Content modeling makes the difference between just writing words to put online and engineering your content – and engineering does sound better, doesn’t it? Compared to our fancy technical infrastructure, we usually don’t structure our content nearly as well. But like well-engineered code makes the codebase more maintainable and reusable, content modeling does the same for content.
If you know a bit or two about database design, you will discover you have been (almost) thinking in content models already. If not, it will change how you think about content completely: Understanding content modeling will help you think about it more strategically.
Why your content should be structured
If you have published content on the web before, you are probably familiar with editing interfaces that let you put the content of your pages into one, big WYSIWYG field. WordPress worked like that before Gutenberg, and many (not headless) CMS are set up in that way.
If you publish your content that way, you will oftentimes mix up important information in one text block: An address, your sources of reference, a specific legal term, a name of a conference speaker. Depending on what your site is about, these are all things that you might want to reuse or change easily later.
Dumping everything into a WYSIWYG field takes away possibilities to make use of your content in the future.
Content is data
„Content is data.“ This simple sentence in one of the first chapters of Designing Connected Content by Carrie Hane & Mike Atherton feels like one of the core concepts of content strategy to me.
If you think about content, you may think about blog articles, pages on your website, images, ads, social media postings,… Would you call them data? Probably not. They’re that abstract content thing: Words, sentences, images,.. all thrown together and living somewhere in your note apps, in stuff folders on your desktop, in e-mail clients, word docs, sometimes on post-its and in those big WYSIWYG fields.
Data is structured information
Data is just another word for a piece of information. But unlike the ugly blob of unstructured information inhabiting a WYSIWYG field, pieces of data can be looked at separately. (And analyzed! We love doing that, right?)
When creating structured content, we aim at breaking up our content into the smallest parts possible – chunks, or pieces of data – so that you can:
- Edit them in one place and have changes published everywhere
- Remix pieces of content in the future
- Display them in another place with a different layout
- Use them to publish on new channels (app, info screens, social media,..)
Structured content is content that is planned, developed, and connected outside an interface so that it’s ready for any interface.
Carrie Hane & Mike Atherton in Designing Connected Content
Structured content is the basis for a cleaner separation of content and representation (channel & styling), which has been kind of a golden rule for web design for ages. You can also compare it to the DRY principle – don’t repeat yourself – of programming.
If you’re not yet convinced of why that is important, I love telling one of the stories by my lecturer Rahel Bailie: A client of hers tasked its employees to replace a legal disclaimer due to government requirements. Together, those employees spent a year in working hours to replace those strings – and they still missed about 30.000 instances of it. It would have been a matter of minutes to change that text if their content had been structured well. Minutes!
(Structuring content is part of successful content operations as well!)
Relationships define meaning
Structured content does not only mean separating your content into chunks but also defining the relationship between all the small parts of information.
Without relationships between the things in our world, we could not make meaning of them. Defining relationships between your content objects help your users understand your content as a whole.
What is content modeling?
This brings us back to the terms model and content modeling: A model is a description that helps you to understand how things work and relate to each other. So a content model is a representation of how all the pieces of your (structured) content are related.
If that smells like database design to you, you’re on the right track! Deane Barker uses the term „relational content modeling“ that borrows from relational database design.
A content model example
Here’s a simplified content model of our site madewithvuejs.com, a showcase of projects developed with Vue.js:
The model shows what kind of content we publish, and how these pieces of content are connected. It describes the attributes of the different content types of projects, collections, creators and blog posts, as well as their relationships:
- A project can have no, or one creator.
- A creator can have one, or multiple projects.
- A collection can have multiple, but at least one project(s).
- A blog post can reference no, one or multiple projects.
- A project can be referenced in no, one or multiple blog posts and collections.
This does not mean our model is perfect. Can’t there be a project that has multiple creators? Shouldn’t every project have a creator? What’s with open-source projects with a big list of contributors? Well, we made the choice to structure our content that way. Defining a content model is all about making the choice between simplicity for users („what makes sense“) and objective factual correctness.
The relationships in the chart are shown in the same way that cardinality is shown in an entity-relationship diagram. (If you want to read more about that, read Entity Relationship Diagrams explained by Sonic the Hedgehog by Helen Anderson on dev.to!) It may look strange at first, but it’s really useful to quickly describe relationships between (content) objects:
one – only one – one or many – zero or one – many – zero, one or many
Content Models vs Data Models
A content model is not exactly the same as a data model. The content model describes your data on a more conceptual level. It does not (yet) describe what kinds of values the attributes contain (How many characters does a description have? Is it a number, a list of countries?), which tables you’ll need in your database or which attributes are keys.
Of course, it’s a great basis for your data model, but it should be more user-focussed than tech-focused. In other words, you need to ask yourself how you want your users to experience your content, rather than how to store it.
It’s a great deliverable for UXers and content strategists to discuss with the dev team, as it makes sure they understand and implement all editorial requirements well.
Chunking Mindset
It needs a bit of practice to get into the mindset of content modeling. If you want to dig deeper and get an in-depth how-to, I can recommend Designing Connected Content by Carrie Hane & Mike Atherton, which explains how you go from exploring your problem space to defining a content model for your next project.
Also, there are a lot of great articles about content modeling by Rachel Lovinger & Michael Andrews. If you want to get more technical and CMS-focused input, you could read what Deane Barker writes about it. (Find a list of links at the bottom!).
Once you get accustomed to thinking in these structures, you will see them everywhere. Your brain will automatically build them. This will help you understand a problem space for a new product, as well as get ideas on how to reuse your existing content (f.ex. for marketing automation).
It’s a skill – or a kind of creativity – I have seen in many developers and indie makers that build their own products. They are so used to think in structures that ideas how to connect data and information come naturally to them.
Future-friendly content
Having our content on madewithvuejs.com chunked, we can easily find new ways to present projects and expand on the info we already have. Maybe we’ll make automated lists of the top-projects of the month? Or we’ll build creator profiles, showing all projects of a specific creator?
We don’t know how this project will grow in the future, and what things we’ll want to build. But we’ll be prepared!
By creating a content model, you will build your projects more future-friendly. Some day, you’ll thank past-you for chunking it up and making it reusable and maintainable.
Read more
- Designing Connected Content: Plan and model digital products for today and tomorrow by Carrie Hane & Mike Atherton
- Designing Future-Friendly Content: Modeling Structure for Every User Interface User Experience Magazine by Carrie Hane & Mike Atherton
- Content Modelling: A Master Skill – A List Apart by Rachel Lovinger
- Redefining the Role of Content Models – Story Needle by Michael Andrews
- Wine, Content, and Domain Models – Story Needle by Michael Andrews
- Where Domain Models Meet Content Models – Story Needle by Michael Andrews
- Web Content Management: Systems, Features & Best Practices by Deane Barker
- Towards a Content Modeling Standard – Gadgetopia by Deane Barker
