Who is a CMS for, nowadays?

When we talk about CMS, we are thinking about systems that allow us to manage content. This usually means updating, deleting, and adding new content. These systems have been with us for a long time and have been, ever since what marketers called "Web 2.0," a cornerstone of the web. Their role on the web platform has evolved over the years, though, and so has what people and organizations expect of it and what they use it for.

Authoring the Web

While the web as a platform was always meant to be built on by everyone, not just people versed in programming paradigms with a dedicated education, it presented a significant barrier to many people and organizations. In a time where dynamic web development was not yet the norm, updating content meant updating HTML documents.

In these times, managing content requires, for the most part, understanding HTML and adjacent systems. Often, "webmasters" not only translated whatever required content from one medium to the web but were also involved in creating content themselves.

While HTML 3 eventually introduced some concept of modularity with frames, and systems for editing content certainly emerged during this time, content was still created and edited statically until PHP and MySQL eventually made dynamic web development the new default for making websites.

Dynamic Web Development?

The term "dynamic web development" has become a bit elusive nowadays. We're now using it often to refer to it as a synonym for "interactive," but it usually means that instead of serving an HTML document as is, statically, it instead gets dynamically built by the server based on the request that is being made to it and then served to the client.

The popularity of the LAMP stack and its ubiquity in shared hosting was an ideal, fertile ground for systems that allowed for systems to be created that focused on managing content. Websites were built around these new monolithic CMS systems, but the ability to update content separately from having to update the website code opened up content publishing to a wider audience.

Publishing on the Web

In these times, web development and its processes, as well as content management itself, were aligned around the limits and capabilities of the CMS that was being used. WordPress eventually emerged as the dominant system in this world during these times. Its architecture of plugins and themes not only shifted a lot of autonomy to site admins and authors without requiring too much technical knowledge but also popularized the idea of decoupling presentation from content. That way, it mirrored the idea of separation of concerns, which has long been an important paradigm in web development, even though where we see separate concerns is certainly changing nowadays.

For the first time, established editorial processes found some congruence with content editing on the web, ultimately allowing them to make the web not an afterthought but an integral part of content publishing. Yet the requirement to make a CMS the backbone of a website made developers a secondary target audience. CMS that worked well for web development rarely worked well for authors. This eventually changed with the rise of the Jamstack as the new default.

Off with their heads!

What was once known as AJAX eventually made the client side JavaScript rendered SPA the new default for the web. Instead of needing a CMS to return an entire web page, we could now handle its data and render it on the client itself. This further separates the content from the website itself. How content is presented can now be entirely separated from how it was written. CMSs that support this approach are referred to as "headless."

It coincides with an era that understands websites more as applications and thus treats content as a secondary concern. This comes with a lot of freedom for developers, and it coincides with the industry's focus on DX ("Developer Experience"). A website may change entirely, but its content may remain identical. This allows those who work on content to be less reliant on development while also becoming more reliant. Changing content might not necessarily result in an update on the website unless implemented specifically.

But at the same time, it allows content to become its own separate concern, for which a website is just one publishing channel but not necessarily its source of truth. This way, creating and reasoning about content can become a separate discipline, allowing people with dedicated skillsets to flourish without having to align with the capabilities and limitations of a monolithic CMS. Yet because content is so separated from its context, content authors have no control over many presentational aspects of their content, including their URL, unless developers specifically develop with these requirements in mind.

While separation of concerns is a feature that has been serving the web platform for decades (and continues to do so), when it comes to content, in some situations, it may fail us. Meaning is given in context, and for content, this context is the experience in which it is being consumed by readers. The ability to influence this experience through the content itself is critical to the autonomous movement of any team working on this content. They need to not be too dependent on time-consuming and cognitively intense planning; instead, they need to move at a speed that allows them to learn about what they are doing as they are doing it.

Components meet content

As a specific piece of content is created, we understand more about its subject, and this understanding may have a recursive impact on how we create this content. This is what is usually referred to as a hermeneutic spiral. Creating content for a website is very often an explorative process in which what we are trying to convey and how exactly we're getting where we need to go are revealed to us as we dive into the subject matter.

This is where it becomes crucial that we consider the visual building blocks that our content is delivered with. WordPress knew this and brought the block-editing experience to its editor with the Gutenberg project. Separation of concerns is being rethought in the age of componentization on the web, as we see the concern of the content and the concern of its representation as one singular concern. The result is a mental model and a workflow that abstracts more individual units of content and design into components, or blocks, that can then be composed together.

On the development side of things, in its most ripe form, components are getting designed and developed in isolation from the context in which they're being consumed. And this workflow is entirely consistent with using blocks in Wordpress. So it made sense for competitors to pick up this model. Storyblok is one of those CMSs that focuses on providing an entirely block-based model, which also coincides with the rise of the omnichannel CMS.

Omnichannel is a marketing term that refers to delivering and marketing content via all relevant channels. The idea of an omnichannel CMS is to provide publishing to a variety of channels from a single source of truth. And the fact that current-generation CMSs, like Dato CMS, Storyblok, and Agility CMS, are marketing themselves as omnichannel CMSs shows a change in demography for using CMS.

So. Who is it for?

In general, a CMS is for everyone who sees value in adding, changing, and deleting content separated from its development workflow, in varying degrees. Whereas in the early days, it was safe to assume that content editors were skilled enough to work with HTML, nowadays that is no longer true. We're in the era of headless CMS, but they are moving their interfaces to their own platform and offering themselves as a service, allowing users of CMS to require less knowledge to use it effectively. And while many of the people needing to just edit their website content autonomously are nowadays often better served with a platform like Wix or Squarespace, those that need more are served with CMS that increasingly move towards a model that is shared between development and marketing teams.

What we require from a CMS is determined by how we work with content, who works with content, and how we develop the website in which the content resides. And all of these things have severely changed and will continue to change. So it is only natural that CMS, as important pillars in this cycle, also change to cater more towards who profits from them at a given time.

Today, CMS are speaking primarily to the needs of developers because the non-technical user has moved on to WordPress, Squarespace, Wix, Weebly, or even Webflow. Users of our current generation of CMS are frequently found in groups, and thus in businesses. and their needs are somewhat different. CMS like Storyblok, Agility CMS, Dato CMS, and even Hubspot CMS or builder.io demonstrate their focus on marketing teams while still trying to cater to developers.

So while a CMS is for everyone who finds it useful, their primary target audience has changed from empowering non-technical users to catering to developers and marketing teams primarily. And with time, it is to be expected that this will change too.

Header Image: Photo by Glenn Carstens-Peters on Unsplash