The future of content delivery: part III

The future of content delivery: an introduction

The future of content delivery: part II

Content best practices and anti-patterns

In a previous post in this series, we looked at approaches to content modelling and the relationships between types of content. Here, in our latest post, we look at content management best practices in a world of unknown consumers.

Single responsibility

Modern content management systems (CMS) allow us to easily create as many content types as we need and add to these any number of fields. With this flexibility there is no need to force a content type to do more than one thing.

When creating content models, we like to consider the single responsibility principle: that any content type or field has one purpose and one purpose only. Taking a simple example, if we have an article content type, we would not try to make this behave differently by adding a date field and using it for an event.

Sometimes, during planning sessions, as the number of possible content types starts to grow, there's a temptation to map different physical content to content types we've already defined in a bid to reduce complexity.

In reality, we end up doing the opposite, because things get considerably more complicated when you attempt to use a single content type for different purposes. Instead, it's important to keep content types discrete, specific, and well-named so it's obvious to an end user which one to use in any scenario.

Let's take another example where we are working on a content model where the organization offers different types of event - webinars and multi-day, onsite workshops, for example.

Here there might be a temptation to create a single event content type as they sound similar on paper. In reality, the content requirements are completely different - one will require a venue, for example, while the other needs a dial-in URL. That's why two content types are required.

We also have the same scenario for fields within a content type. If we take the example above, it would be tempting to have a single URL field which has two purposes depending on the type of event: 1) to give us the link to access the webinar and 2) to give us a map to the venue.

These are exaggerated but not uncommon examples that lead to overly complex content models. The moment we introduce any ambiguity into the system, we are effectively restricting the unknown consumer as it will not understand the context of our content.

Non-content content

'Non-content' content is a common anti-pattern that's often driven from design requirements. I've heard this type of content referred to as a jump, link, signpost and others, but ultimately it's always the same: a piece of content that's simply text, an image, and a link. It has no purpose other than to link to something else. An example is a 'jump' that provides a teaser and link to a blog post.

The problem with this type of content is that, while it's not meant to be treated as real content in its own right, it still gets indexed by search engines. For this reason, it's important to think about our content in a number of view modes. If we want to link to a blog post, for example, we can render it as a teaser view that provides exactly the same content as our 'jump', but displays it in a different format.

The example here shows a news article in teaser mode and full content mode: the same content in different contexts.

It's essential to take this into consideration for the unknown consumer for whom context is important. We need to present the content in a form where the device or platform can decide which parts are appropriate to display. For example, we don't expect a voice user interface (VUI) like Amazon Echo to read the entire contents of an article, but it might be possible for it to read a shortened summary.

Field ambiguity

A good content model should not require training for a user to understand it. As with the single responsibility principle I mentioned, all fields within a content type should be obvious to anyone with working knowledge of the content domain they are working within.

Fields should be clearly labelled with sufficient contextual help text that no one needs to question what the field is for.

Content for logic

Another commonly-witnessed anti-pattern is the use of fields in a content type to control some other part of the system. There could be a drop-down field, for example, which allows the content editor to switch between a number of possible layouts.

Encapsulating logic in this way is confusing as it leads to 'magic' happening within the CMS. Our unknown consumer will have no way of knowing what these tricks are and this could lead to the context of the content being changed unintentionally.

The Godzilla content type

If the single responsibility principle is followed, this one should never happen, but we often see the monster content type which is all things to all people. It has potentially hundreds of fields and can act as many different things depending on the combination of settings filled in.

This often happens when a system evolves over time. Fields are easy to add in a CMS and often this might happen as a result of a support request without referring back to the original content model and system design.

Our unknown consumer will not be able to correctly interpret this complex kind of content and so we must treat the addition of a new field to content as a non-trivial change, no matter how easy it is to do.

What's next?

These are just some of the anti-patterns we see in CMS-based website builds. Considering the impact of small decisions on the unknown consumer is essential.

In the next part of this series, we'll look at how we can expose our newly-created content model to the outside world so that we can invite others to make use of our content.

Want to know more about Inviqa's content management practice? Interested in speaking with a consultants about your content strategy? Contact the Inviqa team!

Inviqa is an eZ partner.

Insights and News