Content management systems have always held a place at the center of multiple personas, both editorial and technical. Because of this, vendors have made grand compromises and set in stone social contracts to ensure the success of everyone who interacts with a CMS, whether a content planner, compliance officer or executive stakeholder. In previous contributions to CMSWire, I’ve identified some of the core areas of collaboration: unpublished content preview and digital experience management.

But as the CMS continues to evolve in the market into a more enterprise- and future-ready digital experience platform (DXP) that ostensibly treats all digital experiences equally (especially those that don’t play in the same sandbox as websites), these social contracts, long foundational to the successful use of web CMSs, are beginning to fray in ways that not only challenge traditional stalwarts in the market but also emerging upstarts who are realizing CMSs have always been about much more than data management and delivery.

There have always been odd and arbitrary distinctions that separate some CMSs from their competitors. Some traditional web CMSs, for instance, only deal with individual websites, requiring separate CMS installations for each new site (or a convoluted multisite strategy that can quickly overwhelm even the most skilled power user). Others juggle multiple sites, mobile applications, and now contend with the widening array of possible digital experiences out in the wild.

Others, meanwhile, have severed the long-sacred connection between editors and their content through decoupling — an architectural separation of concerns that to content managers seems awfully arbitrary and opaque. Here, the challenges of content preview become extreme for editors who simply want to push a button and see their unpublished content in any number of possible scenarios.

These social contracts, increasingly interrupted and disrupted by both ambitious architects and forward-looking futurists, are critical to the continued success of digital experience platforms as they continue to evolve, because they have been integral to CMSs for so many years. DXP vendors therefore face a stark choice: handle all digital experiences as gracefully as they do websites, or get out of the experience management game altogether to focus on data delivery as a headless CMS. Provide preview functionality for all digital experiences, or get out of the best-in-class preview game altogether.

No longer is there any in-between. Because a DXP that does wonders with websites but falls flat on its face with mobile, JavaScript and other applications isn’t showcasing a full feature set. Rather, it is showing its age and that its hodgepodge of capabilities, none of them aligned with each other, is no match for the ongoing channel explosion.

The Web CMS Forged Multiple Social Contracts Between Personas and Vendors

The current state of the market looks very different from the landscape of the mid- to late-2010s, before the channel explosion and ensuing expansion of content delivery needs first made their mark. Traditional, monolithic, web-only CMSs only needed to contend with a single question when it came to digital experience management: Should we build a system that powers a single website or a platform that powers multiple websites?

For a long time, these decisions were made without much notice from the market, as players like single-site Drupal (its default approach) or multi-site Adobe Experience Manager squared off. Today, however, whatever social contract vendors signed with their customers are long since outdated. Data needs to end up in more than just websites, and those content consumers need to be first-class citizens too.

The headless CMS upended the CMS market owing to its fairly successful argument that it’s simply impossible to manage digital experiences writ large in the same way we manage individual websites. But as I’ve written before, shrouded in the promises of developer freedom by headless CMSs is the disenfranchisement of editors and content strategists who see yet more of their power stripped from their key roles.

Related Article: Is a Headless CMS Right for You?

DXPs Have Broken the Social Contract of Digital Experience Management

In my conversations with enterprise organizations and small businesses alike, I hear a common refrain: “It used to be so simple. Why is it so complicated now?” DXP vendors seem besieged from all angles by the same personas they used to serve effectively: product managers want more digital experiences, content strategists and editors want more visibility into those experiences, and developers continue to want the freedom to build how they want. Over the last several years, these requirements have felt increasingly irreconcilable.

For architects and developers who decry the emphasis on digital experience management as opposed to channel agnosticism, look at the problem from the editor’s perspective. For many years, all site builders had to do was install a CMS, add some templates and a theme, and voilà! A fully built, production-ready website. But when the technologies and infrastructure involved are totally foreign, and when the digital experiences we now have to manage are alien to the systems we so carefully built, it’s clear a paradigm shift is needed.

Take products that allow users to build multiple websites on a single platform, and those that in recent years have added mobile application management to the mix. Those show up as managed experiences within products like AEM, but as universal JavaScript becomes the preferred development approach for large swaths of the web developer community, do JavaScript applications simply become untouchable, inaccessible black boxes or islands?

Learning Opportunities

In other words, when you give users the ability to manage multiple websites or mobile applications, you’ve inked an implicit social contract with your customers. It’s only a matter of time before they say, “I’m so glad I can manage my websites and applications entirely from here. But what about my React app, Gatsby site, and (perish the thought) voice interface?” You have given them a subtle promise that any conceivable digital experience, JavaScript or not, WebXR or not, shared infrastructure or not, can be managed within your product.

Related Article: A Trip Down WCM Memory Lane

How DXPs Have Broken the Social Contract of No-Code Content Preview

Perhaps nowhere else have we seen the tensions borne out so forcefully by the fraying social contract of digital experience management than in the problem of no-code preview. In the olden days, web-only CMSs made a singular and unique promise to customers that has long since come back to bite them in many ways. No matter how you build your site, there will always be a no-code approach to content preview available for you to check it before it goes live.

Preview in digital experience platforms is the single feature that has led to both unprecedented innovation in the CMS market but also unmitigated frustration among our customers. The channel explosion, as it has done with so many other established ideas in the CMS universe, has completely overturned the monolithic grace with which preview was achieved in bygone eras. Most vendors have struggled to enable preview of unpublished content with headless consumers, vying either for a hodgepodge of integrations with infrastructure providers or providing a chaotic range of plugins that inject preview buttons into existing CMS interfaces. Others have “single-page app editors” that are so custom-built they virtually guarantee vendor lock-in.

For those vendors that have always enabled the management of multiple digital experiences, even though they are now no longer limited to websites, the question of preview becomes a question of integrations and graceful communication with infrastructure providers that can provide a preview build or environment — without leaking too many abstractions. But for headless CMSs that have long prized their agnosticism, the issue of preview injects a series of challenging problems, much like the hard-to-manage preview widgets in Contentful that interact with specific infrastructure providers but offer users no sense of what the digital experience is or how it figures into their larger milieu of managed digital experiences.

For this reason, I’m deeply worried about how certain vendors use the “DXP” name without acknowledging pressing problems in the never-ending tug of war between editorial, marketing and technological prerogatives. I’ve written before about the DXP's potential disintegration as a cohesive market. Are marketing teams everywhere destined to lose out on all the benefits of the channel explosion by handing all of their needs to technical teams that might care much more about performance enhancements than supporting no-code preview?

When we can no longer manage digital experiences as tangible, browsable, viewable entities on a user interface — as we have for decades — they become black boxes, unreachable siloes, developer-only playthings, and editorial orphans. When editors can no longer interact with their digital experiences as richly as they were able to before, they become convinced that they can’t have any input into them at all — and that they are playing a losing game.

Related Article: With Content Delivery, What Goes Around Comes Around

fa-solid fa-hand-paper Learn how you can join our contributor community.