Implementing a headless CMS architecture in Kentico Xperience

Remember when a CMS was primarily used for laying out content on web pages? At the time, this satisfied website management needs. However, the industry is changing and digital experience platform Kentico Xperience is leading the way. Read on to find out how and to learn more about two principles you can use to ensure omnichannel success.

Customers are no longer finding companies because of their great websites. They are discovering companies, products, and services because of great content. Are people finding this content by clicking links in search results and engaging our websites? No. They are engaging content in Google search snippets, info panels, voice searches, and social media. Ask yourself, when was the last time you were engrossed in an article that you weren’t looking for? Was it in LinkedIn? How about the last time you needed to look up something? Did you find what you needed in a snippet or info panel? There’s no doubt about it, content is king, and forward-thinking organizations must manage content for the many content channels people are engaging.

Competitive organizations are embracing omnichannel marketing and ensuring their content is understood by search bots to support Google knowledge panels, snippets, and voice user interfaces. To accomplish this, organizations are turning to headless CMS solutions, or hybrid CMS (such as Kentico Xperience) that support both a headless and traditional CMS architecture. However, adopting a CMS that supports rich-structured content types and provides a robust API (such as Kentico Xperience) is not enough. I learned the hard way that approaching the CMS solution with my familiar design-system approach could ruin the content strategy. You can read about my painful epiphany in the article A Content Model Is Not a Design System on A List Apart. I realized that instead of creating a content model to fit a design system, it must serve the needs of the content strategy by being semantic and connected. Here, I’d like to give an example of how to apply these two principles when implementing a content model in Kentico Xperience, but first, in case you didn't read the article, here's a summary of these two principles:

1. Content models must define semantics instead of layout. A semantic content model uses names that reflect the meaning of the content, not how it will be displayed. For example, a non-semantic model might have types such as teasers, media blocks, and cards, but a semantic content model would have types that allow each delivery channel to understand the content, such as product, event, and testimonial.
2. Content models should preserve content context instead of being sliced to fit design systems. A good content model connects content that belongs together, so that channels don’t have to know how to stich pieces back together before delivering it.

In the A List Apart article, I provided some obvious semantic examples, such as events, press releases, and questions. The article also describes how creating types that provide all the fields necessary for each content item makes the content much easier to manage and deliver to various content channels. For instance, putting all the fields necessary to populate an event in one page type, would keep the event content connected, easy to author, and easy for any platform to consume.

The need for the articles and FAQ items to be connected, standalone pieces of content may be obvious, but there are many other pieces of content on a website that retain their full value only as a connected whole. Much of this content becomes less usable when broken into subatomic pieces. Whether a content item is small or large, a content model should connect content that belongs together. In Kentico Xperience, this often means creating types with all the fields necessary to manage and deliver a reusable piece of content. The key is that if content belongs together, it should be kept together from content creation all the way to each delivery channel. 

A common example

To make the concept of semantic and connected types clearer, let’s examine how we might apply these principles to a less obvious example in Kentico Xperience. Imagine a website that needs to provide a list of featured content displayed in the card layout below, and that the same content must be reused in multiple delivery channels (such as multiple pages and emails), using a headless, API-centric model. 

If you are like me, you are used to thinking about design principles and would naturally slice what you see into design components such as a section title, call-to-action cards, and a call-to-action button. This is exactly how we achieve efficient reuse of design components. However, this design-system thinking can lead to dividing the content by design boundaries and make the content more difficult to manage and reuse. If trying to make all the content reusable, this could lead to dividing the content into three page types: Section Title, CTA Card, and Simple CTA.  An author might need to populate several content items in the tree and then select the content in three separate widgets: Section Title, Card Layout, and CTA Button. Can you imagine how tedious this would be for content authors? How about how difficult it would be to reuse the same content in an email?

This might make perfect sense from a design system perspective, but it has several problems:

• If you wanted to reuse this content in another channel, such as in an email, you would have a hard time getting all the pieces. Notice that in the above solution, the content is only related together in the Kentico Xperience Page Builder. Retrieving the title, description, feature items, and button content would require extracting all this information from the Page Builder’s storage. The content would be very difficult to reuse.
• Even if all the content components could be extracted, the delivery channel would have a hard time understanding what the content is. Are they press releases, videos, events, articles, or manuals? The system can’t tell and will have a difficult time providing the appropriate UX or embedding the appropriate Schema.org structured data.
• The authoring experience is very cumbersome. The author would need to create eight different items in the content tree, and then add and configure three different widgets to display it. In the CTA Cards, the author would probably be reentering titles and descriptions for content that already exists in the system.

Applying the principles

So, what happens if we apply the two principles to make sure content is semantic and connected? We might dig into the content requirements and discover that the CTA Cards are pointing to a variety of types of content, Press Releases, Videos, Events, and Articles. Even better, these content items are already in the system, so that if we ensure each one provides a title, thumbnail, and short description, authors won’t have to reenter the same content in separate CTA Cards. The target items can provide their own summary content.

When we think about connecting the content—that is, keeping content that belongs together connected together—we’ll realize that the title and description of this list belong to the list. They are the list’s title and summary and would be meaningless on their own. Additionally, the CTA button at the bottom belongs to the list. It is the link for getting more resources such as the ones above it.

Putting this together, we realize we only need one page type, Resource Collection with the following fields.

To create the content, the author would create one new content item, enter the title, description, and more-link content, and then relate the existing press releases, videos, events, and articles, as illustrated below.

At this point, the content is ready to be consumed in any content channel. An email could easily request the resource collection and have all the content pieces that are necessary to render it. You could easily add a Web API that returns the content to a mobile app or another website to support a headless architecture. It would not require stitching the content together, from instructions extracted from the Page Builder. Additionally, the content is much easier to create and manage.

In the same way that the connected content is easier for alternative delivery channels to consume, it is easier for Page Builder templates and widgets to consume. You could simply create one Card Layout widget that allows authors to select the Resource Collection content item. The content model intrinsically connects the content, the widget understands the content and renders it with its design system just as the email designer understands the content and renders it with its design system.

Closing

Instead of slicing this resource collection into standalone components based on the design system, the content model makes it easy to keep the necessary parts connected and semantic, providing the following benefits:

• The content is much easier to create and manage.
• Each delivery channel can consume and render the content with an independent design system.
• The semantic types allow structured data to be embedded so that Google search snippets and info panels can understand the content.

By adhering to these two principles, keeping content models semantic and connected, you'll avoid the jarring authoring experience described in A Content Model Is Not a Design System and ensure your solution is ready to deliver content to whatever delivery channel the future may hold.

Have questions on how to get the most out of your Kentico Xperience implementation? Drop me a line on Twitter (@HeyMikeWills), view my other articles here, or join me at Kentico Xperience Connection 2022.