Introduction to content modeling. Part II

Going deeper into the concepts of content modeling: custom types, repeatable types and single types, static and dynamic zones

We'll start with an overview of content modeling, then go through the steps of modeling a web page, and wrap up with some best practices.

What is content modeling

Content modeling is the process of taking a website design and figuring out how to structure the content in a CMS. You start by determining how to break down the content into sensible chunks for authoring. Then you need to take the design of each chunk and figure out which content fields you need to provide a content author for them to be able to create pages and write content.

Identifying Custom Types

The first step of building a content model is to figure out how your website content will break into different custom types.

What is a Custom Type

Custom types are the base level structure for your content. Inside of each custom type, you will add all the content fields (images, text, embeds, etc.) you need for that type.

There are two categories: Repeatable Types and Single Types. Repeatable Types are for recurring content pieces such as article pages, products, places, etc. Single Types are for unique content piece, such as a homepage or a privacy policy page.

Most of the time, breaking down your design into custom types is rather straightforward: 1 custom type for each type of page you have on your site.

Example: For a simple website with a blog, you might have Repeatable Custom Types for your content pages, a Repeatable Type for your blog pages, a Single Type for your Homepage, and a Single Type for your website layout (header, footer, & navigation).

Sometimes the custom type breakdown is more complicated than this. The practical examples on this website show how to deal with different use cases.

Breaking down the page design: what's static, what's dynamic

After you've determined a custom type, the next step is to figure out which fields are static and which content you want to be dynamic.

Use the interactive model below to see an example of determining the static or dynamic fields of a design.

Static Fields
Dynamic Zone

The Static Fields

The static fields are always present in every instance of the Type. In this example they would be the Title, Publication Date, and Author.

1 of 2
< PreviousNext >

The Dynamic Zone

The dynamic zone will allow authors to mix and match different elements to build out the content for the page. In this example they would be the Text, Images, Videos, etc.

2 of 2
< PreviousNext >

After figuring out where your Static & Dynamic zones are, you need to break down the design to determine which content fields are needed for your specific design.

Static fields

The static fields for a custom type are the fields that you will always need for a given type.

Let's take the example of the blog post given above. We determined that the static fields were the title of the blog, the release date, and the author. The rest of the content we will want to be dynamic so that the content author can freely write their posts. But these three things are consistent from post to post.

You need to determine which content fields you need to add to your custom type so that the author can control this content. Check this out in the interactive design below to see an example of this.

Dynamic zone

By contrast to the static fields, the dynamic zone is where you allow a content author to create page content from different micro-components. In the example of a blog post, this would be the main blog content.

After identifying the dynamic zone, we need to break the content up into the elements that your authors can mix-and-match. (In Prismic, for example, these elements are called slices.)

For the blog post design presented above, the needed elements are Text, Images, and Videos. We will create a slice in the Slice Zone for each element we need.

See the interactive model below to see required content fields for each slice.

Interactive model

Explore the interactive model below to see how each field will be modeled. You can highlight the static or dynamic zones with the toggles below and click on the different elements of the design.

Static Fields
Dynamic Zone

Blog Post Title

A title will appear on every blog post. In our Blog Post custom type we will add a Title field for this.

1 of 6
< PreviousNext >

Publication Date

Each blog post will have a publication date. We will add a Date field for this.

2 of 6
< PreviousNext >

Blog Author

We will add a Text field to our custom type to enter the blog author's name.

3 of 6
< PreviousNext >

Text Slice

The first slice we need is a Text slice. This will consist of a Rich Text field.

4 of 6
< PreviousNext >

Image Slice

We need to allow the content authors to add images to their posts. For this slice we will need an Image field for the image and a Rich Text field for the caption.

5 of 6
< PreviousNext >

Video Slice

The video slice will consist of an Embed field which will allow content authors to paste YouTube or Vimeo links and add videos to their posts.

6 of 6
< PreviousNext >

Note that there are usually multiple ways to configure certain fields. For the simplicity of this example we are choosing a Text field to enter the author's name, but there are other methods for doing this.

Example: Building the custom types in a CMS

Once you've determined all the pieces of the content model that you need, you'll then actually build it in your CMS.

Here is how you would do it in Prismic, for example: Writing Room, the web app for managing content, has a drag-and-drop custom type builder that makes creating types and adding fields rather straightforward.

Same applies to the slice zone as well.

Content modeling best practices

You should always keep in mind that when you build a content model, you are determining the content author experience – for weeks, months, or maybe even years. The way you model your content and build your custom types will directly impact how convenient it will be for them to create and edit pages. Keep it in mind when you build your types and try to make them simple to use – not only for front-end developers, but also for content teams.

One way to make custom types easier to use is by organizing your content fields into relevant tabs. This can make content fields easy to find and edit for the author. It will also prevent documents from growing too long and becoming difficult to edit. In the following image you can see two tabs: Main & SEO.

Also, it's helpful to have the flow of the content model match that of the web page. Generally you will want the authoring experience (editing tabs from left to right and each tab then from top to bottom) to match the flow of the end webpage. This will make the custom type user-friendly and easy to edit.

How to model content for your project Nathan will be glad to help you come up with a solid content model for your project. (It’s free.) Schedule a call