Content Modelling in Kontent.ai— Part 1
Getting your model started with content types, structure, and relationships.
Kontent.ai is a fantastic Content as a Service (CaaS) platform. It’s a place to work on your content before you publish it to a channel (website, app, voice assistant — basically anything that can make use of the platform’s Delivery API).
To get started, the first thing you need to do is create a model that your content can be put into. The model represents the content and describes that content in terms of content types, structure, and relationships.
As an example, for a music streaming service, our model would have an artist (a type of content) where we could write the name, bio, and genre (the structure of the content); and each artist would have albums (a content relationship between an artist content type and an album content type).
Let’s explore these three things and build them out in Kontent.ai. You can sign-up for an account over at https://app.kontent.ai/.
Content Types
How do you tell which parts of your content should become content types? Content types are typically the nouns in your model. They’re the things in the topic your content is related to. In the case of our music streaming service, these would be things like an artist, an album, and potentially a song.
You can use the content model section of Kontent.ai to start defining your content types.
So why did I say “potentially a song”? Here’s the rub when it comes to content modelling: you’ll have to decide just how far you go with breaking the content up into distinct types. But how do you decide? Well, outside of the obvious (we’re going to need an album content type), you should consider the following:
Promote content reuse
The model should allow content to be reused. Editors shouldn’t be expected to enter the exact same content multiple times. This keeps our model flexible. If a song appears on an artist’s album and their ‘best of’ album, then with a separate song content type, the editor just has to create the song once and link it to both albums.
Take a ‘content first’ approach
Your content likely doesn’t exist in a vacuum. Whether it’s intended for a website, app, or something entirely different, you want to start designing and discussing the content requirements with your team or client at the very start of the project.
Brainstorming the purpose of your content and how that content will be presented will help firm up the overall requirements for your content model. These content requirements should inform things like design and development more so than the other way round. For example, maybe we don’t need a separate song content type if all we ever do is list the song names. In that case they can be added to a text field directly in the album content type.
Balance content flexibility with the effort to create it
Typically, the more flexible the model is, the more abstract it gets, and the more steps it may take editors to put the content together. Because of this, you have to balance flexibility with the work effort to actually author the content in the first place. You might look lovingly at a music service content model with 30 flexible content types, but if an editor has to enter content into half of these just to make a single album, then you’re going to get tapped on the shoulder.
Structure
Once you’ve identified a content type you’ll likely roll straight into giving it structure. By structure, I’m referring to the exact content you want to store and, ultimately, present on some channel. For our artist content type we’re going to capture their:
- Name (text)
- Bio (rich text)
- Genre (some type of categorization)
To capture this information in Kontent.ai, you add fields to the content type. These fields are referred to as elements in Kontent.ai vernacular, and can be used for entering in content directly (plain text field, rich text field, etc.). They can also be used to support your content in some special way — such as adding in a URL ‘slug’, which is a unique path for the content on a website (e.g., facethemuzak.com/some_slug).
Kontent.ai supports a whole bunch of these element fields, as shown below:
With the structure of the artist content type setup, editors will be able to create new artists in the content inventory in Kontent.ai.
The Genre field in the artist content type is an example of taxonomy. Taxonomy can be used to add categorization or tagging to your content, and is another way to add more structure to the model.
This is an example of content reuse. We want to categorize the genre both for the artist and for their albums. Rather than writing out the entire list multiple times, we write it out once in the Taxonomy area of Kontent.ai.
The Genre taxonomy group can be edited in one place and then added to any content type that we wish to use it on.
Relationships
Breaking content up into types helps to make it reusable. It also makes it more accessible. Rather than having one BIG artist content type that contains each and every field for an artist, their albums, and all their songs, we’ve created distinct content types for each. This means that if I just want to get the info about a single song, I don’t need to retrieve the artist’s full back catalog from the API just to get at it. I just use the API to query for that particular song.
This is all great for managing and accessing content in a modular way, but what if I actually do want to get the information about an artist, their related albums, and the related song information from those albums? How do any of those content items know how they relate to each other?
The answer is that the relationships are defined explicitly in the content model. The primary way of linking content items in Kontent.ai is by using the linked items content element:
The linked item field can then be used by editors when they’re working on an artist content item to create the relationship between the artist and their album(s).
Linking a content item to another content item can also be done in rich text. This flexibility to relate content rather than recreating it is another way in which re-use is promoted in Kontent.ai.
This feels like the right spot to wrap up Part 1. In this post I’ve highlighted how modelling should help promote content reuse. Write your content once and use relationships to reuse it. In Part 2, I’m going to explore how you can reuse the actual structure of the model itself.
I’m thinking this article could make a decent video tutorial. That would let me go into a lot more detail with the Kontent.ai app. Tell you what: if I get a hefty number of claps then I’ll roll up my sleeves and get recording. Bribery? Who, me?
For an extended trial of Kontent.ai — use this magical link and go sign-up 😎.
