Content Modelling in Kontent.ai — Part 4: Modelling the Channel

Extending your model with content types that allow editors to manage channel-specific considerations.

Welcome to the fourth and final post on my content modelling series in Kontent.ai! In Part 3 I discussed a few content modelling best practices that help make your core content easily available to multiple channels.

Refresher:

• Core Content — content that’s core to your business. In our example of a music streaming service, this would be content types such as “Artist”, “Album”, and “Song”.
• Channels — anywhere your content is made available; e.g., a website, voice assistant, mobile app, etc.

In this fourth and final post (😥), I want to focus in a bit and look at how a single channel might influence our content model. We’ll continue with the example of a media streaming service. As for the channel, let’s imagine the service is looking to build an online platform and is going to make a website.

Our core content has been nicely modelled and authored in Kontent.ai. Editors know how to create Artists, Albums, and Songs. They know how to create all the relationships between the different types of content.

When it comes to making a website, however, there are likely a few questions your editors will quickly start to ponder:

• How do I make a web page?
• How do I add content to that web page?
• How do I manage the site navigation?
• How do I extend pages with what’s typically considered optional content, such as a “Call to Action”, or an interactive component such as “Newsletter Sign-up”?

Obviously there’s an assumption here that we want editors to be able to accomplish the above goals. This is likely a very safe assumption… because we aren’t evil monsters. Editors will want to manage these very “channel-specific” things. In the case of a website, we’re going to need something that editors can work with that represents (hint: “models”) these channel considerations.

So, what are your options for managing these channel-specific content requirements? How about the tool we’ve been using — Kontent.ai? Can we use that? Spoiler: the answer is a definite yes — but humour me for a few paragraphs.

Kontent.ai is a content management tool (CMS). It’s not, however, a traditional web content management tool (WCMS) such as SiteCore, Wordpress, or Kentico Xperience. Platforms such as these focus almost exclusively on the web channel, and as a consequence, come with all the features you need to create pages, navigation, manage templates, etc.

Kontent.ai is a little different from WCMS. It’s a “Headless” CMS. Headless CMS platforms typically only give one hoot (🦉) about your channel: that the channel can consume content using the API the Headless CMS provides. Outside of this, no other hoots are generally given. They typically have no concept of a web page, or a widget, or anything specifically web. So, assuming you want to empower editors from core content all the way down to the web channel, your options include:

1. Bring another platform or micro-service to the table that’s explicitly concerned with managing the web channel; i.e., an editable head for your headless solution, or…
2. Keep to the one tool (Kontent.ai — phew!) and extend your content model by adding or adapting content types, structures, and relationships for the purpose of addressing channel requirements.

Needless to say, the first option is a bit more involved, as it requires multiple platforms. It’s an approach that some folks in the Kontent.ai community are beginning to investigate:

• Store core content on Kontent.ai (I don’t care about the channel)
• Use Kentico EMS to manage presentation for the web (I care a lot about the web channel)

As much fun as this is to consider (yes, sadly, for me this does constitute fun), it’s really early days for this type of integration. Some exploration has been done with pushing content the other way — from Kentico EMS to Kontent.ai.

Kentico EMS (now Xperience) connected to Kontent.ai, so that it can take advantage of the CDN and Delivery API.

Regardless, there’s going to be additional investment when using multiple platforms. Investment that you don’t have to make because you can manage your core content and web channel requirements all within Kontent.ai (thanks for humouring me on this last post).

With this “do it all in Kontent.ai” approach, we extend our content model with new content types that represent things we need for a specific channel. In this case, the “user interface stuff” for our website channel.

Time to focus on the other parts of our content model — our channel content.

Let’s check out a few typical scenarios for modelling our web channel in Kontent.ai. We’ll start with making a web page. You’ll likely have a few content types that represent specific types of pages; e.g., a review page, an artist page, and — of course — our homepage:

A doodle of the homepage for our web streaming service. I didn’t build it because I think Spotify has the market cornered.

You can see the homepage is itself composed of different elements like a featured album and various calls to action (we’re going to have a featured one at the top and three at the bottom for our subscription tiers). These make up the structure of our homepage content type.

The structure of our “Homepage” content type.

What we’ve done is create a content type that represents the structural layout for this specific type of page. Here’s the content item we’d create using the homepage content type:

This is the homepage content item which is an instance of our homepage content type.

Our Featured Album is another channel-specific content type. This content type links directly to an Album content item created using our core Album content type.

This content item is an instance of the “Featured Album” content type. This is a linked item used within the homepage content item. This “Featured Album” is linking to an album that is part of our core content. The editor doesn’t duplicate album information directly in this channel-specific content item.

Remember: linking content items helps us avoid content duplication. Also, linking any core content item to our channel content item keeps these two things nicely independent of each other. Our core content will survive large-scale changes in our website design because, should that happen, we are only changing the channel-specific parts of our model.

Need to manage navigation? Assuming your website is like 99.99% of all the websites ever created, you’re going to want to make links and then group them together into sets of links for things like the header navigation, footer navigation, etc.

A doodle of the header navigation used on the “soon to beat Spotify” site 💪.

Again we can extend our model with new content types to help editors get the job done. We’ll make a content item to represent a single link, and also a content item that represents a group of links.

On the right we have the model for our “Navigation Group”. On the left we have the model for our “Navigation Link”. The group model has a linked item element (highlighted) that allows it to relate to multiple links.

Here’s the final navigation group content item we’ve created to represent the header and its associated links using our models Navigation Group and Navigation Link:

Our “Navigation Group” content item contains the four links used on our homepage.

What we’ve just created for navigation may be applicable to multiple channels. After all, haven’t we just modelled a reusable information architecture that could be used to power navigation on our mobile app? Be on the lookout for opportunities such as this. You might find that, with a little tweaking, non-core content types that you originally created for a single channel can be extended to work for multiple ones as well.

So, our model has core content types and channel-specific content types (potentially many different types). Our model is going to start to get a little chunky. Ideally there’d be a way to group parts of your model together (I’ve submitted a feature request to Kontent.ai 😆).

What you can do today is use a naming convention to help your model designers (even if that is just you — you’re worth it):

Want to see all content types in a specific group i.e., core, channel-specific, etc? Use the group name as part of the content type name so you can easily filter. Yes — this is a hack for convenience, and yes — names might get a little long. It can still be handy if your model gets large.

It can also be useful for content editors when they’re filtering through content items in the content inventory. Sometimes you aren’t looking for a particular item (if you are, then use the keyword search) but want to see a list of all items by a logical grouping. If I’m looking for a particular type of core content (i.e., all Albums), then I can see “core” at the beginning of the display name. This makes doing this type of filtering a little easier on the brain.

Using a naming convention like this also groups the content types together in the content type filter.

Time to wrap it up! What was originally just going to be one post turned into one, two, three, and now, four (never say never on a fifth). I hope you’ve enjoyed this series on content modelling with Kontent.ai. It’s a fantastic Content as a Service platform, and well worth checking out for your next content initiative.

If you’re interested in finding out more then be sure to check out the Kontent.ai community landing page that lists many great resources.

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