How do you design a content model that supports content reuse and API delivery?

A quick and easy way to map content is within a spreadsheet. Use each tab to represent a section of content (eg. An event) and list the fields required for the content the first column. These might be event title, image, description, date/time, registration details, venue etc. in the next column, think about the type of content. These might map to the fields supported by your CMS, such as short text, long text, date/time or a related section. Then you can enter sample content into your spreadsheet to test the suitability and titles of each field. In following columns you might include other considerations for each field, such as file types or max file sizes, any conditions or pre-requisites for content or instructions for users.

Content Types: Use content types (e.g., content types in a CMS like WordPress, or schema types in a headless CMS) to define the fields, relationships, and structure for each type of content. Headless CMS Structure: For headless CMS platforms (e.g., Contentful, Strapi, Sanity), you can define content types and custom fields (text, number, image, reference, etc.). This allows for easier content delivery and reuse.

A content model defines the structure of content types within the CMS. Each content type has a set of fields and relationships with other content types. A well-designed content model simplifies content entry and eliminates duplicate content entry. Each content entry typically represents a page or a UI component on the page. Often a content model is designed by analyzing common page components in the visual design, pairing each with a content type.

A content model in a CMS is like a blueprint for organizing and structuring content on your website. It defines the types of content you'll have, such as articles, images, or videos, and how they relate to each other. It's like creating a framework that guides how you create, manage, and display content, ensuring consistency and efficiency throughout your site.

Write a good content once and use at multiple places is an effective strategy to save resources and effort while offering consistency in content.

If you follow the example above by using a spreadsheet to map your fields, you’ll soon start to see fields that might share the same properties or criteria. This allows you to choose the fields that can be reused across your CMS. It helps to avoid naming content fields with their respective sections. For example the type of content added to an event description field will be the same as a person bio field. So naming this as ‘basic content’ is better than having 2 fields for event description and person bio. This makes development and maintenance easier and also makes using the CMS more consistent for users.

An example is with events. Each event might have a venue and a speaker as attributes that each have their own respective content. An event will have a description, a date and time along with other key information. Related to this will be a speaker who has a bio, profile photo and other content. A venue will have a location, website and maybe capacity information. Each can be related by specific attributes, and events might also be related to similar events.

Modern CMSs provide a content API, often based on REST or GraphQL. When developing a headless web application, you must consider the number of API calls required to generate a page, as each call takes time and can negatively impact page rendering speed. One useful feature of GraphQL is the ability to query many content entries and types with a single API call.

Interesting read! Jon Voigt and I did a video on “future proofing” your content - lots of similarities from this. https://youtu.be/PjKGZfxZNqI