Content modeling best practices

This article introduces you to content modeling best practices and some tips on how to build a scalable schema for developers and ensures a smooth user experience for content editors.

Common challenges

Models vs components

While modeling your content, you may be in doubt about when to choose a model instead of a component and vice versa. Consider the following points when choosing a model or a component:

• Models focus on what the content is, so usually you start with creating models for your main content, like pages, articles or case studies.
• Models are perfect for reusable content, like categories that can be used in multiple models, like articles and case studies.
• Components often focus on how the content looks, like buttons and sections of a page.
• Choose components for content consistency and presentation.
• Components are great for reusable structures in your front end, like page headers.

In conclusion, use the general guidelines above, but keep an open mind for exceptions.

Simple vs scalable

When modeling content it's important to create a simple, yet scalable schema. A scalable schema has a flexible structure that can easily grow and adapt as your needs evolve. If you make it too simple, it might not be scalable enough and vice versa. Follow the guidelines below to find a balance between simplicity and scalability in your schema:

• Start small with a minimum viable schema by focusing on essential models, fields, and relationships to support core functionality and immediate goals.
• Avoid “what if” over-engineering. Add fields or relationships only when they bring real value.
• Prioritize editor usability to keep their workflows simple, but leave room for refinement as needs evolve.

By following these guidelines, you'll create an efficient and adaptable schema.

Nesting models and components

Nesting is structuring models or components in a hierarchy, where one model or component is embedded in another. Nesting simplifies content management by breaking down content into smaller, reusable parts.

Example of a nested structure.

Nesting in content modeling is quite logical for developers because it mirrors the way content is typically structured and consumed in the front end. However, a completely flat structure makes editing very simple for content editors.

So, it's important to find a middle ground when nesting models and components. Consider the following points when deciding how deeply to nest models and components:

• You might choose deeply nested schemas to accurately reflect relationships. But, this can make schemas difficult for editors to manage because they need to drill down multiple levels to make basic changes, which slows workflows and increases the risk of creating errors.

Example of deeply nested models.

• Flat schemas rely more on field conventions and references instead of nesting. This simplifies editor workflows but requires discipline in naming conventions and content structure.
• Flat schemas reduce the mental load for editors and make content easier to query and scale.

Page vs Article

A page consists of modular elements so it has to be flexible for custom layouts. While an article needs to be structured for consistent formatting. In Prepr, you can enable modular page elements in the page model by using a Stack field. To ensure consistent formatting in the article model, you can use the Dynamic content field.

The table below indicates the key differences between the two fields and essentially the structure of the Page and Article models.

Factor	Stack field for pages	Dynamic content field for articles
Flexibility	Highly flexible for custom layouts.	Structured for consistent formatting.
Editor Workflows	Editors build pages by stacking pre-configured blocks, such as image galleries and text blocks.	Editors fill in predefined fields like title, body, and tags.
Reusability	Focus on reusing layout components across pages.	Focus on reusing content elements like tags and references.
Optimization	A/B testing and adaptive content	-

Developer considerations

Generic vs specific models and components

A generic model or component is a flexible model or component, for example, a Button component with a styling field like Button type with the options, Primary and Secondary. Instead, you could opt for separate models or components to make your definition specific, for example, a Primary button and a Secondary button.

There are no hard and fast rules to choose generic over specific models and components, but note the following considerations when making this decision:

Factor	Generic	Specific
Flexibility	Highly flexible with many options.	Purpose-built for specific use cases.
Ease of Use	Can overwhelm editors with too many choices.	Simpler for editors, with fewer decisions.
Maintenance	Easier to manage one flexible model.	Multiple models may lead to duplication.
Scalability	Scales better if options are structured well.	Becomes harder to scale with too many models.
Front-end logic	Requires conditional logic in code.	Clearer frontend integration for developers.

Mapping front-end components to your schema

The schema and front-end often evolve independently, leading to inconsistencies between the schema and front-end components. Misalignment can make it hard for developers to translate CMS content into front-end design efficiently.

To resolve this challenge, you can align your front-end components directly to the defined models and components in your schema.

Maintaining your schema

Consider the following tips to make it easier for you to maintain your schema.

• Create a modeling templates library in a repository like GitHub. This is useful when you work on multiple projects with similar requirements. For example, you could have templates for a Page, Navigation, Article, or FAQ.
• Use the Schema sync feature in Prepr to keep your development, testing and production environments in sync.
• Use clear, consistent names for models and components.
• Include terms like Grid, List, Card, or Carousel to describe their purpose.
• Document your naming rules to keep your team aligned.

We trust that these best practices and tips can help you build a schema that meets requirements, scales and supports a smooth content editing experience. Check out the schema fundamentals doc for essential concepts and considerations to get started with building your schema. If you still have questions or doubts, please feel free to register for the Content modeling workshop (opens in a new tab).