On Not Building a CMS…

I’m tempted to write a book (or a website?) called, simply:

“How to Build a CMS”

It would be a comprehensive, ground-up discussion of how to build a CMS from scratch, detailing all the things you need to think about to build a system to manage and deliver content effectively.

(We wouldn’t be pedantic about the definition of “CMS.” It’s a “big tent” book. Relax.)

We’d need to settle on a couple hypothetical use cases. For each, we’d walk through the areas of content modeling, content aggregation, editorial tooling, output management (ha! I snuck in my “Four Pillars of CMS” model…) and beyond, explaining what you need to think about, both now and in the future.

But we actually wouldn’t even start with something as pedestrian as content modeling – we’d start all the way back with usage and needs. What problem are you trying to solve? Why do you want to build it?

We’d explain how a modern CMS is “stack” of a series of tools, and how options exist for all layers of that stack. Are you just gluing layers together (probably true for all programming, really), or is there some layer you’re actually going to build from scratch, and why do you think you can provide extra value at that layer? Do you just need to customize an existing CMS? Are you just making a flavor or something else?

We’d explain how a CMS – all software, really – is either a reflection or a re-definition of work process and usage. Are you supporting an existing process? Or are you defining a new process? Are you following your users or are you leading them? Are you building both a CMS and a…philosophy?

We’d explain that every CMS is a balancing act between flexibility and simplicity. Do your users want to work in defined channels, or are you building an “open world” in which they can tinker? What level of opinion are you going to build into it? And if none, will it slowly melt into incomprehensibility?

We’d explain how users react to blank slates and ultimately flexibility – that everyone says they want it, until they see it, then they’re often bewildered by it. We’ll talk about “load-bearing walls” and how you need to build immovable pillars into your system to hold it up, but there are all sorts of other ways to build movable features in and around them to make the system customizable.

We’d explain that a CMS is fundamentally about boundaries. We impose boundaries – that particular value HAS to be a valid date, for example – in order to achieve other goals like aggregation, administration, and presentation. We’re essentially fighting a never-ending battle to make data (content) comply with rules so that it’s predictable and boring and expected.

…and maybe then we’d start with content modeling.

…

Someone please talk me out of this.

(Bonus content: at the end of the book, if you still wanted to build a homegrown CMS, we’d have a directory of therapists and counselors in your area so that you could find someone to talk to about your life choices.)