Content Modeling Best Practices

Content modeling is the process of identifying fields for your app or website and creating the structure of the content types, based on the website design. It involves picking the right fields to create the content type structure in the most optimized manner.

However, before you start with content modeling, make sure that you have the following in place:

• Website design: This helps in content modeling. With proper website design, it will be easier for you to understand your website's front-end structure. Thus, making it simple to define content types in Contentstack.
• Knowledge of data types: Understand the functionality and intent of every element of the website and what type of data it stores. For example, a call-to-action button is a text with a hyperlink.

Once these things are in place, you can start modeling your content. Read about how to get started with content modeling.

While content modeling is considered to be an art that improves with practice over time, there are certain best practices that you can follow to make sure you model the content in the recommended way.

Warning: Avoid using _regex or _exists in field UIDs. These are reserved keywords in GraphQL and may cause errors during queries. Use alternative naming to ensure smooth query execution.

Use “Reference” Fields for Reusable Content

If a piece of content is being reused in multiple entries, it’s best to create a Reference field for that content. Consider, for example; you have a content type named “Blog” with a Reference field named “Category.”

So, every time you create an entry for “Blog”, the value for the “Category” field is usually any one of these: “Sports”. “Movies”, “Business” and “IT”. Instead of entering the value every time while creating an entry, it’s best to create “Category” as a Reference field, which refers to the “List of Categories” content type.

Similarly, “Author” can be a Reference field in your news site's “News” content type. “Size” can be a Reference field in the “Products” content type of your e-commerce site.

Use “Group” Field for Bunched Items (Banner, Footer, etc.)

Many items on your website are usually bunched together. For example, a banner usually comprises an image, a title, some supporting text, and a call-to-action button. And footers usually consist of several columns of links.

Instead of creating separate, independent fields for each component in a set of bunched items, make them all part of a group.

So, in the banner example, add a Group field in your content type. Then, within the Group field, add a Single Line Textbox field (for the Title), a Multi Line Textbox field (for the Description), a File field (for the Image), and a Link field (for the call-to-action button).

If the bunched components are multiple (such as three rotating banners), mark the Group field as Multiple.

Use “Modular Blocks” Field for Dynamic Web Pages

The Modular Blocks field lets you add multiple structures as blocks within a field. So, for example, you can add one block for a banner, one block for image and text, and another for videos. While creating an entry, the content manager can select any of the blocks, giving the content manager greater control over the page's structure.

Let’s consider an example to understand this better.

You need to add two different structures to your content type: a “Banner” with a description and background image and a “Video Gallery” with a video file and a Call-To-Action (CTA) button. These structures will change dynamically on the web page.

Here, you can use a “Modular Blocks” field when creating your content type. Add one block for the Banner” that contains a “File” field for the background image and a Rich Text Editor field for some descriptive text, and another for the “Video Gallery” that contains a “File” field for the video file and a “Link” field for a CTA button to take you to a particular link. You can use any of these two content structures while creating your entries. Thus, the “Modular Blocks” field allows you to use different types of structures for your web pages, providing dynamic content.

Now, when you create entries for these pages, you can select the “Banner” structure for the “Homepage” entry and select the “Video Gallery” structure for the “About Us” page entry.

Additional Resources: Apart from this scenario of using the Modular Blocks field, we have covered several use cases that demonstrate the use of Modular Blocks in the Modular Blocks - Real World Scenarios guide.

Use “Global” Field for Reusable Fields

The Global field lets you create multiple fields that you can create at once and include in multiple content types. This reduces the need to create the same common set of fields for different content types.

Let’s say you want to create an “SEO” Group field for every content type that consists of the following fields:

• Meta Title
• Meta Description
• Keywords

Instead of creating this in all the content types, you can create an “SEO” Global field with the above fields as its subfields. Subsequently, you can use this “SEO” Global field within any content type, and those subfields will appear automatically on every entry page of that content type.

Use “Custom” Field for customized content

Contentstack provides a set of default input fields that help you create content types. However, if you want to add a custom input field that accepts different data types or looks visually distinct, you can do that by using the Custom field. It allows you to add a custom input field for your content types. Some of the examples of custom fields are color picker, code editor, input table, etc. You also use this field to integrate with third-party applications such as Shopify, Amazon S3, Optimizely, Youtube, and so on.

Reference vs. Select

A Reference field allows you to create a reference to other entries, while a Select field allows you to choose one or more options from a list of predefined choices. These are two different fields servicing different purposes.

You can use the “Reference” field when referring to entries of the same or different content types. An example of this is the “Author” reference field in your “Blog” content type that refers to the entries of “News Authors” content type. On the other hand, when you need to refer to a set of values that you can pick and choose from, you can use the “Select” field for example, a list of age groups or genders to select.

Use of Boolean Flags

If you wish to provide content managers with the ability to decide whether to show a piece of content on a webpage or not, it’s best to use a Boolean input field. A “Boolean” input field accepts a true or false value and shows up as a checkbox on your entry page.

A great example of this field would be using it to show if a product on your e-commerce site is “Available” or is “Out of stock.”

RTE vs. Markdown vs. JSON RTE

The HTML-based Rich Text Editor (RTE) accepts data in various forms, such as text, images, and videos. Content managers can view and format their content either in the code format, using the UI's formatting options, or in the HTML format, using HTML tags. Content managers familiar with basic data types will find it easy to work with RTE fields.

With JSON Rich Text Editor, formatting is done solely through the formatting buttons on the UI. Content Managers will find it easier to format content in JSON RTEs as there is no scope of any confusions. One unique feature of JSON RTE is the ability to embed social media content into the editor.

The Markdown field is an entirely distinct editor that uses the Markdown flavor to display content. It only accepts text in the Markdown format and uses specific tags/formatting instructions to display content in the required format. Markdown text is easy to read and write, and content managers familiar with markdown usage find it easier to edit and format content entered in a Markdown field using HTML tags.

Building a Complex Navigation Structure

When your website has a complex navigation structure, you need to manage several menus and sidebars used to navigate through your site. You can decide how many heading levels you require within your website’s navigation hierarchy. Depending hierarchy levels, you can choose whether to use the “Group” field or the “Reference” field for your site navigation structure.

Use the “Group” field when your website has headings that flow up to three levels deep. However, for a website that has a complex hierarchy with headings that flow more than three levels deep, you can use the Reference field.

Let’s consider an example to understand how you can use “Group” fields and Reference fields to manage your side-navigation menus. Suppose you are preparing documentation for the different API calls used by your content management system (CMS).

Here, add a “Group” field in your content type. Then, within the “Group” field, add a single-line textbox field (for the Title of a section of your API documentation), a multiple-line textbox field (for a Description of that section), and a group field (for a description of the API calls). Within this nested group field, add a reference field (to pull in entries that contain content about several API calls) and a rich text editor field (for a description of the API calls, if needed). The nested group field will contain a reference to the different subheadings under the section.

If the bunched components are multiple in (such as three different API calls), mark the “Group” field at level one in the hierarchy and the nested “Group” field as “Multiple.”

When you structure your content type in this way, you can easily keep adding references to independent “API call” entries within your nested “Group” field. This will help update your API documentation with different API calls under new subheadings.

This technique allows content managers to create navigation menus with ease.

Additional Resource: You can also refer to our guide on Custom Fields to understand how you can add or create custom fields in your content type.

Best practice to refer entries in code

Entries in Contentstack have a unique ID that is commonly known as the “Entry UID”. It's a unique alphanumeric string that is associated with a specific entry. Developers often use the UIDs to refer to entries or render the content of the entries in their code. Here’s an example:

<a href="/blogs/blt123"> Contentstack Headless CMS</a>

While it’s one of the possible ways to fetch entries, it may not be a good practice. If you were to migrate content from one stack to another, the UIDs of the entries would change, and you may have to make changes in your code at several locations.

Recommended best practice: Use values of any unique field

If you want to fetch entries in your code, use any unique field of entry that will not change even if the content is migrated. You can use the “Title” field or add a field specifically for this purpose. Here’s an example of how you can fetch entries using the “title” field:

<a href="/blogs/contentstack-headless-cms">Contentstack Headless CMS</a>