Recently, I’ve had many chats with people in the content management system (CMS) industry about my writing on the universal CMS that tracks the current transition and convergent evolution of the hybrid and hybrid-headless segments of the market toward a renewed balance: the universal CMS. For many, the CMS is a technical product with an emphasis on developers, but the CMS is also about everyone who works with content—whether that means content modeling, preview, workflows, or observability.
Four years ago, I wrote a column in CMSWire about how the headless CMS era has violated a fundamental grand compromise between two important teams: technical teams tasked with implementing presentation layers (such as websites, JavaScript apps, or other channels) and editorial teams who need to make sure those same presentation layers can be previewed and audited for compliance and accessibility.
One aspect of CMS features that the headless and composable segment has done with aplomb is to provide a stellar developer experience, with an expanding array of application programming interface (API) and software development kit (SDK) ecosystems to serve content. But as one headless CMS sales lead opined to me recently, the headless CMS is increasingly commoditized, and editorial teams are increasingly concerned about how their content workflows are falling apart. Two opposing forces are contributing to this:
The channel explosion. Formerly the only digital channel for content, the humble static website of old is now just one in a slew of delivery destinations, including native mobile apps (frequently leveraging cross-platform frameworks like Flutter and React Native), extended reality (XR), in-store signage, over-the-top (OTT) interfaces, voice interfaces, and AI chatbots.
The JavaScript renaissance on- and off-web. The static website is no longer no static, as the moniker “web app” becomes more commonly used to describe the interactivity and dynamism that characterizes websites in the present day. Developers today are using frameworks like Next.js, Nuxt.js, Gatsby, Vue.js, and still others for off-web interfaces.
On my personal blog preston.so, I’ve shared my thoughts on preview and visual editing problems that plague CMS practitioners routinely. In this article, I use “content teams” as a catch-all phrase for all those stakeholders who interact with content as part of their remit. That doesn’t just mean authors and brand marketers working with blocks, components, and previews, but also those who are concerned with regulatory compliance, multimodal accessibility, and legal officers.
In this piece, I contend that what we’re seeing now in terms of more focus on shared, standardized editorial interfaces in the CMS market, given the convergent evolution of the hybrid-headless and headless market segments, is nothing short of a new paradigm for CMS writ large:
Headless vendors are now racing to build visual editors. Based on the softness currently seen in the headless and composable segment of the CMS industry, headless vendors are shifting their priorities. Now, they’re laser-focused on marketing and content teams, not just technical teams, as customers become increasingly unhappy with the present disequilibrium.
Hybrid-headless vendors are maturing in their API and SDK stories. As hybrid-headless vendors face a steep decline in developer satisfaction, a trend that has progressed over years, they’re reorienting themselves away from just bolted-on REST APIs and GraphQL APIs toward SDKs, command-line interfaces (CLIs), sample code, and other ancillary tooling to make hybrid-headless products more usable in headless settings.
However, the universal CMS as a paradigm isn’t just about architectural continuity between editorial interfaces straddling both headless presentation layers and hybrid-headless implementations. It’s also about, especially for headless and composable vendors sprinting to enable these same approaches, a single shared user experience that is capable of universally editing content irrespective of presentation layer and independent of whether that front-end destination is on- or off-web: React and React Native, Angular and Amazon Echo, Vue.js and Vision Pro.
The fact of the matter is, especially since we can’t rewind history, content teams don’t want a CMS without the visual editing, visual preview, and editorial workflows that characterized previous eras of the content management world. But I’m absolutely not arguing that pure headless CMSs, composable CMSs, or hybrid-headless CMSs, can’t be, on their own, the right option for a customer. Instead, I believe the universal CMS is where all vendors across the CMS industry are headed: where universal editing becomes a baseline, not a bolted-on afterthought. The universal CMS is a paradigm where all technologies and channels are first-class citizens. But it’s also ultimately a gathering place for people, where developers and editors are first-class citizens unblocked from doing their best work too.
Why universal editability?
How about a bit of history? The grand compromise forged across developer and editorial teams was struck almost unintentionally during the static website era, and of course, it was by no means prepared for 2024’s difficulties surrounding tech- and channel-agnostic visual editing. But the most important features the next generation of the CMS—the universal CMS—needs to have are as follows:
Universal visual editing. Manipulating block components and layout templates across an array of presentation layers, and across hybrid-headless and composable architectures alike, is now table-stakes for enterprise organizations. But most solution sets on the market right now either require a dependency on easily broken user interfaces (UIs) that demand hard-to-understand plugins and fragment the user experience further, often with gobbledygook URLs.
Universal visual preview. The complete inability to use a consistent visual preview interface in a cross-channel and cross-technology fashion is a constant source of frustration in my conversations with content teams who have evaluated headless and composable CMSs. I’ve written at length about honoring this requirement for off-web channels like digital signage and voice interfaces, but editors shouldn’t have to contend with disparate UIs and disunified workflows to see a live preview. This is also the case for authors who need multiple tabs or windows open to evaluate previews across multiple points in time for embargoed and scheduled content.
Universal time-machine preview and audit trail. The channel explosion and drumbeat of new frameworks don’t change the fact that enterprise organizations require long audit trails that reach far into the distant past—and content scheduling for points far in the future—to ascertain at every touchpoint what, where, and how content appears. With fragmented user experiences and difficult workflows, those who may only interact with a CMS once in a long while, such as compliance officers or single-campaign marketers, often find themselves blocked without grappling with a high barrier to entry or consulting an engineering team.
One editorial user experience to rule them all. All of these concerns also have one big need in common: content teams want one single editorial UI to rule them all, especially for the sort of agnostic content modeling that is pageless and prepared for off-web contexts. As enterprise organizations continue to retreat from expensive product suites and also combat departmental silos characterized by discrete CMSs used internally, a single editorial experience with one onboarding process and one learning curve is now a paramount consideration.
But how on earth did we come to this point in the first place?
A broken contract: Headless visual editing and preview
A depiction of the disconnect in visual editing represented by the pure headless CMS, where in-context visual editing and visual preview aren’t nearly as straightforward as they were in the static web CMS era.
Products like FrontPage and Dreamweaver, representing the “what you see is what you get” (WYSIWYG) approaches so popular in the 2000s, were messy when it came to visual editing for the static website, despite their democratization of a discipline that was solely the territory of developers. Many contend that today’s tools are just as problematic, namely Wix and Squarespace. But there’s another key error that WYSIWYG site builders made: they cut developers out of the conversation entirely, and FrontPage and Dreamweaver were notorious for their propensity for generating spaghetti code.
In much the same way, the monolithic CMSs of the late 1990s and early 2000s made a similar mistake. Yes, they forged a grand compromise crossing the divide between content teams and developer teams stepping on each others’ toes as both worked to build the perfect static website. But they also erred by building into the CMS an expectation of highly contextual and granular in-place editing.
In my view, this represented a shift from WYSIWYG to “pseudo-WYSIWYG,” which proved to be a weighty anchor when web development innovation sped up thanks to universal JavaScript and monolithic CMSs found their templating languages and theme engines suddenly became living fossils. In their own prescriptivism for developers, monolithic CMSs slowed down their own potential for innovation on the front end.
In much the same fashion, many headless CMSs are now allowing their architectural purity limit their penetration by facilitating page- or route-driven headless CMS preview without ever solving for the visual editing gap. Content teams who purchased pure headless and composable products were stunned to find that they now lacked access to features that they had long held dear, all of which permitted them to work independently without the aid of developers.
A few years back, I came across this issue firsthand as part of my architectural consulting practice while on contract with a Fortune 500 company in Japan. Well into a decade-long replatform from a monolithic to a new headless architecture, their developers loved each constituent brand’s launch onto Angular, React, or Vue.js. But their marketers were disappointed as they watched key visual editing and visual preview features vanish or become limited to hard-to-maintain developer-built integrations. Such corporations wishing to engage in incremental adoption of headless architectures consider editorial unity surrounding one interface to rule them all a top priority.
Certainly, template engines and theme layers in monolithic CMSs were frequently seen as leaky abstractions by developers who strained against their seemingly arbitrary limitations. But by the same token, architectural purity in the headless and composable segment is seen as leaky abstractions by marketers who face fragmentary preview and visual editing solutions that seldom work gracefully together.
In the end, preview and visual editing are, by necessity, a use case jointly governed by content and developer teams alike. In the emerging universal CMS paradigm, and as the CMS evolves to be more omnichannel and tech-agnostic, content practitioners still need preview and visual editing, while technologists still need to innovate without obstacles. In other words, no one persona can be fully responsible for both preview and visual editing.
Why is universal editing now table-stakes?
A graph displaying the fidelity expectation for preview and visual editing as a function of the ability for a CMS to enable that fidelity owing to limitations of architecture and implementation
I’ve shared a great deal about the issue of preview fidelity and in-context preview. But content authors and editors now are deeply aware that some previews and visual editing capabilities will necessarily be lower-fidelity than others. When it comes to web-native digital experiences, high-fidelity previews and a high-fidelity visual editor are now table stakes. But for JavaScript applications leveraging Next.js, Vue.js, Angular, Svelte, Astro, and other technologies, high-fidelity preview is a baseline capability, whereas visual editing is quickly evolving to become so. In the universal CMS paradigm, both high-fidelity preview and high-fidelity visual editing are available on a cross-framework basis by default.
A series of illustrative examples demonstrating how the universal CMS enables both content preview and in-context visual editing straddling multiple arbitrary JavaScript frameworks (here, Vue.js and Next.js).
Today, many content teams understand that for pure voice interfaces, previewing and putting together content for presentation is a much more difficult proposition than for a JavaScript app or a static website. Although true channel-agnostic preview and visual editing remains an open question in terms of ease of use, the web, as expected, is still the main place where these actions happen, and that includes off-web channels.
For example, JavaScript technologies like Babylon.js are seeing wider use for the creation of WebXR-driven interfaces destined for extended reality (XR) headsets. Babylon.js even includes internal support for React. Along the same vein, visually rendered chatbots in native mobile apps and even those sometimes uncanny pure voice interfaces for Amazon Echo or Google Home can become web-renderable, just as React Native and Flutter support web-based rendering as well. Even digital signage, which in the past used lower-level technologies, is now becoming more web-based. Web renderability is the cornerstone of how visual editing and preview will function in the universal CMS.
A set of illustrative examples demonstrating how content preview and in-context visual editing on a cross-channel, multimodal basis can occur in the universal CMS paradigm irrespective of destination (here, websites, mobile apps, digital signs, OTT apps, XR, and conversational interfaces).
In the universal CMS approach, all presentation layers and all delivery channels are first-class citizens, along with developers and content authors alike. Similar to the monolithic static web CMS, which understandably only had the prescience to anticipate static websites and, later, responsive websites as first-class citizens, developer teams and content teams need a new cross-channel equilibrium.
In short, the universal CMS is universally editable. And that isn’t just when it comes to both headless and hybrid-headless implementations; it also means all headless destinations, whether they entail multimodal or omnichannel requirements (digital signage, in-store displays, set-top boxes, voice, chatbots, XR) or tech-agnostic ones (Astro, Svelte, Vue.js, Next.js, React, Angular, and even WebAssembly).
What does it mean for visual editing and preview to be universal?
In both hybrid-headless and headless products, one previously ubiquitous word has fallen out of fashion: the idea of layout as a service (and its less flashy corollary “navigation as a service”). In many content management systems, the notion of a fungible block-level component has many different monikers: components, slices, blocks, containers, and others.
Conscia co-founder and CEO Sana Remekie recently authored a blog post about the problem of page-based building, wherein the static website’s biases and the very notion of a “page” as the irreducible unit of presentation layers remain a threat to the ostensibly omnichannel and tech-agnostic outlook for the CMS. Sana’s main argument is something I couldn’t agree with more: the future of the CMS in the long term—and therefore the universal CMS writ large—is pageless (a word we deployed quite frequently at Oracle Content Management).
I’d ever so slightly extend Sana’s astute argument against an overreliance on the page and the web as a vehicles for thinking about visual editing and preview approaches. Still today, CMSs largely remain poorly equipped to deal with presentation layers beyond the visual web and the visual smartphone, especially aural and spoken content (think voice interfaces or speech-enabled chatbots) and immersive and spatial content (think digital signage, XR interfaces, and in-store displays).
We’ve launched for general availability a Universal Visual Editor at dotCMS with an ambitious vision to power both visual editing and preview capabilities across JavaScript architectures and the pageless channels of the future that lie beyond the web. Any web-renderable presentation layer, after all, whether it’s responsible for aural content or immersive content, ought to be previewable and visually assemblable within a CMS. Whether it’s a chatbot interlocution or a floating XR overlay, in the universal CMS, the page becomes just one of a slew of available irreducible units.
A depiction of the dotCMS Universal Visual Editor, illustrating the in-context visual editor available for dotCMS copy that’s delivered to a Next.js app.
All this becomes more urgent in a world where compliance and auditing capabilities continue to surface as must-haves for enterprise organizations, just like features like multimodal accessibility, content observability, and content scheduling and embargoing. The World Wide Web Consortium (W3C) is working hard towards better standards for XR and multimodal accessibility alongside more robust recommendations for website interactivity. As such, the editorial workflows marketing and content teams rely on only become more complicated than ever before. When it comes to the universal CMS, these workflows need to be made simple for every channel and every technology.
Conclusion: One editorial UI to rule them all
At its core, the universal CMS is about what’s coming. Most organizations today, after all, are dealing with these difficulties now, and the CMS industry isn’t yet ready for what exigencies content teams and developer teams will grow into in the medium to long term. That’s why I believe the next evolution of the CMS needs to be the universal CMS—headless-first with hybrid-headless for those who want it—as the web moves fully off the page.
In order to succeed, the universal CMS, represented by the convergent evolution and “race to the middle” between hybrid-headless and headless feature sets, has to satisfy both engineering teams and editorial teams as first-class citizens, all while the omnichannel and tech-agnostic outlooks continue to evolve. That demands a single unified editorial user experience that incorporates the biggest advantages of headless architectures for developer teams in addition to the biggest advantages of a single user experience for editorial teams.
A month ago, I chatted with an executive with many years of experience in composable CMS. He revealed to me his conviction that pure headless and composable CMSs are losing traction due to their fragmentary and confusing user experiences for editorial and marketing organizations. Today’s buyers, who continue to be deeply discerning, increasingly seek a single shared editorial experience to work with and visually build their content, regardless of where it ends up.
Content needs to be universally editable in the CMS to make this a reality across both the omnichannel and tech-agnostic landscape. The time when we could rally customers to our side with a page-driven and web-focused orientation for visual editing and preview is long gone. The universal CMS jumps firmly off the page and off the web.
In the subsequent part of this series (see part one), I’ll share the clear need for a universal developer experience permitting engineers to bring with them any stack and any framework of their choice, including technologies that haven’t yet been invented. The CMS no longer has the luxury to prescribe what JavaScript framework developers should use. In short, the universal CMS needs to be universally developable.