Experiential Design Firm Uses Headless CMS For Display Project; “Considerably Easier” Than Traditional Digital Signage Software
August 19, 2022 by Dave Haynes
At least a couple of digital signage CMS firms have gone down the path of offering what they term a headless CMS – the proposition being that customers with in-house developer and creative talent can continue to use their preferred tools for a digital signage project by tapping into the CMS firm’s API.
So instead of backing out of whatever they use and then launching the digital signage CMS to do that work, they just make the media assets and schedules they develop route through the CMS, without ever using expressly logging into and using that digital signage-specific UX.
I mention this because companies like Signagelive and Screencloud both see at least some of the user base going that way, and they decided to get ahead of it.
Here’s compelling evidence from a much-respected interactive experiences firm, Bluecadet in Philly, that headless is indeed a real thing:
This recent Bluecadet project is a great illustration of our thesis that physical spaces and displays can and should be as timely and relevant as the web, writes CEO Josh Goldblum in a Linkedin post.
This lobby wall at the Glick Center at The MetroHealth System (Cleveland, OH) integrates w Sanity.io – a super easy to use, headless CMS that we use on some of our less complex web projects – aka keeping this signage current is ridiculously easy.
It’s designed to make a range of imagery shine – from artwork, day in the life pictures, videos, etc. but moreover keeping the display current isn’t more difficult than putting a slideshow on Instagram, LinkedIn, etc., easier than WordPress or Drupal and considerably easier than traditional digital signage software.
I poked around Sanity but it’s a site aimed at developers, and I was going cross-eyed quickly trying to understand the proposition. Making content production easy, efficient and somewhat seamless all makes a lot of sense.
The one top of mind question for me is whether these kinds of third party tools have any sort of device management tools. Getting content up on screens is one aspect of the work, but keeping the hardware working and healthy, and monitoring their state and what’s on screens minute to minute, is also a big part of networks of any scale or complexity. Device management is, to my mind, a fundamental component of any sizeable digital signage deployment, and even small ones if what’s on-screen just can’t go down … like ever.
UPDATE: Goldblum provided some additional detail on what is supporting the Sanity CMS:
In terms of other applications being used:
Automatic daily reboot via Task Scheduler as well as Bluecadet Launchpad + NodeJS to monitor and deploy exhibit software, RealVNC for remote maintenance, Visual Studio Code, Visual Studio 2022, Github Desktop and
Unity for display.
This is a one-off and not a big scaled network, so having these tools as backups and support is fine. A lot of ops people would argue, though, that a scaled-up network with a lot of devices would be more easily managed by one CMS that does indeed have good device management, than a headless CMS set-up like this that requires launching and running all kinds of software applications in parallel to keep the patients breathing comfortably.
Interesting but much agreed about device management and support concerns. There are many ways to achieve the concept of managing content outside of the CMS to make it easier for end users, but device and content maintenance are critical parts to a DS network where I think this would make it more complicated, not less.
Thanks for the mention, Dave.
There is a big difference between a Headless CMS for building a web experience that runs in a browser of a user’s laptop or mobile device and a headless CMS for digital signage that provides a full-stack solution for media scheduling, and publishing and device management with proactive failure alerts and reporting.
Both have their place in the Headless, API-first world. In many cases, we have partners and customers using the likes of Sanity, Contentful and Storyblok in conjunction with our APIs and Widget Development Framework that takes web content and ensures it works offline, unattended and at scale on any digital signage SoC display or player.
It’s important to understand what you are trying to accomplish. When I am working with clients, there is a bit of an evaluation phase when it comes to content management and there are some key questions that need to be answered to help determine the approach. There must also be awareness, as you point out Dave, that there are some things that an enterprise content management solution simply do not do when it comes to digital signage – the first is device management (you need to fill this gap) and the second is what I refer to as “orchestration” or getting the right content to the right display at the right time. When it comes to managing attribute based content routing or scheduling (even as simple as dayparting), these are simply not what enterprise web/mobile content management solutions are meant to do. Also, there is a lot of content for digital signage that really doesn’t belong elsewhere – for example, if you are doing a wayfinding project, you might want all of the information about the points of interest to be delivered headlessly from the enterprise CMS, but you might also have an attract loop with large video content that isn’t used on any other channel. There are a ton of ways to skin this cat, as long as you are asking the right questions and have the software development capability to make it happen. I think we as an industry need to move to more and more of a blended/hybrid approach to content management, and for that matter the use of other types of data as content in an experience.
We’ve always built the ScreenCloud with the mindset that we want to connect and repurpose content that already exists – Which means we needed to design the platform in a way that allows customers to do that!
To give a couple of integrations as examples to bring it to life. We have customers using Microsoft Teams to curate content and push directly to screens. We then have customers using Staffbase as their internal communication platform and then integrating with ScreenCloud to extend the reach of the content being shared.
In both cases, once we’re connected, the content creator does not need to visit ScreenCloud at all.
Obviously though, connecting to the content is one part, managing the health of the screen network and device management is another so agree with the comments above.
Appreciate the mention. Cheers Dave