Have Headless CMSs Forgotten Content Teams?




PHOTO:
Alev Takil | unsplash

Content management systems (CMS) have been around for decades and like many things that survive the test of time, these solutions have gone through many metamorphoses. A conventional, straight-up, head-still-attached CMS offers three core functionalities: Data storage, a user interface for content management and a content delivery mechanism.

So what happens when you chop the head off?

The Pendulum Swings Again With Headless DXPs

In a sprint to become uber-nimble and ultra-flexible, are we de-prioritizing the author’s importance and experience with our (supposed) headless digital experience platforms (DXPs)?

The authoring experience in many of the newer headless content delivery platforms has, again, taken a backstage to technology. Questions like:

  • How do you deploy?
  • In what technical manner?
  • To which channel?

Has supplanted the authoring experience priorities like:

  • Is the authoring user interface intuitive?
  • Is the tool accessible?
  • Can any author engage with the technology, or do they need a Ph.D. in front-end development?

Having been in this business for over 20 years, I’ve seen the ebbs and flows of the world of content management, and I believe the pendulum is shifting in the wrong direction.   

Related Article: Why We Need a Grand New Compromise in Content Management Systems

A Quick Walk Down Web CMS History

In the late 1990s we saw the rise of content management system (CMS) titans — Documentum, Vignette and Interwoven (among others). Thus began the early battles between content authors and the content authoring interface. This battle was before the overhyped web 2.0 found itself center-stage, and suddenly the web interface and its usability were being prioritized by the digital community.

At first, the focus was on the site visitor, encouraging interactivity with the site. Meeting this content need required a significant uptick in content velocity — more content, more often, at a higher cadence — and quickly pushed content management system software vendors to follow suit. How can we improve the relationship between our products and the users? Speed and productivity were at the heart of this new wave, answering a new question: How quickly can we add compelling content to our sites?

As the digital revolution continued, a new need emerged: usability of the systems by non-technical users.

Usability wasn’t a novel need, but would allow marketing and content teams (i.e., non-technical teams) to truly take ownership of the content management process by removing the HTML and random JavaScript skillset requirements of earlier CMS iterations. The days of the “webmaster” were over. Heavy market players, like Fatwire, RedDot and Percussion, took a page from some of the earlier in-page editing systems, like Macromedia’s Contribute, and began introducing newer ways to enter content. In-context — not just a WYSIWYG editor that showed a few styles, but a page that attempted to resemble the final rendering of a published page — became the standard to meet. Being able to click on a small red dot and edit the content “right there” was a huge draw and the key to the name of, you guessed, RedDot.

But there were drawbacks. The process was slow, the result often had misalignment, and the systems were difficult to code. As a result, allowing structured content to be edited and previewed took serious effort. The strides this took towards usability by content authors were momentous. Or, as most of us saw it, a game-changer for content authorship and content entry portability.

From that early era of content owner-centric, CMS came a new generation of CMS platforms that provided competing levels of in-context authoring. Sitecore, Adobe, SDL Tridion, FatWire Content Server and Drupal became leaders striving to provide the most feature-rich in-context editing experience. Each release was a testament to that goal. Were they perfect? No, and in some cases not at all! But they made a concerted effort, and each release was a step towards a better user experience for one of their prime customers: the content author.

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

Where Are We Now With Content Delivery?

A host of new headless CMS products have flooded the market, many under the umbrella term DXP. Each is touting its technical chops and written eulogies about the death of the monolithic CMS. With headless, microservices and decoupled being the mantra of this era of DXPs, the authoring experience has taken a step back in importance and focus for many popular headless platforms.  

That isn’t to say that a headless or microservice approach is terrible — it’s not. It’s excellent, allowing separation of many content management-related concerns. In the old days, we called that “decoupled” or “baked, not fried.”

baked decoupled cms

A “baked” big-bang approach — with entire websites published at once — was plagued by a lack of interactivity with other systems (like, log in or, for the more daring, personalization). This gap was filled (at least partly) by asynchronous JavaScript. However, a series of high-latency APIs from some systems were often unwieldy and required large amounts of bandwidth and computing power. JavaScript was not a panacea.

During the early 2000s, many ergs of energy went towards convincing organizations to move their content production out of developer-centric software development life cycles (SDLCs). This unwieldy approach, a seemingly never-ending back-and-forth of copy editing between content authors and developers, was painfully slow and error prone. We called this the content liberation era and have happily moved beyond it, focusing more on feature richness and continued usability improvements. 

Today we are presented with a slew of headless, SaaS, microservices-based content platforms that have little to no real content authoring capabilities. They take us back to the early days of CMS, where content authors had to rely on the patience of technical users to explain, train and even enter their content. The visual look and feel of the digital experiences, being built separately, purposely, heavily impeding the ability of a content author to see what the experience would look like before publishing. Many workarounds have been, and continue to be, created to fill this gap. The result? We’re now starting to see a resurgence in demand for content authoring tools.

By way of example, one of the leading new-era content platforms, Contentful, launched its editing experience called Compose in 2021, seven years after the launch of its core product. In my opinion, this is by far the best editing experience across this new breed of platforms. Yet, it took them seven years — seven years! — to recognize that one of their primary audiences was being completely underserved (read, overlooked). While more established DXP’ who have spent many release cycles focusing on this need are being pushed aside for technical agility.

Related Article: A Trip Down WCM Memory Lane

Headless DXPs: Well Designed? or Hacked Together? 

There is no one-solution-fits-all when it comes to content management. Similarly, no one technology will fill all gaps for all organizations’ content management needs. For some, a traditional CMS, with all body parts attached, will be the right choice. For others, headless DXP will be a practical solution. 

That said, this extended development cycle and sudden about-turn provides some food for thought to those considering their next CMS/DXP investment and begs the question: Are today’s headless DXPs really headless — or more of a Frankenstein’s monster?

Dustin Collis, Sr. Director of Content Solutions at EPAM, has more than 20 years of consulting experience, focusing on enterprise clients with critical business needs in the digital marketplace.



Source link

We will be happy to hear your thoughts

Leave a reply

EvoCalmed
Logo
Shopping cart