CMSs Are Dead - Long Live CMSs!

3 years ago

I've been unsatisfied with Content Management Systems (CMSs) for many years now. On one hand, they save a lot of content-management work (text, images, files, etc.) which is great if you are working on a marketing-oriented website. In that environment, managing content is 90% of the problem. On the other hand, when you start addressing the other 10% (styling and behavior), it can be quite difficult to achieve the simplest things if your need wasn't foreseen – and provided for – by the CMS developers / template creators.

Traditional monolithic CMS platforms like WordPress have to make many assumptions. These assumptions help when your needs match them but make things quite difficult when they do not. More modern systems like SquareSpace try to make fewer assumptions but then mishandle the resulting complexity -- which tends to fall squarely into the laps of content managers, requiring them to think and act like developers. And the situation gets much worse when the behavior need scales to the level of a custom application mixed into a CMS (a situation I encounter regularly). You typically have to jump through a crazy number of hoops to inject code into the CMS environment, or you end up with a CMS that is so customized that it can't be upgraded when a new version rolls out.

The typical workaround is to isolate the problems and needs from each other. Many deployments take the approach (which I've used also) of placing marketing content on a dedicated, stock, CMS platform, and any custom behavior on a separate custom web application platform. While this does a great job of separating concerns and simplifying the situation overall, it does come with higher cost and an increased maintenance burden.

Unsatisfied with this situation, I began exploring what the ideal solution would look like.

Wonder Twin Powers, Separate!

I believe the fundamental problem with CMSs is they tie management of content too closely with presentation of that content. The technology approach to presentation (almost always based on some form of templating) is often handicapped by how the content is structured, accessed, and stored. On the other hand, the structure of the content tends to be inflexible in order to standardize how the presentation works. Fundamentally, pushing these two problems away from each other should result in fewer constraints on each and allow solutions with better design and UX to emerge.

My first pass at a solution took a block-oriented approach where blocks were organized hierarchically and defined major content abstractions (images, text, sections, etc.) for rendering in a custom application context, but allowed a content manager to control the order in which they were presented. Both were implemented within the same application framework but with the desired separation of concerns. I used the result to implement my own business website, Data Bakery.

It worked well and made building the presentation side easier (more like a custom application driven by data) while giving the content manager a simplified view of content that didn't burden them with unnecessary details. However, after working with it for a while, I realized that, for this approach to scale to large projects, it would need a metadata system for defining and describing the blocks. As anybody who has ever implemented one knows, a metadata system requires a considerable amount of work that is hard to justify outside of the context of a product development effort. Also, the block structure was indeed flexible and powerful, but it really needed a constraint system in order to ensure valid combinations so that the presentation side could be simplified.

The Headless CMS (Not from Sleepy Hollow)

Around this time, the concept of "headless CMSs" began to emerge and become popular. While the headless CMS aligned with my first pass philosophically, its reality suffered. The first headless CMSs tended to be clunky, expensive, and a performance concern. I took a second pass at my solution (again on my own business website) that 1) simplified the block types so that a metadata system wouldn't be required and 2) moved block organization into the presentation code since organizational flexibility wasn't often utilized. The result was even simpler to implement on the presentation side and simpler to manage on the block side – but the reduced flexibility of the approach was fundamentally unsatisfying. I chalked it up to the constraints of the development scenarios that I regularly encountered.

Fast-forward a few years, and the concept of headless CMSs has evolved into a powerful paradigm that finally felt like the correct concept. The best-of-breed headless CMS manages content using metadata-based descriptions in a way divorced from presentation while custom applications (web, mobile and desktop) implement custom presentation of that content divorced from how the content is managed. The separation of concerns had finally been clearly defined. But giving content managers the ability to organize that content in the presentation still had not been addressed.

Then I found Storyblok.

It's Bloks All the Way Down

Storyblok struck me as different from most headless CMSs in that it both supports a metadata content system and a hierarchical block system – which I believe are key features of any ultimate solution to the CMS conundrum. Discovering Storyblok brought that solution into sharp focus for me: addressing the content side with an off-the-shelf SaaS solution that can afford to build a best of breed UX around content management combined with building custom applications to present the content.

So, I took my third pass at it and rebuilt my business website again, this time using Storyblok. As the saying goes, third time is a charm. Storyblok has done the hard work of implementing a powerful metadata system for content and solving the hardest UX problems around hierarchical block arrangements of that content. The presentation implementation has the least code of any iteration making it easily incorporated into larger custom web applications.

Final Thoughts

The experience of converting to a Storyblok implementation uncovered an unexpected benefit. The process involved – and clearly benefits from – a thoughtful setup of content types. My recommendation is to start with the smallest number of high level containers you can. Then decompose them into further containers only as needed. While it would be counter to the entire concept of a headless CMS, you could decompose them down to matching HTML tags one-to-one if it were truly necessary.

This approach allows you to dial the level of abstraction and control to the right spot on a project-by-project basis. Working with a content creator who doesn't handle technology well? Then just define some high level bloks with text fields that don't support any organization. Working with a more analytical type who is a tech natural? Decompose into further bloks that both allow them to organize as needed but also exert more control over the presentation.

After many years of griping about the difficulty of working with CMSs it feels like I have finally come across the right solution. I guess I'll have to find something new to gripe about (looking at you, AI...).