Introduction
When developing a content model, there are three challenges to overcome.
The first is understanding the value of a content model and what it can do for your organization. Most discussions about content modeling tend to concentrate on this question of “why”? We spend a lot of time explaining all the reasons we should model content in attempt to persuade someone a content model is a thing they need and should want.
This has already been done well. I’m going to let others keep fighting this battle.
But, once we’ve convinced people of the why, we run headlong into the second challenge: how do we actually create a model from a team and requirements standpoint? Meaning, how do we decide what types and attributes we need, and how should they all fit together?
This is a problem of discovery, analysis, team dynamics, trial and error, and dozens of other factors. Again, many resources have been written about this.
Assuming we know why we need a content model and assuming we’ve put together a good, logical plan, the challenge this guide is concerned with is the third one –
What tools do we actually have available to do this?
The answer to this one can be tricky. If you already have a CMS, then you have an existing toolset you need to work with, and it’s helpful to know what modeling functionality that CMS offers before you start planning.
If you don’t have a CMS and you need to acquire one, then knowing what tools you need helps inform the decision. Many teams don’t know what features they should look for, or what questions they should ask when they go looking. They end up with a system which is completely mismatched to what they were trying to accomplish in the first place.
Less Theory, More Reality
All too often, content models are developed according to abstract scenarios without any consideration of how they might be manifested in the (ahem) real world. Sadly, dreams of a perfectly matched model – and how it will benefit the organization – go out with window when the team realizes the system they have just won’t support all the effort that went into planning the model.
I teach an “Introduction to Content Management” course to students in the Masters of Content Strategy degree program at FH Joanneum in Graz, Austria. My course is in the last semester, and by the time the students get to me, they’ve been talking about content modeling for almost two years…from a content strategy perspective.
I open my lecture on content modeling roughly the same way every time:
“I’m here to rain on your parade.”
Why? Because, inevitably, you are limited by your tools. You can design the greatest house to ever be built, but if the only tools you have are dental floss and chewing gum, then you’re never going to construct the home of your dreams. Likewise, you can plan the greatest content model in the world, but if all you have to manifest the model is an ancient CMS from back when rich text editing was a big deal, then a lot of your effort will be wasted.
Sometimes you have flexibility in CMS selection – “we’re not going to pick a CMS that can’t support what we want to do!” Other times, the CMS is set in stone – if your organization has seven figures into a vendor’s solution, you can’t swap it out just because it doesn’t handle your model well. You may have to play the hand you were dealt.
Why Content Modeling Matters
Whenever I evaluate a CMS, I first try to figure out how it models content in general and what specific modeling features are available. I believe, above anything else a CMS does, how it models content is foundational – both for an obvious reason, and a subtle one.
First, and obviously, the tools a CMS offers for content modeling are critical to building a good content model. As I said before, if you don’t have a decent hammer, building a house is going to be difficult.
Second, and less obviously, the tools a CMS offers for content modeling are usually an accurate predictor of the quality of the rest of the system.
Content modeling is so fundamental that if a CMS screws that up, there’s a very good chance other parts of the system fall short as well. Content modeling is the gatekeeper to determine if the team who architected the system had any idea of what they were doing.
I’ve seen systems so deficient in basic modeling capabilities, that I just knew the rest of the system was going to be hopelessly flawed as well. Perhaps it was a self-fulfilling prophecy, but that initial impression never failed me.
CMS capabilities operate on a wide range. There are some commonalities, certainly, but beyond the basics, different systems offer a lot of different tools. Some are fantastic if you can find them, and others are superfluous or can be improvised by creative use of other features.
And small variations in how a feature is implemented can cause wide variations in usability and applicability. A seemingly minor change in implementation can cause a gaping functional chasm when trying to put the feature into practice. Sadly, by the time enough layers have been peeled off for these differences to become apparent, the software has been purchased, half-implemented, and there’s no going back.
What I think has been missing over the years is a comprehensive survey of the features and capabilities that different CMSs offer to allow content to be modeled.
This guide is an attempt to be that missing feature survey. I’ve worked with a lot of systems over the years and taken particular note of how they model content. What I’ve tried to assemble here is a broad view of everything I’ve observed in the market, and how these features might relate to common content modeling problems and scenarios.
The goal of this guide is to increase your fluency and ability to ask the right questions. Half of the problem with evaluating software is knowing the breadth of what’s possible. The only way to know where an option exists on the scale of competency is to understand the range and outer limits of the scale. You can’t decide what’s “good” or “bad” without knowing what those terms even mean in an absolute sense.