What Kills and What Will Save Content Management Systems
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.
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 CMS UI (if desired, speaking of headless systems)
- the CMS code
- the theme code (WordPress parlance)
- system updates
- theme updates
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.
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!
Maybe this is interesting to you, too:
- Next: What We Should Teach Up-and-Coming Developers
- Previous: 10 Photos V
- More under Web Development, or from 2017
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try 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.