Issue 19

Structure

Quick thoughts about how content lives in systems

When content lives in a content management system (CMS) where there’s an underlying model that gives the content its structure. That structure—a content model—forms the core of creating meaningful content that can be applied in websites, apps, chatbots, and more. It allows the content to be created and managed at scale.

​Last issue, I introduced six mistakes I’ve made in modeling content. There’s not a lot of strong guidance on how to model content (yet?!), so it was a lot of on-the-job learning for me, with a lot of learning from mistakes as I worked.

That issue was part one, where we talked about these three mistakes I have made:

• Starting too slowly
• Bundling presentation too closely to content
• Failing to understand developer queries

In this issue, let’s look at three other mistakes I’ve made:

• Wanting everything to be perfect
• Modeling for expediency, not scale
• Modeling at the wrong granularity

Wanting everything to be perfect

Those with content backgrounds or information architecture backgrounds might have a tendency to really get deep in details and want to model content as theoretically pure as possible.

In reality, you should expect to make some pragmatic content model decisions. As Joe Reis says in Practical Data Modeling, “applying theory to the real world will be hampered and challenged in ways that will leave you frustrated.”

Sometimes I might see this desire for perfection bubble up in modeling things that I see as logical next steps but for which there’s no current business case or capacity. Other times, it might surface as an optimization for which the problem hasn’t surfaced yet.

If you find yourself working ahead of the business, you may be a wise visionary, but check yourself to make sure you’re not overcomplicating things. Be prepared to make what might feel like a concession. Sometimes “good enough” is what our content models need to be in order to demonstrate business value sooner.

Modeling for expediency, not scale

CMS vendors often offer specialized field formats for authors, such as checklists or dropdowns. Or when you connect one content type to another with a reference field, you choose whether there can be a single reference or multiple.

These are times where it’s easy to model for expediency and not scale.

In many CMS tools, those specialized field formats simply contain plain text. If your developers have queries relying on the text of the checklist items or dropdown and then the text changes, everything breaks—or developers need to run a migration script to change from the old to the new. (Some CMS tools have a unique ID for the checklist text or dropdowns, so then you’re fine to change the text as long as the ID doesn’t also change.)

Similarly, if you need to change from a single reference to multiple, that’s an expensive, avoidable change. For example, say you have a “Book” content type that allows only a single “Author” reference, then you’re going to have to get a lot of developer help when it comes time to change to multiple “Author” references for that book that has co-authors.

If you think about building for scale, you can anticipate these complications and model appropriately. This might play out as modeling additional content types (which may have some cost, depending on your CMS provider) which you use in lieu of checklists or dropdowns. And if you’re going to have a single reference, your CMS may provide the ability to instead define the reference as a multiple reference with a validation of only one entry. This gives the same outcome, but you can more easily change the validation to allow multiples if the time comes.

Modeling at the wrong granularity

I remember one project where I anticipated some capabilities that the content team would need to deliver more targeted content to their audience. This was a key pain point, and solving this would really help the business.

So I added some metadata fields to the article content type, pleased that I was ahead of the stakeholders.

It didn’t take long before those stakeholders started asking me questions about the metadata fields and bringing me real-world examples that showed me that I’d gotten the granularity wrong. They needed to have targeting not at the article level, but within the article.

Had I run a workshop with some of the stakeholders prior to my content model update, I would have understood the need more clearly. Instead, I shipped a basically useless content model change.

Another time, we made a pragmatic decision to launch with a “one-size-fits-all” generic article type with plans to introduce more specific article types (e.g. trouble shooting, set up, reference, etc.) over time. Launching with the generic article type saved us time, but we never did go back and introduce specific article types, and the business had more and more need for them.

On the flip side, there have been other times where I wanted to define content types with great specificity (see “Wanting everything to be perfect”) and with nested content types.

For example, I might want to model a content type for “office location” with sub content types for “address” and “hours of operation” because I might think they are nice standalone pieces of content. But in reality, “address” might only be used once with the office location and “hours of operation” may differ at every location so there’s no reuse. If so, then I probably only need an “office location” content type with fields for address and hours of operation.

At another organization, the situation might be different and the more granular model might make sense.

A more granular model requires more complexity in queries and front-end implementation. Without a real business reason, a highly granular model can be more problematic than helpful.

It’s really helpful to share in-progress content models with your cross-functional team to get feedback, just like a UX designer might with their mockups or a writer with their content draft. This is where you might learn that the complexity is problematic for developers or that it creates an unnecessary burden for authors.

​

Top of mind

Things that are bouncing around in my head as I synthesize a range of ideas

Last week I was in Colorado, and I was able to catch up with two separate former colleagues who I worked with more than a decade ago on the other side of the continent. We had fun reminiscing and catching up on life.

I left with a thankful heart—thankful for the time I spent in a work environment that forged long-term friendships, thankful for the in-person reunion, thankful for the things that these friends taught me and the influence they made in my career.

It also left me thinking. Sometimes the smallest things make a big impact on those around us.

What little explanation can you give that might provide an a-ha moment? What simple feedback can you give that makes someone’s work stronger? Can a simple act of sharing—a comic, a meme, an article—stick with someone for years? Maybe it’s just the act of faithfully showing up and being authentic every day.

I’ve got a renewed desire to edify those around me. What about you?

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

Thanks for reading! 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 6 new subscribers who have joined us since the last issue of Model Thinking.