Conclusion

Did you ever wonder why people get crazy about beer, wine, coffee, or cheese? I study cheese a bit, and I’ve been amazed at the heights to which some amateur cheesemongers have scaled. Some people analyze it like they’re trying to get a PhD in cheese.

For others, the contemplation of wine is like a monastic commitment, and only death will stop them from their pursuit of knowledge and experience.

On the opposite side – you never find a “Diet Coke expert.” No one ever bothers to study Diet Coke. They don’t give any awards or titles for this.

This is because of context. Specifically, some disciplines are “high context” and others are “low context.”

Context is:

The set of circumstances or facts surrounding a particular situation.

The event of tasting wine has a lot of context. There are hundreds of inputs into that moment, from the type of grape to region of the world to the type of soil it was grown in (the “terroir”) to the exact moment the grape was harvested. A glass of wine represents the sum total of hundreds of years of history, perhaps dozens of years of preparation and storage, and even the prior few moments of presentation and service. There is simply so much context that impacts how the taste of wine is perceived.

Diet Coke is…Diet Coke. All you can do is take a sip and declare, “This tastes like every other Diet Coke I have ever had.”

In fact, Coca-Cola spends billions of dollars every year to ensure that every single can of Diet Coke tastes exactly like the last one. There is nothing to contemplate when drinking a Diet Coke. There’s no mystery to unravel. It’s a cognitive dead end. It’s incredibly low-context.

Over the 30-some-odd chapters and 50,000-some-odd words in this guide, I hope that I’ve demonstrated that the practical aspect of content modeling is an incredibly high-context activity. The level of subtlety and nuance involved with making a digital representation of real-life concepts is impacted by dozens of different factors, any of which can magnify a small change and spin the path off in a completely different direction.

We like to think our ideas are exempt from practical implementation details. We have high-minded theories of our content that we’re convinced will “just work” because they make perfect sense in the theoretical world of boxes and arrows we created in our favorite diagramming software.

Eventually, you have to manifest your theory inside an information system. That can be a painful reality check.

The only effective content model is one that has been implemented and has thereby suffered through the natural process of reconciling its theoretical ideal with the realities of the system in which it must operate.

I’ll conclude by returning to a theme from the introduction – no system is going to do all of this. I don’t think any one system ever could. There are architectural paradigms discussed in this guide that simply could not co-exist. Occasionally, there are simply opposite ways of doing things, and neither is wrong, they’re just different.

Throughout this guide, there have been several themes:

• A CMS is a direct, practical limit on how you can model your content; everything you do will be constrained within the functional box a CMS imposes
• There is a constant tension between what is and should be built-in and what is custom – the platform-product dichotomy is a subjective balance
• A key goal of the content modeling capabilities of a CMS is to increase resiliency by protecting content from inadvertent corruption
• A CMS is instrumental in creating good content because it can add to or detract from editorial usability, and happy, confident editors make better content
• Missing features can often be reconstructed using a inventive combination of other features; sometimes, a larger pseudo-feature can “emerge” from a combination of other features
• A well-architected API can help fill content modeling feature gaps
• There is a clear dichotomy and philosophic separation between what an editor should be able to accomplish with and without development support; where this line is actually located is different for every scenario

The goal of this guide was to present a broad spectrum of features to assist in getting your arms around the solution domain in the broadest possible sense.

More specifically:

• I wanted you to think about your content model or content domain in more concrete terms, and consider how any aspect of a theoretical model might be supported by solutions actually in the marketplace.
• I wanted to help you understand and articulate the questions you might ask when evaluating a system.
• I wanted to lift the covers on the most basic of CMS features and show you some of the depth and nuance involved in their implementation.

To whatever extent possible, I hope I succeeded at those goals.