Off to the digital experience races: The second CMS war is officially here
February 4, 2020Over the course of the last five years, I have been keeping a close eye on content management systems (CMS) and how they have evolved in light of the dizzying innovation that has taken place in the web development world. In my opinion, one of the most surefire signals of a coming paradigm shift comes when there is a substantial change in terminology and in how industry analysts like Forrester and Gartner envisage the CMS market. This past month, Gartner retired the Magic Quadrant for web content management (WCM), citing the increasing homogeneity in the WCM landscape. This comes after Forrester’s assertion as early as late 2018 that the “classic” era of WCM is at an end.
The new term in vogue at Gartner is digital experience platform (DXP), which to me feels like a coinage that attempts to capture all of the various trends impacting the CMS market at this moment: the channel explosion when it comes to content delivery, the shifting separation of concerns when it comes to CMS architectures, and the move towards increasingly distributed approaches to content management. These mirror my statement during my keynote at DrupalCamp Pune last year that we should no longer be characterizing the CMS as a contiguous system, but rather as a distributed content management stack (with the added benefit that no acronyms need an update).
In Dom Nicastro’s article in CMSWire highlighting Gartner’s change, which Forrester has yet to adopt, he quotes Deane Barker of Episerver with the following intriguing quote, which mirrors much of my own thinking ever since I began exploring the growing frictions and conflicts engendered by the splintering of traditional CMS architectures at DrupalCon Vienna in 2017:
“So there will be two sides — content management and experience management … Many of systems [sic] — like Episerver — will cover both. Other systems, like headless vendors, will only be on the content side.”
In these next two posts about the future of the CMS, I want to unpack the concept of experience management and how precisely traditional CMS ecosystems like Oracle, Drupal, WordPress, Adobe, Sitecore, and Episerver will distinguish themselves in a landscape increasingly dominated by headless upstarts like Contentful, Contentstack, Prismic, Forestry, and Sanity.
What exactly does an abstract concept like experience management mean in the context of this shift toward digital experience platforms (DXP)? In this article, I’ll examine the ways in which the coming CMS war will reflect the browser wars of old and, in contrasting the second CMS war with the second browser war, how anyone who wishes to capture this hypothetical DXP market must provide capabilities that straddle multiple personas, an increasingly intractable endeavor for the vast majority of players in the market today, for a wide — and punishing — variety of reasons.
How the CMS wars reflect the browser wars
I had the unique privilege of growing up as a web designer and developer at the tail end of the first browser war (1995-2002) and at the onset of the second browser war (2004-2017), when graduating from table-based layouts to CSS-driven layouts was a rite of passage. Both of the browser wars were events that today seem positively prehistoric against the backdrop of the achievements wrought by the web standards movement and unification around clear and unequivocal shared feature sets across browsers, especially the developer tooling revolution first realized by the likes of Firebug. Interestingly, there are several ways in which each iteration of the browser wars mirrors the CMS wars that have occurred over the past decade.
The first browser war, which involved the vying for dominance between heavyweights Internet Explorer and Netscape Navigator, centered around issues of product packaging (in which Microsoft won the day by ensuring every single installation of Microsoft Windows came with Internet Explorer by default) and feature sets that sometimes veered on the comical (such as Netscape’s now-pilloried introductions of the decorative
<blink><marquee>Feature completeness: The first browser war and first CMS war
The race to build new features — at the expense of the ability for web standards to flourish, in the context of browser technologies — was what characterized the first browser war (which Wikipedia says lasted from 1995 to 2002) and also the first CMS war (which I would date from roughly 2005 to 2014). Initially simplistic blogging or message board tools with limited functionality and flexibility, the content management system as an entity exploded in innovation in the early 2000s with the advent of server-side dynamism, as I described last year in my examination of the history of CMSs.
Some of the most widely used features in content management emerged during this period, such as custom content modeling capabilities in Drupal core and WordPress’s plugin ecosystem (in the form of Advanced Custom Fields), as well as complex query builders like Drupal’s Views module and WordPress’s Toolset Views. Many CMSs quickly followed suit or already relied on this functionality as a foundation, and custom content modeling and arbitrary content listings are now rightfully considered table stakes for all CMSs across the market. And just like the
<blink><marquee>User experience: The second browser war and second CMS war
As for the second browser war, which ended with the dominance of Google Chrome across nearly every country in the world (although due to recent optics challenges, Mozilla Firefox is garnering a second look from many users), two defining trends cemented the battleground for the next volleys between combatants: the emergence of the mobile web and the importance given to perceived browser performance and the end user experience. With new challengers like Opera, which was (and remains) a compelling option for both mobile and desktop browsing, it became crucial to support not only a bevy of new devices and network conditions but also a variety of ways in which users interacted with browser products.
The second CMS war, which has already begun thanks to the proliferation of headless or decoupled content management solutions, will involve precisely the same machinations on the battlefield. Many CMSs, with the possible exceptions of Adobe Experience Manager and Oracle Content and Experience (OCE), have had significant issues entering the mobile space in the senses of both content delivery and editorial administration, due to the implementational issues involved in architecting a mobile editorial experience for back-office users (for full disclosure, I contributed to Drupal’s Spark initiative in the early 2010s, which aimed to provide mobile-optimized functionality in Drupal’s editorial interface) and, on the delivery side, the sheer variety of new devices that needed to be tested and built for.
Moreover, the second browser war represented a wholesale transition of web development towards web programming with the advent of DHTML (Dynamic HTML) and JavaScript in the browser. The introduction of client-side scripting in browsers is an event I consider highly analogous to the more recent runaway adoption of universal JavaScript approaches and the Node.js runtime for server-side JavaScript, which has in turn led to a high amount of innovation in the CMS world. Decoupled Drupal, headless WordPress, Sitecore’s JSS, and other forays into decoupled content management architectures are not only symptomatic of but also synonymous with this development in the second browser war.
However, there is a key distinction between the context in which the second browser war occurred and the emerging milieu in which the initial skirmishes of the second CMS war are now being fought: the end user experience. Browsers have long only had to contend with a single class of users: no matter whether you are searching on Google, scrolling on Instagram, or purchasing on Amazon, the browser’s primary persona has always remained solitary: the end user. Content management systems, on the other hand, have never had such a luxury, given that they have always resided at the uneasy nexus between editorial, marketing, and developer needs.
Revisiting “Decoupled site building”
Three years ago, I had the opportunity to deliver a conference session at DrupalCon Vienna entitled “Decoupled site building: Drupal’s next challenge” about the tensions increasingly inherent to the CMS landscape with the promulgation of decoupled architectures. I had just had the privilege of completing significant research concerning decoupled Drupal, and I was becoming nervous about the relative paucity of attention afforded the vast changes that traditional CMS personas were witnessing as the significant evolution represented by decoupled CMS architectures began to become clear. One persona in particular, often split between editorial and marketing functions, has to do with site building.
In Drupal parlance, site building is defined as the set of workflows that involve user interactions with administrative interfaces not associated directly with content creation or editing itself. So-called site building features run the gamut between layout management, content templating, and query building — all operations that a traditional content creator may not undertake with regularity. Even today, in most CMS practitioner teams, the site builder tends to be a mix between the editorial and marketing organizations — indeed, whichever has the most experience bending the CMS to their will so that it displays content the way that it should look for a particular landing page or as a curated list of related articles.
Not all CMS personas are treated equal anymore
During that session in Vienna, I presented the most pressing concern that traditional CMSs were dealing with at the time and continue to grapple with today. As mentioned in the previous section, the ideal CMS in 2017 was not only one that began to offer compelling options for omnichannel content delivery but also one that continued to serve as effectively as possible the use cases of four distinct personas: the content editor, the developer, the marketer, and the end user — all with different needs, all with different entry points, workflows, and interaction flows within a CMS product.
The growing incongruity in CMS value propositions
The figure above drew quite a bit of attention from the audience as it attempted to depict the fundamental problem facing content management solutions today. These wholesale paradigm shifts in developer experience (represented by the runaway growth of JavaScript frameworks in front-end development) and content delivery (with user expectations that content can be accessed on any device and on any conceivable experience) have generated an anxiety-inducing and nerve-wracking incongruity between the traditional personas that have long defined the uneasy alliance at the core of the CMS value proposition. The figure below shows how I would illustrate this incongruity today.
One of my key messages I hoped to convey then was the concept that CMSs will soon need to address the coming irreconcilability between the fact that new channels for content delivery are increasingly exclusive solely to those developers who are sufficiently skilled in an increasingly complex constellation of competing technologies, and the notion that the CMS needed to continue to serve as that ideal meeting point and functional intersection for content editors, content marketers, and developers extending functionality. It dawned on me at the time that so many of the features that we had built in Drupal with such enduring success — in-place editing, contextual links, layout management — could all be for naught without the ability to offer similar manipulability of presentation layers well outside the usual auspices of the web, especially in light of the shift in the separation of concerns in content management, whose traditional conceptualizations are facing growing challenges.
From WCM to DXP: What’s in a name?
For what it’s worth, I don’t think that CMS practitioners — except perhaps those choosing the vendors and writing the checks — will rush to embrace the term digital experience platform, as it is merely an extension of what the CMS has already represented for several years: a content repository for omnichannel delivery that still retains the editability and manipulability of a web-only CMS — that is, for its own native front end only. Nevertheless, it is striking that Gartner has raised the bar for CMSs in order to match the demands we are already witnessing in the enterprise CMS segment: a modern developer experience and an editorial experience truly and authentically prepared for the omnichannel.
At the time of that talk in Vienna, I was fortunate to work on an exceptional team working on Drupal’s core features, particularly those enabling API-first content delivery, the subject of my recent book Decoupled Drupal in Practice (Apress, 2018). As such, because so many of my teammates were focused on how to enable improved editorial experiences in Drupal’s core feature set, I was particularly concerned about the notion of content editability and whether editorial interfaces should be part of every device’s experience. Several years later, it is clear from both market trends and usability tests that the vast majority of editors prefer to use CMSs on their desktop computers rather than on mobile devices or even more unrealistic environments like an Apple Watch or an Amazon Alexa (though the many innovative experiments and prototypes that emerged during that era would beg to differ).
Happy developers, but unhappy editors and marketers
Nonetheless, the notion that content editors and marketers have no desire to collaborate on content in a variety of highly distinct form factors does not discount the fact that content simply must look different on all of the environments to which content is now delivered. How does that carefully templated, copiously perfected landing page translate to a mobile or smartwatch context? What happens to a list of related articles when the only way to access it on an Alexa skill is by asking for it through a voice command? How can a CMS user lay out templates for, preview unpublished content on, and ensure compliance for such an experience?
In other words, this is to me the most essential unsolved problem that plagues every content management system on the market today, irrespective of whether it is a new kid on the block like Contentful or an old mainstay like Drupal. Resolving this core conflict is what I contend lies at the core of the transition from web content management (WCM) to digital experience platforms (DXP), and every CMS today is now burdened with overcoming this seemingly insurmountable obstacle. It should come as no surprise to my readers that though I routinely sing Contentful’s praises in many other regards, I have heard much less positive feedback from the many enterprise marketing teams transitioning to a CMS platform that represents, in their view, an unforgivable surrender of key editorial functionality — no matter that the developer team across the open office is rejoicing and jumping for joy with their newfound power.
The Holy Grail of digital experience management
To return to Deane Barker’s word choice of experience management, I would argue further that what is truly needed for CMSs to succeed in this day and age — and the Manhattan Project that will win the second CMS war — is presentation management. But this is not just the ability to manage how content is displayed in terms of how items are sequenced or how a template is spliced into interface cards on a smartphone; it is also about how to create a compelling developer experience that makes the evolving relationship between the marketing team and engineering team as frictionless as possible, and indeed, as balanced as it was in the web-only CMS era.
In my view, this is the Holy Grail of what we call digital experience management. After all, content reuse has become a chief concern in light of the many dead-end mobile applications that traffic in orphaned content and are routinely the focus of complaints from users expecting all web content to be accessible through their iPhone. This problem is further compounded by the fact that the vast majority of CMS users today lack the bandwidth or the budget to juggle multiple content models, distinct across channels with unique approaches to displaying content. We experienced this ourselves while working to accommodate the State of Georgia’s desire to retain a single rendition of all of their content across both web and conversational channels during the development of the Ask GeorgiaGov Alexa skill.
Conclusion
The challenge now, of course, is how to make this a reality such that both developer teams and marketer teams will be satisfied with their choice of a content management system. For the vast majority of organizations the world over, it is a foregone conclusion that content must be recycled, intact, across not only the web but also an incredible range of digital experiences represented by mobile, conversational, wearable, digital signage, augmented reality, and virtual reality experiences.
How editable should these experiences be? How much control should a content editor or marketer have over how their content looks in these novel experiences and ones that we have yet to see emerge on the horizon? Should we advocate a retreat from the vast feature set that CMSs supported in the web-only era, much like the retirement of Drupal’s Color module, and let developers do the heavy lifting? Should CMS ecosystems begin to think about things like emulators to power previews beyond the web, something that seemed unfathomable when preview functionality first became ubiquitous in content management?
Even after all these years, I’m convinced there is a way to find an optimal equilibrium between the needs of the marketer and developer in a manner that prestiges both personas and doesn’t leave one or the other behind. We have invested far too much in the happy medium that the web-only, monolithic CMS has long straddled only to see it all gone in a flash with a shrug. In my next blog post, I will begin to examine at a high level the sort of product thinking I believe all CMSs will need to undertake to craft an attractive experience for all personas that also retains as much of the CMS functionality we all hold dear as possible.
Fortunately, there are exciting emerging approaches from both extremes of the spectrum — whether at the design stage or at the implementation stage — that suggest this utopian future may not be as far off as we think. In the meantime, though many have waxed poetic about the demise of the CMS as we know it, including even me, we are about to enter an era of unprecedented innovation and vast competitive battles that will go well beyond neologisms and truly rebuild our shared foundation of what makes a CMS … a CMS.
