Best practices for content modelling
Last updated
Was this helpful?
Last updated
Was this helpful?
We can model page content models in three different ways depending on the context and the needs of the page you are trying to build.
Templated pages have a static page structure, only allowing authors to edit content in predefined areas on the page. This makes editing really simple but gives the author no control over the layout of the page. An example of this might be a blog post page, where the layout is fixed, and only the title, blog content, and authors need to be inputted by the content author.
Non-templated pages are fully customizable, enabling the author to pick components and rearrange the order of the layout. This provides a lot of flexibility but comes with a high degree of complexity and design choices.
Alternatively, hybrid pages specify some fixed content and allow some specific sections of the page to be dynamic and reordered. This is the most common type of page content model we encounter. It gives the content author the right amount of flexibility without being too complex or tedious to edit.
The right type of page content model is entirely dependent on your use case. To determine what is the best strategy will require you to look at the page you are trying to model and answer a few questions.
There are two types of page modules that we model: reusable and global page modules. The way we model them is the same, but they are used differently in our platform.
Reusable page modules, as the name suggests, are meant to be modelled once and used in multiple places with different content. Header, Accordion, and Quote components are good examples of reusable page modules that we can picture appearing on various different pages.
Global page modules are modelled and used once for the entire site. They contain content that only needs to be defined once and are not unique per page. Navigation and Footer are good examples since they tend to be the same on every single page. With global page modules, we won’t ever see them referenced in any other content models and will live at a global level.
Notably, there are two kinds of names for a field. There’s a Field ID and a Display Name (actual names vary by headless CMS).
The Field ID must mirror the component name and is not visible to the content authors.
The Display Name is what the content author sees in the CMS interface as the name of the content field.
Although teams often use the same name for Field ID and Display Name, this isn’t always the best approach. A name that makes sense to developers might be ambiguous and confusing for authors.
The fields of a page module map to the props of its counterpart component. This doesn’t mean that every prop of a component should be mirrored in the content model. Thinking back to the importance of simplicity and its impact on user experience, we want to only include what's absolutely necessary for content authors. It's better to add more options later, as needed, rather than granting maximum flexibility from the start.
We use reference fields to allow authors to add existing content to new content models. This is really useful if a piece of content needs to be displayed in various pages or components and managed in one place. Rather than recreating the same content over and over again, we can create it once and use it anywhere we want. Let’s take a look at an example.
Let’s say we’re building a blog section of a website, and we want to be able to show the authors' information on all of our blog post pages. For those of you who are familiar with relational databases, the relationship between authors and blog posts can be viewed as a many-to-many relationship. For a given blog post, we can have any number of authors; similarly, any given author could have written any number of blog posts.
Rather than creating an author (or authors) every time we create a new blog post, we want to be able to reference them from a preexisting set of authors. Then, at a later date, we are able to easily change the author’s profile image, for example, in a single location and have that change be reflected on all of the blog posts.
We give matching field names and prop names to content in a headless CMS and properties in a component library, respectively. This is critical for buildComponent to match our JSON files (from a headless CMS) to the appropriate components (from a component library) and dynamically build pages. (More about this in the section.)
