Issue 18

Structure

Quick thoughts about how content lives in systems

Whether or not we realize it, content has a shape and structure so that it can be applied as information and knowledge. Sometimes that structure is informal, set through headings and how the author organized their writing in a word processor like Microsoft Word or Google Docs. Other times, the content lives in a content management system (CMS) where there’s an underlying model that gives the content its structure.

That underlying model is called a content model, and it’s a terrific way to produce inter-connected content at scale.

For content professionals, there’s more to content modeling than they might realize. Indeed, most of what I know about content modeling was probably on-the-job learning and learning from mistakes along the way.

Here’s 6 mistakes I made so that you don’t have to.

• Starting too slowly
• Bundling presentation too closely to content
• Failing to understand developer queries
• Wanting everything to be perfect
• Modeling for expediency, not scale
• Modeling at the wrong granularity

Let’s take a look at the first three of these in this issue, and then we’ll look at the last three in the next issue.

Starting too slowly

In my biggest CMS implementation project, we struggled a bit with “blank page syndrome” in the sense that there were so many possible acceptable ways to start that we spent too much time debating which way was the best way to start.

Had we picked a way and started building, we would have learned and iterated quicker, and we would have delivered value to our organization a lot sooner—at least 6 months sooner.

Bundling presentation too closely to content

This is a topic that I’ve discussed before (The biggest mistake I see teams make in CMS implementations), but the fact is that even I’ve made this mistake.

Many teams will conflate the content and how it’s presented. For instance, the content model may have a content type for a three-column layout and another for a two-column layout. To be fair, this is solving for a long-standing problem encountered while building websites from a CMS. But the problem is that nothing in such a model tells you if the content in those columns is leadership bios or product descriptions.

I was smart enough to avoid that flavor of bundling presentation too closely to content, but I still made essentially the same kind of mistake by defining the destination of content in the content model for the primary content type. Essentially, I used fields on an article content type to say “this article goes here in our site page tree” and “this article can appear on this product screen.”

This quickly led to problems scaling the content and required content creators to understand a lot of things they probably didn’t need to understand. It probably would have been better to have a different content model, connected by a reference, that defined “routes” for the articles.

Failing to understand developer queries

I already mentioned the mistake of starting too slowly and that it cost us 6 months or so. One big reason for this delay was a debate about which directions references should flow between content types. One of my responsibilities was designing a friendly authoring experience, and I felt the authors’ lives would be easier if the references went from their primary content type out (or “up” as we called it) to other content types.

However, with the number of content types involved and the way that our content model was evolving, my content model was going to be very hard for developers to query for the content needed to build the user experience. When we reversed the direction of the connections to go “down” from other content types to the primary content type, queries became much simpler.

Once I wrapped my head around this, we used the query-friendly model and made some customizations to the authoring experience to minimize the impact to authors. With several years of hindsight, I think we could have done a number of things differently, but my core takeaway from this became a guiding principle to model content for query-ability while keeping the meaning of content as accurate as possible.

Come back in two weeks for part 2 of “6 mistakes I’ve made in content modeling.”

Strategy

Quick thoughts about the importance of thinking strategically about content

No sooner had the previous issue of Model Thinking (Are we selling ourselves short as content strategists?) come out than I came across a LinkedIn post by Rahel Anne Bailie titled “Rethinking the knowledge pyramid: why content deserves its own spotlight.”

Bailie talks about the “DIKW pyramid.” (DIKW is short for Data, Information, Knowledge, Wisdom.) I think I previously had intended to reference the DIKW pyramid but forgot to do so when it came to writing my thinking down.

If my post sparked any thoughts for you, then I recommend reading Bailie’s post. The timing is eerie—I mean, impeccable. She’s got some similar thoughts, but approaches the topic differently than I do. That perspective, and Bailie’s expertise, is worth reading. And if you didn’t know about DIKW (which is inverted from the pyramid I shared), then you probably should. (At the least, I needed the reminder it existed. 😊)

Trying to sort through the CMS market?

I launched a service to help CMS buyers get personalized, expert recommendations and a CMS implementation readiness assessment.

If you’re considering a new CMS—or are already neck-deep in one you want to optimize—I’d love to help. Head over to Choose Your CMS to get started.

John Collins

Did someone forward you this email? Subscribe here​ If you’re already a subscriber and you found value in something here, tell your friends and colleagues to subscribe!

Welcome to the 4 new subscribers who have joined us since the last issue of Model Thinking.