Why content models matter
In a previous blog post we explored the ‘unknown consumer’ – a catch-all term for new breeds of content-consuming, internet-connected devices. In that article, we established the business need to serve content to these unknown consumers. With this as our goal, we first have to make some assumptions:
- We don’t know the intention or capabilities of the unknown consumer.
- The context of the information we are offering is important.
- Unknown content consumers will struggle to use the type of page we’d typically present to a web browser.
With these assumptions in mind, we need to think about how we can structure our content in the most flexible way. Because many of tomorrow’s content-consuming devices won’t be able to read the contents of a typical web page.
Many new devices won't be able to read traditional web pages
To understand how best to structure our content we need to consider the following:
1. Software is not good at interpreting meaning
Software can struggle to interpret the meaning of your content. Take the example of delivering route guidance to a navigation system. If you try to deliver that information via a human-readable format, it’s not going to work well.
Sure, it would be doable with smart enough software, but using structured data will be more precise and efficient, and will achieve better results.
Delivering route guidance to a navigation system in a human-readable format is problematic
Likewise, if we take the example of a diet tracking app, how well is that app likely to understand a recipe on a web page? Without understanding the context of the recipe information, it’s going to struggle to consume that content effectively.
2. Web page thinking is limiting
We’ve already explored some limitations of the traditional web page format in helping us serve the needs of our unknown consumers. But many people still think of the web using the page model.
With modern HTML, pages may have semantic markup elements that go some way to making sense of the content on the page. But at best these are still signals for interpretation.
In order to meet our goals we need to move beyond page thinking and start to think of our content in terms of structured data.
In this way of thinking, the content creator needs to think beyond pages and relinquish control of the design and layout of their content.
3. Content needs to be liberated from design
Content needs to be modelled in such as way that the task becomes creating the most-structured, clearest-possible data whilst delegating the design to the content consumer – whether that be the theme layer of a content management system (CMS) or the voice user interface (VUI) deciding which available information should be ‘spoken’ back to the user.
The blobs vs. chunks debate has been raging for years, but at the beginning it was more a conceptual CMS theory that was important for maintaining consistency in design when using a CMS. The premise of the debate is whether a CMS should allow the user to create pages using a WYSIWYG (‘what you see is what you get’) editor giving them creative freedom at the expense of structure.
Are you ready to say 'goodbye' to the humble WYSIWYG?
But with the challenges posed by new breeds of content consumers, it’s become essential to remove or mimimise the use of WYSIWYG so that we can offer clean data to these unknown devices – otherwise we are expecting it to parse and interpret irrelevant information.
Adaptive vs. responsive design
There is also a long-running debate about the pros and cons of adaptive vs. responsive design. The premise here is whether every device requesting a page is presented with the same things and the device itself decides what to do – as opposed to a system that changes what it sends based on the device requesting the information.
This is a fascinating debate covered in depth by Karen McGrane and well worth reading for context to this article. When we consider the unknown consumer we have to assume that, since we don’t know what the consumer will be doing with our content, we have to provide it with everything (but in a way that does not dictate design).
An example of a content model
Let’s move beyond the theoretical and use a real example. Consider the content type of a news article. At its very lowest level this would be a title, body, and associated metadata to do with publication date and author.
There’s not much structure here, so we could potentially add an alternative, short-form summary of the body field as well. Once we start adding some context of a real scenario we see that this can quickly escalate.
Now consider the news article as part of a football team’s website. The article itself could be related to a fixture, a player, or a specific team or event. Each of these are content types in their own right.
Illustration of a potential content model for a football news article
This type of model means the content consumer can use only the parts of the data that it really needs, and can understand the relationships between different pieces of content.
Defining the content model
The definition of the content model is an important part of a web development project. Whilst the relationships between content can seem simple at first, we quickly discover complexities in the way content fits together and how we can break down structures into finite elements that link together.
This needs to be done in a workshop style with stakeholders that truly understand the complexity of their content alongside CMS specialists who understand the possible implications of the decisions being made in terms of complexity and performance.
The foundation of content strategy
Getting the content model right before even starting the process of building a CMS is essential as the content model is the foundation of everything that comes next. Getting buy-in and a full understanding of the reasons for approaching content this way is essential for the success of a project – and also for the creation of the content that will work.
In the next part of the series we’ll look at some more practical ideas around content modelling and some of the common pitfalls that we see in CMS implementations.