Content Modelling in — Part 2: Reusable Structure

Make your life easier by reusing the structure of your content model.

Michael Kinkaid
7 min readNov 25, 2019


Image shows a doodle of an album and a song content type. Both point to a set of fields that represent app user permissions
It’s not uncommon for types of content to contain the same groups of fields in their design.

Building out a content model in involves making content types and giving them structure with content element fields. If that all sounds like absolute gobbledegook, then you might want to check out Part 1 of this series before tucking into the rest.

Don’t Repeat Yourself

An idea coming from the world of software development is that, when possible, it’s best to avoid repeating yourself. For developers, that means not writing the same code over and over again. Code = work.

When it comes to content modelling, a lot of the work centres around building out the structure of your content types. By structure, I mean the fields that you add to your model that allow content editors to enter in the actual content. These fields are known as content elements.

Image shows an animation of a user dragging a content element field onto a content type.
Model designers can add content elements (fields) to content types to give them structure.

There will be scenarios when you find yourself designing the same group of content element fields across multiple content types. For example, we might want to configure various permissions in our music streaming service. Our permission settings will control how an album or song can be accessed by the user, and whether or not to allow comments.

Because we want the freedom to control permissions at both the album and song levels, we will add new content element fields to both content types.

Image shows a side by side comparison of the Album and Song content types with the same new permission content element fields
On the left we have the ‘Album’ content type. On the right we have the ‘Song’ content type. The ‘Access’ and ‘User Generated Content’ fields have been added to both content types.

We have to manually recreate the content element fields to build out permissions on both content types. Depending on the model you’re designing, you could end up adding repeating content element fields to far more than just two content types.

Either way, repeating the work is a bit frustrating. It’s going to get even more frustrating when things change and we need to update the permission settings across all those content types.

Image shows a side by side comparison of the Album and Song content types. The Album type has an update that the song doesn’t
I’ve added another value to the ‘Access’ options for my ‘Album’ content type. D’oh! Forgot to add the new value to the ‘Song’ content type.

It would be great if these content element fields could be grouped up and edited in just one place so the model designer doesn’t have to go digging in each and every content type. That’s exactly what provides with a feature called Content Type Snippets.

Snippets are groups of content element fields that you can design once and then add to as many content types as needed.

Image shows the content modelling area in Kentico Kontent. It has an area for creating Content Type Snippets.
You create ‘Content type snippets’ in the Content modelling area of

DWe can create a content type snippet to group all our permission settings. We simply add the content element fields for Access and User Generated Content into the snippet.

Image shows the snippet designer for the Permissions snippet with the Access & User Generated Content content elements
The ‘Permission’ content type snippet will contain all of the settings and be used by both the ‘Album’ and ‘Song’ content types.

We can then add the Permissions snippet to both the Album and Song content types. This is done using a special supporting content element called — you guessed it — content type snippet.

Animation shows a user dragging a content type snippet content element into the Song content type and selecting Permissions
Adding the ‘Permissions’ content type snippet is simple with the content type snippet supporting element.

Adding the Permission snippet to any content type adds ALL the fields from that snippet. They will appear wherever you’ve placed them when designing the content type.

Animation shows an editor scrolling down a Song content item. The Permission fields have been added to the bottom
All the content elements defined in our ‘Permissions’ content type snippet are added to the model of our ‘Song’. An editor will see the exact same thing in the ‘Album’ content type.

Using a content type snippet gives us two wins for modelling content:

  1. We don’t need to recreate all the content element fields each time we want to add them to another content type
  2. If we want to add to or edit the content elements, then we only have to do that in one place — in our snippet

Keeping Things Tidy with Content Groups

We want to make life as easy as possible for content editors when they’re adding in new artist, album, and song information. The Permissions snippet is making our life easier as model designers; however, it is making the page they create content on a little long. This is only going to get longer as we develop our model for each content type. Nothing against scrolling, but it can make finding things a little tiring on the eyes.

It’s also not obvious to content editors that these permission fields are actually a related group of settings. It would be good to represent that somehow so they can more easily jump to them when editing. provides a handy feature for not only making these groups obvious to editors, but also improving the general editor experience for content items that have many content elements. This feature is called content groups.

Animation shows content groups being created for the Song content type. This adds a General tab and a Permissions tab.
‘Content groups’ add tabs to the user interface. Content elements are grouped into a General group and the Permissionscontent type snippet’ is added to a new content group called ‘Permissions’.

With the content groups added to the content type, the editor will see tabs when they are creating new content.

Animation shows a content editor toggling between the General and Permissions tab of a song content item.
Thanks to the content groups used in the ‘Song’ content type, the editor will see a tabbed user interface (UI) that better organizes the content elements.

Reusing Structure in Rich Text

Another place where your model structure can be reused is within the rich text content element. The value of doing this is best explained with an example.

The Artist content type has a rich text content element for the artist bio. The rich text content element supports text formatting (bold, italic, etc.). What if we want to extend what editors can do here by allowing them to add some other structured content that is inline with the richly formatted text? This is a very common requirement — especially when it comes to inline images.

Image shows a doodle of an artist’s bio and where an inline image might be placed.
X marks the spot for where we want to add an Inline Image into the rich text field.

The rich text editor in supports inline images; however, those inline images are just that: images. For our use case, we aren’t only sticking an image into the flow of the text. We need more structure than that, specifically:

  • The image file (which will be a Asset)
  • Alternative text to ensure we’re being inclusive of all users
  • An optional caption
  • An optional photo credit

The first thing that we’ll add to our content model is a new content type called Inline Image using the structure defined above.

Image shows the structure of the new Inline Image content type.
The structure of the ‘Inline Image’ content type that will be used within rich text content elements.

Now we can use our Inline Image directly within a supporting rich text content element field. provides two ways of doing this. The first approach is to insert the Inline Image as a brand new content item. This will create the Inline Image, add it to our content inventory, and add the association within the rich text content. Having the Inline Image added to the content inventory will be super handy if the content is going to be reused somewhere else.

However, in this case, it’s really unlikely that we are going to reuse the content. We’re adding ad-hoc images into an artist’s bio, such as pictures from gigs, tours, promo shots, etc. Chances are these images won’t be used anywhere else but in the bio. Also, given the number of artists we’re going to have in our service, if each has a couple of inline images in their bio then our content inventory is going to get junked up with a lot of these ad-hoc inline content items.

Thankfully, has a solution for this, and it’s the second way to add structured content into rich text elements: components. Components allow you to add structured content into rich text content elements without also adding that content item into your inventory. We get to reuse a handy part of our model structure while at the same time creating content we don’t intend to reuse.

Animation shows the content editor adding an inline image component into an artist’s bio.
The editor can add an ‘Inline Image’ as a component into the artist’s bio. An inline image created in this way won’t end up in the content inventory.

As you can see, there’s a lot of scope for working smart with your content model in

  • You can reuse content element fields in snippets and add them to any content type
  • You can reuse the structure of content types by creating components in rich text when you want to author one-time use content

So far we’ve been designing our model without any consideration of the channel (website, app, etc.) that it’ll be consumed on. In Part 3 of this series on content modelling, I’ll explore if and how we need to factor these channels into our design.

For an extended trial of — use this magical link and go sign-up 😎.

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.



Michael Kinkaid

Hmmmmm, what can I say about me? I’m currently the CTO at Reason One, and I wish I had more willpower when it comes to snacks. Oh screw that! Pass the Fifteens.