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.
- Customers evaluating a specific CMS or embarking on a market search. This guide attempts to explain, in the broadest possible terms, the full range of modeling features you might find in the market. If you have no idea what questions you should ask or what features you should look for, this guide will help.
- Content strategists tasked with developing content models for a variety of target CMSs. Knowing how different systems might manifest the content models you create can help you understand an existing CMS or educate your clients about what features they might need in a future CMS.
- Vendors initially developing a new CMS or continuing to develop an existing CMS. Perspective is good, and it’s helpful to see what features and capabilities exist in other systems.
- Architects and developers who want to better understand the genre of tools they work with every day.
- CMS geeks who just want to talk about CMS all day long. You know who you are, and I feel you.
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:
- Like it or not, web content management (WCM or WCMS) is a huge part of this industry and will be for the foreseeable future. Yes, headless applications are growing, but the industry is still dominated by web-specific platforms.
- Web content management is a superset of other flavors of content management. A web system needs everything a headless system offers... and then some more stuff. So, in discussing WCMS concepts, nothing was ignored in the headless or enterprise CMS space. This guide still covers all that functionality, it just adds the web-specific concepts on top.
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.
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:
- For accepted concepts known by different names, I had to pick a term and go with it. “Type” is used rather than a “template” or a “class” (sorry Sitecore, sorry eZ Publish). “Attribute” is used rather than a “property” or a “field” (sorry Episerver, sorry Drupal).
- For more amorphous concepts, I simply had to invent terms. There are things we talk about and around in this industry that no one really puts a definitive name on, or they might be named in other contexts, but they’re not CMS-specific. When this happens, please just roll with it and know that I’m not trying to stake an intellectual claim when I make up nomenclature, but rather putting some semantic boundaries around a concept to make it easier to discuss.
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.
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:
- Interface design
- Information architecture
- Database design
- Web protocols
- General programming
- Development operations (“dev ops”)
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:
- Editorial workflow and tools
- Content optimization
- Multi-channel delivery
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 34 items.
You can use your left/right arrow keys or swipe left/right to navigate