preston.so

Lately, it seems that we are living in two very different realities when it comes to content management systems (CMS).

In one reality, and in one parallel universe, CMS practitioners speak of application programming interfaces (APIs) and technical jargon such as GraphQL, decoupled Drupal, universal JavaScript, and a slew of three-letter acronyms like JSX, MDX, and ES6. They refer to content as “data” and wax poetic about traversing JSON trees and leveraging newfangled asynchronous rendering approaches. In this reality, developers have all the privilege when it comes to CMS, and they have begun whittling away nonnegotiable features such as straightforward preview and layout management, oftentimes to exert greater control over how “data” is presented. And sometimes, you hear whispers of bottlenecks—editorial approvals that go nowhere and compliance audits that can’t occur—but after all, these are solely the concern of the content teams, not us engineers.

In the other reality, CMS practitioners use terminology that scatters developers into hiding. They refer to digital asset management (DAM), personalization, analytics, search engine optimization (SEO), and proper metadata. In breathless excitement, they are found discussing the ideal content strategy and information architecture, the correct landing page layout, and the right way to surface related content on their organization’s mobile and voice applications. In this reality, it’s all of the CMS personas not wielding code editors that have the advantage, and the CMS to them is not just a handler for data—it is, rather, their only means of interacting with their content in any rich capacity before it is delivered aloft into the ether. On occasion, you hear these practitioners refer pejoratively to the technical teams across the back office who don’t seem to grasp the importance of cohesive content management for necessities like scheduling content, multivariate headline testing, and menu manipulation.

I used this phrasing—”different realities”—during my recent keynote in Manila (presented virtually from my home in New York), because for all intents and purposes, these are two distinct realities with very different outcomes for the practitioners involved. In Manila, I spoke of the uneasy alliance that content management systems had forged in the late 2000s and early 2010s, only for that grand compromise to be jettisoned just as quickly as it was struck by the eagerness of developers to adopt headless CMS architectures.

But you see, the divergent ways in which CMS practitioners talk about the tools they use on a daily basis are not just impacting how these user personas perceive the system they interact with; they are causing a much more worrying phenomenon. In fact, the divergence in discourse when it comes to CMS is not only affecting our perspectives but also, much more alarmingly, leading to a bifurcation and even a potential disintegration of the CMS market.

When developers speak of headless CMS as deliverance from the evils of traditional or monolithic CMSs, and when everyone else refers to headless CMS as anathema to their prerogatives, the result is these disparate perspectives’ considerable influence on the feature sets that emerge from the product teams responsible for respective CMSs. And this phenomenon is rapidly giving way to a polarized market in which two disparate but key user bases now have diametrically opposed understandings of what the CMS ought to be.

In this article, I analyze the current emerging schism in content management through the lens of why a new grand compromise is needed in CMS to accommodate the burgeoning diversity of use cases and demands now challenging the industry in ways never before seen. In the process, I argue that neither reality is entirely faithful to the truth and that the current state of the market is merely a transitional phase to a new embodiment of the CMS. Much like the polarization we are experiencing in human society, we must confront this split before it results in a poorer world for all of us.

Market bifurcation in CMS is due to divergent discourses

I recently had the opportunity to revisit my illustration of CMS market bifurcation from my examination of the imminent second CMS war and the hierarchies of needs in content management, both of which will dictate how the new headless CMS upstarts in the market fare against their more well-established counterparts. In my previous treatments of the market schism, I’ve primarily focused on the changes in expectations of developer experiences and other user experiences within the context of all CMS user personas. But in my reevaluation of the graph above, I also realized that much of the divergence between the headless CMS segment of the market and the traditional segment is due to how each “reality” is defending and touting their respective feature sets.

This schism in the CMS discourse is already leading to considerable anxiety among CMS practitioners rightfully concerned about the impending disruptions coming to the market. It could not be any clearer from developments in the past several years that the uneasy alliance of the CMS’s first era is no longer achievable under the current circumstances.

After all, developers unhappy with antiquated theming experiences have decamped for headless CMS approaches that prestige universal JavaScript, while marketers and content editors continue to shelter in place for fear of losing must-have features they have held dear for well over a decade or more of working with a CMS. Both groups are within their full rights to move into or remain on these paradigms, but the strains are beginning to show.

The incomplete promise of headless CMS

I recently spoke to a CMS expert who characterized headless CMSs in the most succinct possible way for those who are wavering in their adoption plans: they are “by developers, for developers.” In many ways, I couldn’t agree more. The now-popular mainstays like Contentful, Prismic, and Sanity are notable not just for their emphasis on developer experience and robust content delivery APIs but also for the austerity and sparseness of their user interfaces. Gone are the layout managers, the contextual editors, the in-context menus, the interactive preview with dotted-line affordances for express editing. In their place are incomprehensible (to editors and marketers) APIs, gobbledygook JSON, and formless form fields ripped from their line-wrapping, font-formatted, in-context richness.

This new reality CMS users who are not developers face is striking in terms of its minimalism. And this minimalism is placed into even starker relief when comparing it to the limitless range of possibilities that headless CMSs now offer developers, despite the fact that all of this newfound power is inaccessible to the CMS users who previously enjoyed a bevy of key features to manipulate not just the content itself but how it is presented in a variety of contexts. And even where those features can be made available, such as preview, it is no longer the no-code flip of a toggle or button click that project managers and compliance officers are accustomed to; instead, it requires at least some involvement of a “black box” developer to glue all the pieces in place first. It is precisely this incongruity in CMS that I have identified and tracked for the last four years.

The fact of the matter is that CMS users still consider many of these features to be nonnegotiable must-haves, and this is the reason why many headless CMS vendors have seen their adoption curves begin to flatline after years of spiking growth from eager early adopters in the form of developers. Now that headless CMS has entered a new stage of development, those who scratched their heads at the trend have no impetus or incentive to back down from their detractions. In short, for CMS users who are not pushing pixels in CSS or crafting components in React on a daily basis, the promise of the headless CMS is woefully incomplete, though there are some beginning to acknowledge and address this problem by scaling the hierarchy of needs for CMS users who are not developers.

The front-end obsolescence of the legacy CMS

That being said, developers are nonetheless correct in their own evaluation of the inertia surrounding front-end approaches in the vast majority of CMS ecosystems. By fleeing for other CMS architectures that offer a more robust developer experience and better technical paradigms and development best practices, developers have pile-driven a stake into the ground, emphasizing that they will never return to the previous world of compromising too much of their experience again. But to understand why this poor developer experience exists in the first place, it’s useful to take a brief jaunt back in time.

By and large, contemporary CMS developer experiences are anachronistic and rooted in outdated approaches that overburden the theme layer with considerations not only for data handling but also for in-context user interfaces and exception-filled abstractions to furnish variables for the front end. But rather than comprehend the rationales for why this theming experience exists in the first place, many developers have instead champed at the bit to free themselves of fetters they see as obstacles to their progress rather than as conduits to richer collaboration and faster iteration.

Indeed, the reason the theme layers in CMS ecosystems are the way they are is due to the grand compromise struck in the late 2000s and early 2010s during the first war of the CMS. In exchange for peace of mind at night and the ability to move on to other projects, developers acceded to editorial demands that certain in-context and presentational manipulation be possible. Although they may not have known it at the time, the architects and developers responsible for forging these initial developer experiences also shouldered the unique cognitive load of ensuring, Goldilocks-style, that these did not go too far in hampering developer experiences nor in hindering editorial and marketer interactions with the content they own.

Content is not (just) data

This is why much of the viral marketing I see around “content as data” from some of the more developer-friendly CMSs on the market is something I consider somewhat disingenuous from the perspective of the core CMS users that do not consider themselves developers. Headless CMS perpetually traffick in the notion that content is merely data in the new omnichannel world, and in their view, marketers had better get used to that idea. But the truth, as we see from the growing dismissal with which the marketing technology world has greeted the headless CMS segment, is much more complicated.

The first iteration of the CMS that emerged from the initial battles of the first CMS war did not fall into the “content is merely data” trap. These early vendors acknowledged that content marketers and editorial teams considered content to be their bread and butter, their wares, their primary currency. By ripping content away from its original contexts and putting it squarely in the hands of developers who treat it as data, we are jettisoning all of the functions of the CMS that go well beyond data abstraction and presentation.

Content strategy, information architecture, accessibility, semantic markup—what happens to all of these core elements and key features when content editors and marketers can no longer influence the very entities ensconced in the CMS that they are supposed to be responsible for as part of their job description? By sapping the power of other CMS users away and handing it to developers, we are not only doing a disservice to CMS users; we are also doing a disservice to the end users we are supposed to serve by preventing content teams from leveraging their expertise to the fullest extent.

In short, we urgently need to return to the correct conception of content not as merely data but as the functional layer on which different ideas about content must necessarily operate. The developer notion of content as data must coexist with the editorial notion of content as copy.

Headless CMSs, in turn, need to recognize that content management systems are much more than data stores and mere content repositories; they are key gathering points of collaboration, landmarks on the topographical map of content governance. For these new industry upstarts, the easy problem of APIs and offloading maintenance work to editorial teams is resolved. But the more important headless CMS challenge—fostering the same conduit of content management and rich contextual collaboration that existed previously—is just beginning.

Conclusion

If this seems similar to previous arguments I have presented in this blog, especially why the post-CMS era isn’t here and why the second CMS war is nigh, you aren’t imagining things. But this is the first time I have acknowledged the persistent role of persona discourse on how our content management systems are shifting in ways that are beginning to leave entire populations of users behind in the dust. Unless we begin to recast the discussion surrounding CMS not as a means for developers to shake off their shackles or for marketers and content editors to shove coders out of the way, but rather as a nexus of collaboration between discrete teams having different motivations, the rift in CMS will continue to widen.

In coming articles in the medium and long term, I will craft a clearer picture of how this new grand compromise in content management needs to look for each persona and, further, what each persona will need in order for us to repair the disunity in CMS and restore the sort of coherent collaboration we benefited immensely from in previous decades. If we don’t pursue a path that restores the primacy of the CMS as cross-persona collaboration center, we may soon be greeting these two different realities as an inevitable future rather than as a temporary impasse.