What Kills and What Will Save Content Management Systems

Post from August 29, 2017 (↻ December 5, 2021), filed under  (feed).

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.

Toot or tweet about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

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

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!

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.