Jens Oliver Meiert

What Kills and What Will Save Content Management Systems

Post from August 29, 2017 (↻ June 4, 2021), filed under .

Imagine you just moved into a new place, and realize that you lack a screwdriver to put up some of your furniture (it’s not from IKEA). You ring at your neighbors’, find one who’s home, and she, when you ask her for a screwdriver, replies, “sure, here’s my toolbox.” And you lug the toolbox up to the fourth floor where you live.

Now, what’s the problem with this short story? You have a kind neighbor, you got what you needed, so what else is here? It’s that you didn’t ask for a toolbox: You asked for a screwdriver. And that’s actually a problem with many of the friendly responses to our needs today: We don’t get tools, but collections of tools, even though no one asked for (all of) them.

We can work with the metaphor a bit more. You have a lot of work to do when you get a toolbox instead of a tool (carrying it here and there and such). You have more responsibility, too: You need to make sure that you handle the whole thing the right way, and even if you know where the phillips is, you still need to make sure all the rest of the tools stays put, and that the box stays shut (and that you hand it all over, and not only parts, when you’re done). The generous neighbor, although this doesn’t translate that well, will need to do more to keep an eye out, too—all her tools are on an off-site at the moment, and she needs to remember their whereabouts.

The Problem of Making a Toolbox out of a Tool

What has happened in the content management landscape is that former tools, publishing tools, have exploded. (I’ll be intentionally vague in terms of not naming particular publishing tools, for I believe this has happened to most of them.) They have exploded in that they used to be quite specific tools, but have grown into “one size fits all” toolboxes.

There, then, is where we find a great irony: Content management systems have exploded so to become the very reason that these systems, just like like web frameworks, shouldn’t be used—they try to address too many needs, and by doing so they cease to address needs well.

The moment CMSs started to meet more needs, they really began to meet fewer needs (the paradox of good intentions), and this issue actually rears ugly heads in all directions: The CMS provider has to develop more, test more, document more, maintain more, and while growing dependencies make this a logarithmically more complex and more expensive task great care has to be taken to keep the system usable.

The CMS user, or site owner, first stoked by the illusion of more power and control, has to expend more effort to understand the system, not just for simple usability reasons but also for very practical ones: to get the best out of the system and not, for example, use plugins (WordPress lingo) where the system already has an answer.

The end user foots part of this bill, too, by downloading an ever growing amount of assets, HTML output, the CSS framework, the JavaScript library, the font files and some polyfills and then some third-party stuff from maybe not even needed analytics solutions to advertising and tracking things.

No one wins when we do too much (which, from my experience, is a life lesson).

What Can Save the Toolboxes

In one word: customization.

The only way through for content management systems is customization.

It’s the same solution for them as it is for frameworks (where we’ve mostly called this tailoring) and libraries, because the problem we’re discussing is also the same: ignorance of needs meaning bloat.

The customization for CMSs, or toolboxes, or tools, will look a little different than for frameworks, however, as a wizard generating the code to be used won’t alone do, which will bring additional changes—complications—for CMS development and maintenance.

This customization process will mean wizards to modify, at the same time

The wizard has to offer all of this to be focused and relevant for the CMS user as well as for the end user: The CMSs of the future, the toolboxes of the future will be customizable. Sprinkle some machine learning and artificial intelligence over it and the CMSs of the future will be intelligently tailored content systems.

❧ The end result, then, will be much better—for more specialized and more efficient—than what we have today. Good toolboxes will be much simpler and faster than the ones we know today, and with that provide better experiences. And yet they will be incredibly more difficult and complex to build and maintain, for what will really happen, or need to happen, is to move all those decisions and guesses toolbox users have to make today into both effective wizards and more intelligent need determination and system maintenance processes.

To return to our neighbor story, the moment you had said you wanted a screwdriver, the neighbor should have handed you all you truly asked for—a screwdriver. Of the size you needed. And not her entire toolbox. That’s the only way our toolboxes, and truly no matter whether that means content management systems or frameworks or libraries, will stay relevant and at all useful—because otherwise, quality-wise, we better do everything ourselves.

Tweet this? (If it changed your life, you delight me with a coffee.)

About Me

Jens Oliver Meiert, on April 29, 2020.

I’m Jens Oliver Meiert, and I’m an engineering manager and author. I’ve worked as a technical lead for Google, I’m close to the W3C and the WHATWG, and I write and review books for O’Reilly. Other than that, I love trying things, sometimes including philosophy, art, and adventure. Here on I share some of my views and experiences.

If you have questions or suggestions about what I write, please leave a comment (if available) or a message.

Comments (Closed)

  1. On September 4, 2017, 11:31 CEST, Ingo Keck said:

    Thanks for this post. I think you have made some strong points, though I believe the problem underneath feature-bloat is different and that AI is not going to help us there. I summed up my arguments [at Medium.]

  2. On September 4, 2017, 16:27 CEST, Jens Oliver Meiert said:

    Thanks Ingo! After reading your post I just wish to clarify that the idea behind AI here is that it could help tailor CMSs (and their code) to better suit the specific needs of each user—why not even in production, by letting unused features “fade” both from the UI and the CMS code? That certainly needs more thought but I believe there to be quite a few possibilities.

Read More

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.

Cover: The Web Development Glossary.

Perhaps my most comprehensive book: The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.

Stay up-to-date? Follow me by feed or on Twitter.

Found a mistake? Email me,

You are here: Home → Archive → 2017 → What Kills and What Will Save Content Management Systems

Last update: June 4, 2021

Professional frontend developers produce valid HTML and CSS.