Headless is the new hotness. Every organization using a CMS is either moving to a system that decouples the presentational head from the content body or is looking wistfully at their tech-savvy peers who’ve successfully made the transition.
“We’ve now reached a critical mass where even if not everybody’s doing it, everybody is aware of it and thinks of it as an ideal that they should be doing,” says Jeff Eaton. “I think that's the biggest shift I've seen in a long time for our industry.”
But like any platform migration, switching to headless creates common pain points that not every organization or even every migrator has the experience or resources to address.
Let’s face it: most CMS replatforming projects aren’t happening because a management team’s fallen in love with structured data and APIs. They’re done for financial or operational reasons: the current platform (cough AEM cough) is too expensive, the CMS is at its end of life, or there's some other really dull contractual reason why a business decides to terminate its agreement with Sitecore and implement a new CMS. One way or another, the impetus is more about getting off the current CMS than properly planning for its replacement.
This leads to a lot of expensive, time-consuming stupidity for everybody. The existing content may not be properly structured to take advantage of its new platform. Much of it is typically composed of undifferentiated blocks that don’t tell you what’s inside. Different teams of authors might have different needs and workflows baked into the current CMS that will have to be addressed (or underserved) in the new one. And things that used to be stitched together by a monolithic CMS have to be replaced by a bundle of microservices that gather in the seams.
Such a transition requires complex, collaborative, and multidisciplinary work. One of the ironies about a headless CMS is that while it decouples the presentational head from the body, it actually requires all the limbs to coordinate with each other like never before.
All this change makes it an exciting time to be working in digital publishing. “Mobile was a big revolution because it changed how users interacted with content on new devices,” says Karen McGrane. Responsive web design changed how content flowed on those sites and apps. The shift to a headless CMS is addressing the same problems — a shared content repository can be delivered to anything from a touchscreen kiosk with a custom UI or a responsive web front end — but this change is less about users and more “focused on how teams make websites and publish other digital content.”
Ethan Marcotte adds that headless poses special challenges for designers who aren’t used to thinking about content creation, and vice versa. “A design system’s components should be built with an understanding of the kinds of content they’ll contain; a headless CMS might contain fields to describe information as best fits specific screen resolutions,” he says. “Historically, a lot of design teams and product teams have insulated themselves from having to think about some of that. That's why a more holistic view is helpful.”
Jeff notes that headless systems and design systems working together offer a tremendous amount of presentational flexibility, but that the content needs to be properly structured in order to bring out that richness. “You don’t have to build a design system to make your headless schema, but you at the very least have to figure out the ‘range of motion’ you need for your content editors, and it needs to match the way the system works,” he says. “In headless content schemas, you have to collapse decisions about presentation to a meaningful constrained vocabulary of choices. And a good design system is where that is nailed down.”
Headless systems, at least those advertising themselves as such, may seem relatively new to people first encountering them, but content structured to serve multiple platforms and form factors has been around for a long time. Mapping an organization’s content, its structure, its affordances, and identifying where certain locations fall off the map — “here be dragons” — is what Autogram’s team has been doing for more than twenty years.
“We are sort of like the sign-waving prophets saying ‘yes, you have to build the structure’,” says Karen. “Mobile was a great inflection point, but it turns out that you still need this stuff. And I am still trying to tell you, and I'm going to keep trying to tell you.”
Furthermore, organizations and vendors that don’t do this preparatory work can find themselves in the exact same position a few years down the road: organizations drowning in content debt with a CMS nobody’s happy with, or vendors facing blame from a client who doesn’t understand why switching systems didn’t solve their existing problems. And here’s the pitch: either or both of the client or the vendor could have saved themselves a lot of headaches by talking first to Autogram.
So far, we’ve mostly addressed the numerous problems of adapting existing content to a new headless CMS. But most of the missed opportunities come from failing to anticipate the structure of future content. You might simply copy the existing content model from a website or design presentations from an app and call the migration a success. But the presentational possibilities of a rich content model with a range of flexible design choices allow for different kinds of content to be remixed, blended, and adapted in any configuration and combination. The experiences that used to require a design agency and complex hard-wired code or markup can now come out of your design system and CMS. You just have to put the architectural work in first.
Articles and Announcements
The Web Project Guide Podcast, by Corey Vilhauer and Deane Barker
Ethan Marcotte, author of Responsive Web Design and Partner at Autogram, joins Corey and Deane to discuss front-end development and how the world has impacted how front-end design is treated and approached, from the sheer number of devices each design must account for to the impact of those living with permanent and temporary disabilities.
This Max credits thing is apparently gonna be a big, stupid mess to fix, by William Hughes
The Creators tab was apparently the product of harried IT folks who were faced with the daunting task of smooshing together Warner Bros. Discovery’s huge library of content—HBO, Discovery, and other Warner Bros. properties—into one service with insufficient guidance. Rather than parse all the writers, directors, producers, and more who made these shows, movies, stand-up specials, animated series, etc.—and facing the rush to get Max out the door—they opted for the catch-all “Creators” thing instead. WBD executives apparently didn’t find out about the issue until people started, rightly, yelling at them after Max launched earlier this week.
User Inyerface, by Verhaert Digital Innovation
Hi and welcome to User Inyerface, a challenging exploration of user interactions and design patterns. To play the game, simply fill in the form as fast and accurate as possible.