March 26, 2019

Solving Design Challenges in a Headless CMS

Mike Wills

Vice President of Technology

At BlueModus, we advocate a content-centric approach, including a content-first approach to design, and a content-as-a-service approach to implementation. This process enables a website to be designed around the conversations an organization wants to have with its customers, and allows for the engagement of customers across multiple channels, including websites, digital marketplaces, emails, mobile apps, and even digital assistants. But along with all these benefits, implementing a headless CMS introduces new challenges, because a website’s presentation is disconnected from the content.

Consider a traditional CMS. Authors often enter content directly in pages, including specifying how the content should be presented. For example, when creating a call-to-action section, authors would not just provide a headline, summary, image, and link, they would specify background color, padding, and so on. In a traditional CMS, content and presentation are intertwined, so it’s natural to add whatever properties are needed to control the presentation.

In contrast, the goal of a headless CMS is to keep the content separate from presentation, so the content is a first-class enterprise asset that can be reused wherever it’s needed – not just on websites but wherever there is an opportunity to engage customers. So, when designers and developers collaborate to build a website using a headless CMS, a new challenge naturally arises: Where can layout and style configurations be provided?

A HYBRID APPROACH

The answer is easy if using a hybrid approach. That is, a content-as-a-service solution can be built providing content to multiple channels, while building a website with traditional CMS presentation tools (e.g. widgets, web parts, templates). For example, Kentico 12 can be used to create a content repository, with a Web API to serve multiple channels, while using Kentico 12’s MVC page builder to provide design and layout configurations. With such a solution, authors could reuse content across multiple channels, but still configure how the content is presented using widget properties.

HEADLESS CMS, DESIGN CHALLENGES

In a pure headless CMS solution, the options are not as straightforward. For example, we have a project for a customer with a $1 billion-a-year e-commerce website with demanding performance and integration requirements, being built using ASP.NET Core and a microservices architecture. Since there is no configurable presentation layer, the challenge of where to put design-specific configurations surfaces. Here are some examples:

Where can we have authors specify design-specific configurations like background colors?
How do we control how an image should be treated in a responsive design? Should its aspect ratio be preserved, or can it be cropped? If it can be cropped, where is its focal point?
Can we specify media icons to be displayed with a list of links? (In a traditional CMS, we might add CSS classes to the links. However, those classes would be useless or even conflicting within other contexts.)
How do we specify context-specific layout parameters, like padding? (If added directly to the content, it could not be used in multiple contexts.)

In a traditional CMS, the tendency is to have authors provide page and widget configurations to apply design rules. While this is straightforward and often makes life easier for developers, it also has drawbacks:

A website’s design is only as consistent as it is governed. This method leaves design consistency in human hands.
If design changes are required, this may result in major content maintenance. In fact, content may not survive a major redesign.
Content is embedded in the site design and cannot be leveraged in other customer engagement channels.

PRESENTATION LAYER GUIDELINES

To solve these challenges, the way in which design rules are applied requires a new approach. In general, presentation layers must be smarter and, as much as possible, authors should not be concerned about channel-specific presentation. They should be allowed to focus on the content. To that end, here are the guidelines we find helpful:

SMARTER PRESENTATION LAYERS

In a traditional CMS, we are used to supporting design variations by adding configurations in the authoring experience. For example, a design might require extra padding at the top of the section if it follows a section with a darker background. Or, it might require less padding if the section’s headline is preceded by an icon. A designer might convey these guidelines to an author, which would translate into a need for design properties that authors control.

Notice our instinct is to give authors the job of interpreting design rules. However, in a headless CMS, context-specific configurations would prevent content reuse. For example, a piece of content might need extra padding in one page or channel but not in another. So, if we added a top padding property, the content would become useless in other scenarios. However, one of the goals of a headless CMS is to free up authors so they can focus on content. So, we make the presentation layer as smart as possible – that is, design guidelines are translated into rules and enforced by code.

Consider the earlier example. Code can certainly be used to alter padding depending on the background colors of two sections, or the presence of icons that help breakup content. In short, if there are any layout variations that can be determined by making the presentation layer smarter, it’s a win-win. It makes the design more consistent and the author experience simpler.

CONTENT METADATA

Ideally, authors should focus on content, not presentation. However, there will be times the presentation layer needs some human guidance from the author. For example, authors may need to specify whether or not an image can be cropped or scaled on mobile devices. Often, the instinct is to provide a layout-specific property like “sizing method”. To avoid this, we can provide better information in the presentation layer by using metadata. The presentation layer doesn’t really need authors to provide layout instructions. Instead, it needs more information about the content itself.

For example, if the presentation layer contains metadata indicating the type of image (e.g. ‘decorative’ or ‘infographic’), as well as the image focal point, it can determine if the image can be cropped and how to crop it on a variety of screen sizes. Furthermore, the metadata would be useful on all presentation layers, because it remains true about the image in all contexts.

We can also use content metadata to solve a design problem mentioned earlier. A design may require different media icons for a list of links. Again, our instinct may be to have authors provide a decorative icon for each link. However, the presentation layer may really just need metadata about the links, such as the type of content targeted by them (e.g. email, download, map, phone, etc.). With this metadata, useful across multiple channels, a presentation layer can decide how to decorate the link.

To apply this guideline broadly, whenever we feel the need to add layout-specific properties to the content layer, we first ask if we can solve the challenge with metadata about the content. This allows us to use pure content information that will be true about the content in all channels.

INESCAPABLE EXCEPTIONS

Despite making presentation layers as smart as possible and keeping the content repository as pure as possible, there will be cases in which the most reasonable solution is still to add layout properties to the content layer. For example, a presentation layer may support displaying a call-to-action section with multiple layouts, like a full-width layout with a background image, or a split layout with a decorative image. While there will always be cases like this, it’s important to ensure they are limited and that each one is truly necessary. Imagine if the headless CMS is used for three presentation channels. The number of layout properties could become out of control if they are added too liberally. So here are some questions we ask ourselves before adding a layout property to the headless CMS:

Is this property really necessary? Can the goal be achieved by making the presentation layer smarter or providing metadata about the content?
Is the property useful across multiple presentation layers? If not, how could it be made more generic and useful?
Can one property be used instead of many? For example, perhaps a theme property could be used instead of multiple color properties, or a style property instead of multiple layout options.
Can the design be simplified to make this unnecessary? If an equally high-quality design eliminates the need for adding complexity, it will enable keeping the author experience simple and keeping the design consistent.

Creating an optimal headless CMS involves a thoughtful balancing of design, authoring experience, and content reuse. The most successful implementations involve collaboration between designers, developers, and headless CMS advocates, to balance these challenges. However, the payoff is a strategic game changer, that enables content reuse and supports emerging media channels. If you’re ready to begin creating a powerful content ecosystem that will allow your company to compete in emerging marketing channels, our BlueModus strategists would be glad to guide you through the process. Give us a call today.