How a CMS Helps (Or Hinders) Your Content Model

As I mentioned, I’m not going to go deep into why we create content models. This guide assumes you already understand why you need a content model and the value it brings. What we’re going to talk about in this chapter are the principles of a model that a CMS can make better or worse, depending on the features it offers (or doesn’t) and their relative competency.

But first, some theory.

The Theoretical Basis for Content Modeling

Content modeling is the accumulative adding of value to raw data.

In my masters course, I define information as “data with context.” We take raw data and – in a gross over-simplification – we put labels on it.

“3” is a datum.

It’s clearly a digit that exists on the numeric scale. We know it’s more than “2” and less than “4” but we don’t know anything else about it.

It could be the number of ice cream cones I ate last week.
It could be the number of U.S. Supreme Court justices who attended Harvard.
It could be the number of children I have.

In fact, it’s that last one (I didn’t eat any ice cream cones last week, and five of the nine current SCOTUS justices attended Harvard).

By putting a label on this, we’ve moved from a raw datum to information:

Number of children Deane has: 3

This datum now has interpretive value. You can draw personal judgments about what this means about me and my family situation. And you can relate it to other values, like the average number of children of the American family and draw judgments about what this means.

Information is data with labels. Something as simple as a label adds context – “the circumstances surrounding the thing.”

We can add even more information to a datum in ways other than just labeling – we can do it by adding structure.

What if we had a list of text strings labeled “Names of Deane’s Children in Descending Order by Age”?

Alec
Gabrielle
Isabella

By creating some structure, we’ve further increased the value of raw data. Now, in addition to knowing the number of children I have, we know their names and in what order they arrived.

How do we know their names and the order they arrived? Because that’s the label we put on it. The label isn’t just decoration. Rather, we’re explicitly establishing some context for this data. We’re telling the information consumer what this thing is. We could change the label to “Deane’s Pets” and now it would mean something different.

As obvious as this sounds, things are what we say they are.

Our CMS helps us maintain this structure. It can give me a little editing widget to “Add a new child,” and it can reject my entry if I leave it blank.

This type of modeling is discrete, meaning it’s wholly contained in a single object. We can do this relationally as well. If we’re working with content type called Person, we could define a property called “Spouse.”

[reference to a content object representing Annie Barker]

By modeling that relationship, we can now traverse our content model. We’ve created a graph, and we can transition from one object to another with some idea of how they relate. That link creates value in itself – not only does it identify the other object, but by virtue of the label, you also know how we relate. The property isn’t called “Dentist,” it’s called “Spouse,” and that gives you more information.

Since this is a link, perhaps our repository system can offer me a “content finder” to go looking for Annie’s content object.

As my life progresses, our content model gives us some resiliency. For instance, bigamy laws being what they are, we might enforce a validation rule ensuring I can only have one link marked “Spouse” at any one time, to ensure I don’t have two of them.

All of this content exists inside an information system of some kind. It’s only as good as it can be represented and modeled inside that system – how we can label it, structure it, and work with it over time. The functionality that systems provide for this exists on a wide scale, and is the subject of this guide.

The Benefits a Content Model Offers

What the last section intended to illustrate are the four principles of a content model that the features of a CMS have a direct impact on:

Descriptiveness: A content model is fundamentally a description of content. A CMS helps or hinders the quality of this description. A poor CMS will make our description crude and low-fidelity. A good CMS gives us the ability to paint a more accurate picture about what our content is and what it should be used for.
Usability: A content model is only as good as the content that goes into it, and an editor’s ability to create good content is deeply dependent on the tools they have to work with. A good CMS will use the defined model to offer optimized interfaces that encourage editors to create quality content.
Resiliency: A content model that’s perfect in theory can be quickly destroyed by a CMS that doesn’t protect it. A poor CMS will allow editors to violate the rules of the model – the model is said to be brittle. A good CMS will prevent content from being created or edited in an invalid state, so other people and processes interacting with the content can trust it’s a stable and predictable format. (One could almost call this principle predictability, since the goal of resiliency is content that doesn’t deviate from the expected model.)
Manageability: A content model might be complex, and it will usually always change over time. A poor CMS encourages bad management practices that turn an initially perfect model into a jumbled mess. A good CMS can help a content strategist, editor, or administrator maintain their model; keep its definitions clear, concise, and understandable; and make changes orderly, precise, and predictable.

The four concepts comprise the core of what content modeling is. It’s the process of –

Enriching data by putting labels and structure around it
Configuring the CMS to allow it to assist editors when working with it
Enforcing rules to prevent content from existing in an invalid state
Keeping this clear and understandable, both on initial launch and over time

Since the raw data isn’t known in advance, content modeling is the creation of a framework of rules on which to “hang” future data to provide more value. It’s like city planning – you design a structure for maximum use and future value, then watch as your city grows into it.

Again, these aspects are not about the design of content model itself. The competency of the model is an independent variable – you can still come up with a terrible content model, even if it’s implemented in the world’s most capable CMS.

However, the competency of the model isn’t under consideration here. We’re assuming you had the assistance of a competent content strategist who designed a content model to fit your needs.

All we’re concerned about within this guide are the CMS tools to support whatever model is specified, measured by how those tools contribute to the four core principles.

The discussion of a rules framework inside which content “grows” has me thinking about SimCity, which was one of my favorite video games for years.

SimCity is a game about city planning. You develop infrastructure – streets, power plants, zoning rules, etc. – and then your computer people grow a city inside that framework. As this city grows, you need to adapt your infrastructure to accommodate what they do. You need to add new streets, increase power output, find new ways to deliver water, etc.

I loved this idea of guiding an autonomous and growing system of interactions. I used to set up infrastructure, watch the city grow, then reset the game, adjust my infrastructure, and start it again to watch how the “people” would react and adjust. I was fascinated by complexity theory before I even knew what that was.

Over the course of this guide, I hope you’ll come to see the parallels for your content model. You are defining the rules of the content game for your editors by using the tools of your CMS to keep them safe and serve them effectively. You goal is to use these rules to allow them to thrive.