Steve Jobs unveiled the first iPhone on January 9, 2007, which is often considered the beginning of the mobile revolution. This event opened a new area for digital content creators. However, the problem was that most CMSs available at the time were designed to manage one channel only.
This blog post is part of a series of articles about the evolution of Content Management Systems. showing problems addressed and problems left unsolved by the successive approaches.
Compromises: The Problem of two Webs
Firstly, CMSs needed to face the problem of two webs. The seasoned one, dedicated to serve personal computers. And the new one, dedicated to display content in browsers on mobile devices. In other words, CMSs needed to be able not only to successfully detect user's device, but also to follow very different content delivery requirements and diverging users' expectations.
The list of problems included:
- displaying images in proper resolution,
- composing paragraphs fitting mobile devices,
- meeting specific multimedia requirements,
- providing different layouts to display content.
In consequence, at first the quality of content delivery was heavily compromised. Monolith-type CMSs simply could not produce various high-quality outputs at once. Dedicated initially for desktop only, the content itself needed substantial changes when repurposed for browsers installed on mobile devices.
Applications and Syndications
To go around the problem of two webs, an idea of replacing mobile versions of websites with native applications emerged. When mobile internet usage began to exceed that of desktop around 2014, the content created for websites was still not useful as material for attractive, interactive, and engaging mobile apps. Usually, it just needed to be recreated from scratch and manually updated. In consequence, organisations had to maintain and update major digital communication channels separately, even though the content was virtually the same.
The next issue CMSs needed to face was syndication. As the Internet diversified and websites became more specialized, they divided into content providers and distributors. The former were focused on content creation and licensing, while the latter on publishing content curated by other parties.
As the diversification of the digital domain advanced, CMSs followed. They started to mark their fields of specialization, each of them dealing better with one of the digital areas. However, CMSs still had ambitions to be all-purpose tools serving websites, mobile, social media, newsletters, as well as prospective channels of presentation.
Separation: Management and Delivery
The need for separation of content management and delivery within CMS fuelled a fundamental change in thinking. Diversification of channels changed the game, and instead of the question how to adjust the desktop version of the website to the mobile device, or vice versa, a different issue was raised. Namely, how to create a system able to manage the content independently of the channel? The answer was headless CMS.
Even though the way to truly channel-agnostic, headless CMS was long, the perspective switch was necessary to finally find out that the layer of presentation is what differentiates individual websites, applications, content providers and publishers of syndicated multimedia. And each of these channels has their own rules of presentation, no matter what kind of content they display.
In consequence, CMSs of the early 10s were internally split into two complementary, but independent systems:
- the management system, and
- the delivery system.
It created a big opportunity of limiting manual adjustments, versioning, and multiplication of work when working on quality, branded content.
A contemporary management system is a solution able to manage and organize any type of files, and to describe them with metadata. Ideally, pieces of content are organized around central semantic nodes, related to each other, and organized around well-defined topics. This way a network of meaningful relations is built, and the content is prepared for efficient reuse and repurposing in multiple channels. It provides a well-designed outcome, that can in turn be passed along to a separate delivery system.
When the edition is finished, the delivery system adapts the output of the management system to publication requirements of specific channels. It is also the one in charge of constructing a personalized user experience of a website or an app.
Headless Problems: The Need for Presentation
In traditional CMSs, one of the major assumptions was expressed in a WYSIWYG formula, unfolding as what you see is what you get. In other words, a preview window was supposed to mirror a published version of a website. The major challenge in switching to headless approach can be encapsulated in the following question: how to work on content and its meaning with no specific publication form and channel intended? How to plan and preview the results in these circumstances?
The issue caused by separation of content creation and publication can be given a name of “a need for presentation”. Today, we are not able to effectively create content without imagining what it will look like. The tools to support us in this endeavour are insufficient and inadequate. When used by a person, a headless CMS needs to display the channel agnostic content in some default way, usually in the form of a website.
In consequence, the problem of the need for presentation is bypassed by "pseudo-headless” approaches to content creation. In each of them, the CMS user declares their channel of choice. For example, a desktop first, or a mobile first approach. However, all of the “pseudo-headless” solutions share some common faults. Firstly, their default preview influences the created content. Secondly, they obscure the major functional differences between the channels. We would like to point out that a content creator deals not only with content presentation, i.e., how the content looks on the device, but also with content orchestration. It can be understood as a process of making decisions about the ways presentation choices are combined with channel-specific capabilities and restrictions. Those don't have to be limited to different screen sizes and resolutions. Think of print media, in-store displays, stands, VR experiences, and many more, each with its own set of limitations when it comes to content length/size, interactivity (including sensory input and assistive technology), possible colour palettes, metadata formats, shapes and forms, and many more.
A lot of time and resources has been invested in the development of tools that help users make those decisions by providing high-fidelity previews. Looking at the broader picture, one could argue that the preview process itself is a byproduct of the decision process being manual and difficult to reason about, and not a goal in itself. If the whole process gets automated, the preview capability is not needed anymore. Instead, we can express content orchestration as a sum of simpler problems, ones of classification, recommendation, recognition, text summarization, etc. With the right tooling, the content creator’s role could be limited to reviewing the results of AI-powered content creation and personalization, with an understanding of both the channel and the intended audience. However, such an approach requires a new architecture of CMS, as well as further advancement of AI-related technologies that we will discuss in the next part of this cycle.
Hero image by Trinity Nguyen, opens in a new window
