About this Guide

I started writing this guide one Sunday morning before church. It was supposed to be a blog post. A few months prior, I wrote a post about the lack of a modeling standard in CMS, which got quite a bit of traction.

This eventually led to a conference call with some very smart people about what we might do as an industry to move forward. It got me thinking perhaps someone should just write a draft standard (because nothing gets people talking productively like a concrete thing they can criticize).

The original idea of this guide was to paint a picture of what a standard might look like. My goal was to promote some level of interoperability, so that content systems might acquire some degree of similarity at a base level. The hope was that this would make it easier for systems to exchange content.

However, a few thousand words in, it became apparent that I was completely wrong with how I approached it. For interoperability, we’d need to standardize the external interface of a model, while what I was writing was about the internal implementation of the model. (I address this more deeply in the postscript.)

And by the time I realized that, I was having a lot of fun talking about content modeling feature implementation, so decided to ride that theme for a while. Many tens of thousands of words later, here we are.

Who This Book is For

There are a few audiences who might find this guide helpful.

Web vs. Other Channels

Some parts of this guide are web specific, which doesn’t mean we’re ignorant of headless and enterprise content management branches of this industry.

Addressing the peculiarities of web CMS is unavoidable for two reasons:

If your application isn’t web specific, you’re free to skip those parts. It’s not a lot of extra, however, so read it for some perspective and because you might find those parts more applicable than you think.

On Definitions

The content management industry has no central, governing authority, so we lack an accepted vocabulary – not for lack of effort; see The Web Content Management Glossary.

For this reason, there’s a few things to be aware of when reading this guide:

A couple other notes about language and terminology:

I believe the plural of “CMS” is “CMS.” The “S” can stand for either “system” or “systems.” However, for my first book, I was over-ruled by my editor. I’ve complained about this publicly, but have come to accept grammatical purity is trumped by common understanding, so “CMSs” it will be.

The word “system” is used a lot. In almost all contexts, this means the same as “CMS.”

Finally, this guide is explaining general principles spread across many different software platforms (again, like my first book). With this in mind, I will exhaust all sorts of qualifiers (e.g., many, most, some, often, sometimes).

I hope they’re accurate (i.e., “most” should always mean more often than “some”), but take them for the vague qualifiers than they are.

Adjacent Disciplines

When you discuss content modeling deeply enough, you’ll inevitably start to drift across discipline boundaries. Beyond modeling, for example, I touch on the following disciplines in this guide:

I try to call this out when it happens and pull back before falling too far into the weeds when crossing boundaries to explain a concept. My hope is your eyes don’t glaze over before I get back on track, but no promises.

The same is true of other domains of functionality within a CMS itself. By the time you finish this document, we’ll have covered quite a bit of ground about CMS architecture and functionality. As you read, know we are adhering as close as possible to the disciplines of content modeling.

For example, here are things we’re not going to cover directly:

There’s something about all of those disciplines in the coming pages, but only as they relate to content modeling. Entire books have been written about each of them, but we’re only concerned with how they might intersect with the ways a CMS supports a content model.

How This Book is Structured

The “reverse pyramid” model of journalism says a story should start with the most general concepts and get more and more specific, so a reader can quit without finishing and still walk away with the most important information.

I tried to follow this model. This guide gets progressively deeper and more esoteric as we go.

There are a lot of chapters, and they’re short. Each one is dedicated to a specific feature or concept. They will start with the most basic questions and move down the list to features that are more uncommon and specialized.

Occasionally, I’ll take a “timeout” to discuss a general concept that doesn’t quite rise to the level of pure evaluation, but is helpful to understand for context.

At the end of most chapters are some evaluation questions you can ask system vendors to help understand their capabilities, or ask yourself to test and guide your understanding of your own system.

The earlier chapters were easier to write. Basic content modeling features are common enough to have developed accepted conventions around. However, as the functionality got more and more advanced, some of it got harder to write. When discussing a feature not in every system, I started having to take more leaps.

In most cases, I’m describing features I have actually seen. In other cases, I realized I wasn’t describing a feature I had observed as much as I was describing a feature or architecture that made sense to me in a perfect world. If everyone did everything correctly, this is how this should work and wouldn’t that be great?

Occasionally, I thought I remembered some particular functionality from a specific system, then, upon further research, discovered I was misremembering it. However, the feature would have been fantastic if my memory had been accurate. I discuss those mythical features too, in the perhaps vain hope all my functional dreams will come true one day.

In other situations, I frame functionality as questions to which there might not be a valid answer. Some logical situations present paradoxes and intricacies that can’t easily be solved with technology, so some questions are simply open-ended and left to you to relate to your own situation.

This leads to the inescapable point: no one system will embody everything in this guide. If you’re looking for a system that does everything here, you’re going to be disappointed.

Some systems do more than others. In this guide, I have the freedom of both piecing together the best parts of every system I’ve ever seen, and then extending that by describing a hypothetically perfect system no one has ever seen. This guide is both realistic and theoretical at the same time.

More than anything, my ultimate goal was to introduce questions and paradigms of thinking about modeling solutions that expand your perspective on the discipline.

This is item #2 in a sequence of 35 items.

You can use your left/right arrow keys to navigate