Content Modelling in Kontent.ai — Part 3: Modelling for Channels

How to model your content so that it meets the needs of your channels.

Welcome to Part 3 of my content modelling series. If you’re new to the topic then hopefully you’ll find Part 1 and Part 2 of interest as well.

So, why are we modelling content in the first place? Is it just to play around with the cool features in Kontent.ai (of which there are many)? At the end of the day we’re doing it because we want our content to be presented on something… somewhere… so that it can reach its intended audience.

And that audience could be anywhere. There’s really no shortage of options for where you can present content these days: a website, many websites, apps, voice assistants, smart watches, smart TVs, digital signage, within virtual or augmented reality, jumbotrons at sporting events — the list goes on and on (much like this paragraph).

In the buzzword-obsessed world of tech, any place you can stick your content is referred to as a ‘channel’. That’s right — you’re reading this on a channel right now. The channel, or channels, on which your content will be available can have interesting implications for content authoring and, consequently, content modelling. These implications come from:

• What people expect from the channel: The type of content that’s expected from a user (based on the user’s mental model of the channel). I don’t expect to read a book from my smart watch, so it’s no surprise to me that I can’t get the Kindle app on my FitBit Versa. Any content on this channel is likely short and snappy.
• What the channel supports: Content requirements influenced by channel properties (e.g., screen width) and what formats the channel supports (e.g., does it even have a screen?). You might have fantastic images in your content, but that’s not much use to a voice assistant that can only speak.
• What the channel interface needs: Content requirements influenced by the user interface of the channel. Think about all the content requirements of a simple web page: Where does the content for your navigation come from? What about those random bits of text in the page footer?

So, how does our content model adapt to those different channel considerations? To what extent should the channel, or channels, we’re targeting influence how we model our content?

When it comes to modelling for any number of channels, I’d recommend the following advice.

1. You should model core content using an “intelligent content” approach.
2. Unique channel considerations, like user interface text, should be manageable (somewhere).

These two recommendations will be explored in this post and the next. Before elaborating on the first recommendation, I want to explain what I mean by “core” content.

Core Content

In the example of our music streaming service, our core content is the type of content that is core to our business; e.g., content types such as the “Artist”, “Album”, and “Song”.

These content types aren’t coming from channel considerations; e.g., needing something that represents a “Homepage” for my website (we’ll get to those when discussing the second recommendation). Rather, they’re content types that are practically channel agnostic; i.e., content that is valuable to us regardless of where we’re delivering it.

Example core content types for our media streaming service are shown on the left. Other content types that might be in our model, such as representations of channel user interface content, are shown on the right. More on this in the next post 😆.

If we had a website for our music streaming service, then the album content would be available on it. If we redesign our website in a year or two, then, guess what? The same album content will be on that new site. If we launch a mobile app, then the album content needs to head there as well.

Defining these core content types that transcend channels is where you should start. Once you’ve identified the content that matters most, you then want to consider making it “intelligent”. Yup — you’ve guessed it — here comes another buzzword.

Make Your Core Content Intelligent

The intelligent content approach is a collection of content strategy best practices that includes considerations for content modelling. It developed as a solution for the multitude of challenges facing organizations today with their core business content.

Historically, businesses haven’t been great at managing this type of content. If it’s on a single platform then it’s so embedded in there that it’s hard to get out (without bringing extra stuff, like styling, for the ride). If it’s on multiple platforms, that’s likely because someone is manually copying and pasting the content.

For content that is a business asset, we want it easily maintainable and easily consumable on current channels. (We also don’t want to burn the house down completely when at some point in the future we introduce a new channel.) Content can accomplish both of these things when it’s intelligent, which comes from being modelled in a way that is:

• Modular — so that it can be reused
• Structured — so that it is flexible
• Semantically categorized — so that it is discoverable
• Independent of how it is presented— so that it is adaptable

Let’s dive a little bit deeper into each of these.

Modular — so that it can be reused

The alternative to modular content is creating large content assets; i.e., documents, that have many types of content all statically embedded within them. If you want to get at any of the embedded content (for whatever reason — editing, translating, reading it on a channel) then you have to deal with the whole document. This makes your content a little unwieldy to work with, so we break it down into logical parts; i.e., modules.

As covered in Part 1 of this series, we make our content modular in Kontent.ai by creating content types.

Our music streaming service is going to include album reviews. Rather than having one chunky content type to contain all the content for a review, the reviewer, and the album, we break that content down into separate types and use relationships so it can be put back together again in whatever way the channel needs; e.g.,

• Displaying a complete album review
• Displaying information about the reviewer independently from the review

Keeping things modular: the Review content type relates to both the Album and Reviewer content types

Making our core content reusable eliminates the need for editors to copy and paste the same content into multiple places. This keeps our content consistent and also gives us the added perk of reducing content production times and translation costs.

A modular approach will also work better if our content is being consumed across multiple channels. If the channels have different content requirements, then they can get to the types of content they need — without having to request a lot of content they don’t.

Outside of pretty obvious choices (like content that needs to be used in more than one place), how modular to make your content can be a bit of a judgement call.

It can be tempting to break everything up to try and future-proof your content model for any potential channel scenario. At some point that will likely cause challenges for your content team as they try to work out how to navigate your elaborate design. Focus on meaningful content relationships and keep things as simple as you can.

Structured — so that it is flexible

The structure of our review content type includes places to put the review content itself (e.g., title, review copy); a link to the album that the review was written about; and a link to the reviewer who authored it.

Breaking any content down into its structural elements makes that content more flexible because we can put it back together again in many different configurations for our channel.

If you’re delivering content to multiple channels, then it’s likely that the structure of your core content will expand to reflect the requirements of each channel. You might, for example, need different lengths of copy for the summary field of your album review based on the channel’s display properties.

In terms of how NOT to accomplish this, when possible you should avoid unnecessary duplication; i.e., creating separate fields such as:

• Summary for web (site 1)
• Summary for web (site 2)
• Summary for mobile
• Summary for smart watch
• Summary for voice assistant
• Summary for voice assistant (with screen)

Instead, model based on how the content needs to adapt. In this case, we’re looking to adapt based on the length of content required. A more appropriate approach would be to have separate fields, such as:

• Summary
• Short Summary

We can then use content guidelines to help our editors out with understanding how this content relates to our channels:

Our Review content item has two summary fields to meet the needs of our channels. Content guidelines help to give editors a little more context on how these are applied.

In this example, having explicit model references in our core content offers a pragmatic helping hand for our editors. Updating these descriptions is cosmetic and can be done at any time should the guidelines need to be altered to provide different context.

Semantically categorized — so that it is discoverable

We can enhance both the reuse and flexibility of our content by adding a layer of semantics. In a content model, this is done by adding some form of meaningful categorization. In terms of what categorization to add, we typically add semantics to our model that are in line with business goals, user needs, or both.

For example, the ability to search and browse albums by genre is something that both internal users (our editors) and external users (service subscribers) are going to want. Internal users can do this in Kontent.ai:

Semantics can be added to our content by using Taxonomy in Kontent.ai. Here, the editor finds content items categorized into the Classical genre.

When external users browse or search on the channel, then the channel will use the Kontent.ai Delivery API to request and filter the content by the appropriate semantic categorization — our Genre taxonomy.

This aspect of our model is useful for the channels we have today, and it isn’t difficult to see how it would be useful for others. In terms of how far to go with semantic categorization, I would suggest going only as far as needed to meet the business and user needs that you have identified as actual requirements for your content initiative.

Independent of how it is presented — so that it is adaptable

If our core content is heavily influenced by how it will be presented on a specific channel, then that’s generally going to cause issues when it comes to presenting it on other channels.

Not mixing content with presentation is a “known known” in the world of tech. If you’ve ever experienced re-platforming your website to another CMS, then you’ll be familiar with some version of the following conversation:

• Client: “Hey, can we migrate our content to the new platform?”
• Agency: “Hmmm, not without oodles of effort. See, it’s poorly structured and it’s littered with HTML styling that is specific to your old design.”

Ideally we keep as much distance as we reasonably can (more on this in the next post) between our core content and our channels. Kontent.ai has several great features to help you do exactly that.

Not your typical WYSIWYG editor

Most content editors are familiar with the idea of a WYSIWYG editor (pronounced “wiz-ee-wig”), as in “What You See Is What You Get”. Highlight some text, make it bold, green, etc., and this is exactly how it will appear. Better yet, view the source, dump in some HTML code, tinker with it a bit — et voilà —I hope you’ve remembered to make that new code accessible 😉.

Editing HTML in a common WYSIWYG editor, Tiny MCE

The default rich text content element in Kontent.ai takes a slightly different approach to your typical WYSIWYG / HTML editor. As someone working on the content, you can’t view the source. You can’t go sticking in HTML class names, embedding iFrames, etc.

What you can do is format text and create relationships to new or existing content items (which represent embeddable items in the flow of your rich text). It’s up to the channel to ultimately determine how these formats will be presented.

Contextual formatting options in Kontent.ai

The value saved for a rich text content element is still HTML formatted. HTML is practically universal to all digital channels, and the channel can still ultimately decide how to interpret the HTML. If HTML isn’t your thing, then you can always use a custom element to swap in something like a markdown editor.

Image API

You don’t have to be working with multiple channels to understand the complexity of providing images to your target audience. Even a simple website can be consumed on a wide range of devices (all with different screen sizes), with an even wider range of potential download speeds.

How do we ignore the channel requirements when it comes to presenting images, or at least make the effort manageable? I’m sure some content editors reading this are familiar with CMS implementations that ask you to curate and upload just as many versions of the same image as there are channels that you need to send it to.

In an ideal world we’d upload a great quality image for our content and then some magical tool would reformat the image for each and every channel. Thankfully, this tool — Kontent.ai — exists.

Kontent.ai has a truly fantastic image API that the channel can use to re-size, crop, optimize, convert, or zoom in on the focal point of any image it needs to present. For example, the API is creating multiple image variants from the single image shown below through parameters sent in the URL.

One image — multiple variants. All done by query string parameters in the request URL.

It’s the channel properties (screen size, support, etc.) that heavily influence the formatting requirements. Thanks to the image API in Kontent.ai, our image content can be adapted to meet the needs of our channels.

OK — at this point a few of you might be thinking something along these lines:

“So, we’re meant to do all these steps and act like the channel doesn’t exist? That seems a bit daft — I’m making a website! The channel feels pretty significant.”

Indeed it is. In this post, we looked at modelling our core content for channels. In Part 4, we’ll look at considerations for when we might model bits of the channel itself.

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