Content modeling patterns

When it comes to content modeling, every situation is unique. There is no single pattern that solves all content challenges. As a result, each content model pattern listed in this guide is aimed at one or a set of challenges that need to be solved. 

Some of these problems include, but are not limited to: content reusability, empowering editors to work independently of development teams, localization of content, handling UX by managing navigation and/or microcopy. 

This guide will lay out a set of best practices that are considered good content modeling patterns. We suggest to keep them in mind when you set out to  model your content.

Content design vs system design

Content design system is a set of scenario-specific components, agreed upon by the team and integrated into the design system. Something that allows them to make solid content decisions without us. Aimed to be a set of repeatable content patterns that keeps consistency.

A design system might provide context like:

• Use this checkbox when you need this option

• Use this dropdown when you need a link

• Use this file input if you need to upload multiple files at once

Content, meanwhile, needs more context, for example:

• Use this modal when the user tries to leave an unfinished form

• Use this error message when an input is incomplete

• Use this message when the input is successful

Choosing a component is about context. Whether you're building a page or flow, it means making a content decision for that page or flow.

When context is added to a component, content decision-making becomes easier.

Questions to ask when creating a Content Model

Here are questions to ask yourself and your team as you create your content model: 

• How will your editors and authors interact with this model? 

  • Is the publishing flow clear?

  • Does this model simplify editorial or authoring work?

  • Do your Editors understand the flow of content creation/editing/publishing?

  • How is an Author going to discover content?

  • Have you set up any validations for content?

• How will new content be introduced?

  • Will it utilize your existing set up?

  • Will localization need to change?

• Hypothetical tests

  • Can we change the model to include new fields?

  • Can we add new types of content?

  • If you suddenly find yourself with content that you need to split:  Can you  split it?

• Introducing a new content delivery channel

  • Can our current model support it?

  • Do you editors know about it?

Multichannels

A multichannel modeling pattern allows for delivering personlized content across multiple channels (for example, a corporate website, a mobile app, digital billboards, etc.). If you are part of a marketing or ecommerce focused team or department, this kind of pattern can be very helpful for your work. Teams that need to reach a large, broad audience (like large news media organizations) can also make good use of this modeling pattern.

Pros

• Separate content for different delivery channels like website, mobile, iOt, etc

• Targeted marketing: Most companies are able to personalize at least some of their marketing content on a campaign by campaign, and channel by channel basis.

• Quick adjustment to market: But preferred channels and customer expectations are constantly changing.

• Filter content per channel: Adjust to reader view or market segmentation.

• Device targeted: Content can be distributed and reused between devices, example a website and an apple watch.

• Content governance: Same content can be governed by different teams that in parallel perform separated editorial process

• Separate delivery model: CDA or GRAPHQL can be used to selectively present content for particular channels.

Cons

• Not out of the box solution: A content strategy is needed to implement this strategy successfully.

• Potential duplication of types and entries: Without the proper content strategy, multichannel can lead to duplication of content.

• It is a strategy not a solution: It does not guarantee instant marketing improvement or business success,  multichannel is a delivery strategy for content.

• Possible increased complexity: Could increase infrastructure costs and complexity, as different delivery solutions could require different technologies, infrastructure, developers. 

Navigation

Using a content model, you can define the visual navigation structure for a website in the form of a side-menu, site map, breadcrumbs, etc. The structure can be as free-wheeling or as strict as your team requires. The main beneficiary of this modeling pattern are editors, who are freed to define the structure of a website according to their needs, without relying on a development team for small changes. 

Pros

• Site navigation: A content model can be used to define a navigation schema for a site, as navigation menu, site map, breadcrumbs, etc

• Laverage developers work: Developers are not involved anymore in creating a navigation/menu, the editors can handle this by themselves.

• Empower editors: Editors can, with a single click, control how the site can be navigated. Skipping code updates.

• Codeless sitemaps: Sitemaps can be managed by editors, no need of code releases, near instant updates. 

Cons

• It is a strategy not an out-of-box solution: The strategy needs to be an informed decision and have a plan.

• Governance recommended: As navigation will be controlled by editors, governance strategy is recommended. 

Topics and assemblies

Topics are what your app or site is about. Assemblies are content types that, together with topics, create the structure of your content. This content model is perfect for optimizing content for reuse, or for customers who need content to be structured in a very defined way. It also offers the greatest amount of governance between editors and developers. Just about anybody can benefit from this content model, as long as they don’t mind a learning curve.

For a more in-depth look at topics and assemblies, see our Help Center article.

Pros

• One type with different purposes: They consist of content types with different capabilities.

• Assemblies contain fields for layout and site navigation data, they sometimes also have additional metadata for SEO or analytics, but they don’t have content in them. Assemblies use reference fields to refer to topics.

• Assemblies can be nested inside other assemblies, so they can also have reference fields that refer to other assemblies.

• By defining structure blocks or components, assemblies can be  reusable and contain a variety of topics.

• They structure your content for presentation to the end user.

• Each topic is about one part of content, can be created on its own and is self describing.

• A topic can appear in multiple places and across different channels, so should be free of being locked to specific content or layout, and be usable anywhere.

• Each topic is about one area and can be created on its own. Each topic should be sufficiently complete, so that it can be independently presented.

Cons

• There is a learning curve. Breaks the old idea of WYSIWYG and can be hard to understand

• Migration from a Blob or WYSIWYG can be difficult, need manual work in most cases or can not be done automatic.

• Splitting in assembles can create increase of number of content types

• Orphans or unreferenced Content types can get lost or be duplicated in the schema.

Assembly model (fixed vs flexible)

Fixed and flexible model, refers to a subcategory of Assemblies. 

We refer to a fix assembly when a reference field have only one referenced entry. An example could be a WebPage contentType that includes a single reference to a SEO (search engine optimization) contentType, with this a single webpage will include only one block of SEO information.

We refer to a flexible assembly when a reference field have many referenced entries. An example could be a WebPage contentType that includes many references to products entries, like a shopping cart carousel, with this a single webpage will include many references to products entries.

Pros

• Same properties as Assemblies: Fix and flexible describe properties of an assembly for different usages and behaviors.

• Limited to one assembly: Fixed strategy limits the reference to one assembly content type, an example could be a SEO metadata that should not exist more than one time on a site.

• Elements layout control: Flexible assembly empowers the editor to organize a collection of content. 

• Same Content type, two options: Content Types for both strategies are the same, how they are used by editors marks the difference.

Cons

• Without careful validations or strategy, it can be messy.

• Large Assemblies can be difficult to understand

• Same cons as normal Assemblies

Localization

In today’s increasingly globalized world, foreign markets are becoming more and more important. As you create content for these markets, you may end up needing to translate it into multiple languages. This process of translating and adapting is called localization, while specific regions are known as locales. You can set up your content model to handle content  across multiple regions, languages and teams, as well as define a default locale to use as the source language for all content translations.

For more information about setting up localization in Contentful, see our developer documentation.

Pros

• Possibility to describe the different versions of content for different locations or more simply a language-region pair.

• Different strategies to add localized content, Entry, Field, contentType/Space, or mixed.

• Possibility of fallback languages.

• Flexibility on separation of content per language

• Localized content can be governed by different roles/teams

• Localized content can be validated 

• Localized content can separate editorial process (parallel editorial process)

Cons

• Once a space is created in a language is difficult to change

• Is necessary to implement a localization strategy

• Decide in beforehand how localization will be done, field, entry space.. Etc ?

• If not handled properly can add complexity and duplicity to the content model.

Microcopy

Microcopy refers to short, concise pieces of text used on a website or within an app. (Think button labels and website section headers). Our own Help Center uses Contentful to manage every piece of text you’re currently reading, including our microcopy. For customers that need editors to manage textbox hints, or simply want to empower editors to handle aspects of UX design or SEO metadata, using your content model to handle both microcopy and your main content can be a powerful strategy.

For more information about handling microcopy with Contentful, see our Help Center article.

Pros

• Can be as simpleas a 2 fields content type, key and value 

• Short pieces of text to enrich User experience

• Can be used for Search engines meta information

• Small bits of text that bring a website alive 

• Can make the browsing user either click more or leave the page.

• It’s the headline, the error messages or the small hints in a contact form.

• Not a developer who codes the website but the colleague from the public relations, business, product or design department handles the context.

Cons

• Can be mixed with normal content

• Should not be used outside of UX

• Editors handle the layout responsibility and usability.

Training course

Learn more about content modeling patterns by taking our Learning Center training course called Content Modeling Design Patterns.