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

A 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 use your existing setup?

  • Will localization need to be changed?

• 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 personalized 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, for example, a website and an Apple Watch.

• Content governance: The same content can be governed by different teams that in parallel, perform a separate editorial process.

• Separate delivery model: Content Delivery API (CDA) or GraphQL can be used to selectively present content for particular channels.

Cons

• Not an 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, and 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 beneficiaries 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

• Leverage 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 for 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 structural 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, require manual work in most cases, or can not be done automatically.

• Splitting in assembles can create an increase in the 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 fixed assembly when a reference field has only one referenced entry. An example could be a "Web Page" content type that includes a single reference to an SEO (search engine optimization) content type. With this, a single webpage will include only one block of SEO information.

We refer to a flexible assembly when a reference field has many referenced entries. An example could be a "Web Page" content type 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 ‌SEO metadata that should not exist more than once 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.

• It is necessary to implement a localization strategy.

• Decide ‌beforehand how localization will be done, field, entry space.

• 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 simple as a two-field content type, key, and value. 

• Short pieces of text to enrich User experience.

• Can be used for search engine 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 a 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.