Why you should be modelling content

Content modelling is the process of creating a sound, logical taxonomy structure for the content you create. For example, by structuring an 'author',  'article' or 'service' content model, that atomic unit can be used, reused, adapted and included in other models. This allows the content to be served to web-first and web-only channels and over APIs to other channels.

We will explore the different aspects of content modelling, its history and Luminary’s expertise in this space.

With the advent of headless CMSs or Content as a Service (CaaS), ‘Content Modelling’ has been thrown around as a buzzword. Is content modelling a whole new process? Or has the focus on content modelling changed to a different stage of the Software Development Life Cycle (SDLC)?

Data modelling

For us at Luminary, content modelling is not a new concept. We developers have learnt about data modelling in our uni days and content modelling is an extension of data modelling.

For example in data modelling, we learn about relational, dimensional and entity-rich data models. Then we move on to data abstraction in terms of conceptual, logical and physical models. Finally, we use different modelling processes and techniques to convert conceptual models into logical or physical models.

With relational databases, we would also go through the process of identifying unnormalised data, normalising it and then denormalising it for performance reasons. When building web applications that are not driven by a CMS, this is part and parcel of a developer’s job.

Conceptual data models are created during the design stage of the SDLC. These conceptual models are then translated to logical and physical data models during the development stage. 

Data modelling in practice

At Luminary, our development team has been creating data models since 1999. This data modelling technique has been the backbone of projects such as Clipsal Electrical Design Application and the flight status information module on Melbourne Airport.

Content modelling in traditional CMSs

When it comes to a traditional CMS or DXP, we still need to create content models. To confuse matters, various CMSs call content models different names. You might hear about page types, document types, content types, content templates or page templates depending on the CMS you use.

Even widgets or components used in page builders in traditional CMSs have a content model associated with them. This may not be obvious to a content author, but the developers work with these content models to render content to a page.

When building out a content model in a traditional CMS, a back-end CMS developer would generally take the lead on this. It is usually a very behind-the-scenes job, where the developer would look at the high-fidelity design of pages and components to build out the content models in the CMS. Then content authors would see it in the CMS as a form or a widget where they can enter content. There could be some tweaking of the content model depending on usability and performance.

Content modelling in a traditional CMS usually happens after the planning, wireframing, designing and front-end development. It happens during the back-end development stage and before content creation.

At Luminary, our CMS developers have been content modelling in traditional CMSs since 2004. That’s over 17 years and counting. Our work on CMS platforms such as  Kentico Xperience, Sitecore, Optimizely and Umbraco are examples of this modelling technique.

Content modelling in a headless CMS

With the advent of headless CMSs or Content as a Service (CaaS), content models and the content modelling process have become more visible to content creators. This increased visibility is because, with a headless CMS, content authors can create content before any front-end or back-end development has started.

Content modelling can begin soon after wireframing begins and before any development work. As we see components and patterns begin to emerge during the wireframing stage, we can start creating content models. This is a collaborative process that involves all disciplines. You can read more about it later on in this article. Auditing historical content (which needs to be migrated across to your new website) is another avenue for identifying content models.

While content modelling is an extension of data modelling, it does have its own processes and techniques which we will delve further into. We will also look at what extra considerations are necessary to make the best use of a headless CMS.

Omnichannel delivery

Usually, with a traditional CMS, the content is targeted at a single web channel. If the content is also targeted at a different channel such as an FAQ bot or a mobile app, it is often more of an afterthought.

But when it comes to content modelling in a headless CMS, we need to consider all delivery channels. These include but are not limited to the following:

• Web (This includes multiple web channels such as a primary website, regional or state-based websites, multiple micro-sites and landing pages)
• No-UI
• Smart displays
• IoT devices
• Social channels
• EDMs

When thinking of multiple channels, we need to stop thinking about layouts, colours, and placement. We need to concentrate on the data and how it relates to other content delivered via those channels. If done correctly, all our channels should be consuming from the headless CMS, which is the single source of truth.

Involving all disciplines

With a traditional CMS, the back-end CMS developer is the owner of the content model. The content modelling process is a black box to everyone outside the development team. The process of converting wireframes to lo-fi designs to hi-fi designs to front-end markup refines the way components are structured and utilised. This in turn lets the back-end developer refine components for creating content models.

With a headless CMS, the content modelling process is a transparent one where the content strategist, IA and UX practitioners, designers, content authors and developers all work together. Note that more thought needs to be put into creating content models from wireframes rather than when creating content models from high-fidelity designs. But with the benefit of creating content earlier, gaps in content models can be identified early on and fixed with less technical debt.

Though multiple disciplines may be involved in content modelling, we recommend that the development team owns all content models for a project. With a headless CMS, it’s easier than ever for a content author with elevated privileges to modify content models. But changing content models without proper planning could lead to unintended consequences like breaking your website.

Layers of a content model

When speaking of content models, it is important to talk about the different layers of a content model. 

Content attributes come together to create a content model. These attributes could be of the following data types which translate to different editor interfaces within the CMS. 

**NERD ALERT** – Skip past the next two tables if you don’t want to get too much into the details.

For example, a product content model might be defined as follows:

These attributes form a content model (or a content type). Various distinct configurations of content attributes form unique content models within a system. The urge to shoehorn different content models should be avoided here. CMSs that provide inheritance (think of a blog post as a type of article) and composition (think of a page as a combination of hero banner, content, call to action etc.) have a definite advantage as you can still have unique models with less overhead.

The example below shows different content models (called Document Types in this CMS) for different content types such as Blogpost and Contact.

The assembly model looks at where content authors will put individual content items (or instances of the content models) together to make web pages, campaigns, documents, or other content products.

For example, a Blogpost can be made of a Hero Banner, Content, Author and callout content models. Having content models be atomic in nature allows for this assembly model to work well without duplicating content.

Tools and techniques we use at Luminary

Since content modelling in headless CMSs has become more transparent, we need to take our customers on this journey. We need to engage the product owner, project stakeholders and content authors when defining content models early on in a project.

This involves a bit of education and collaboration between our team (Strategy, UX, UI and development) and the client. We would start off with a Miro board that explains a content model, its layers and its uses. We then take an existing page and break it into different components as an exercise for our client. 

These content models are then recorded in detail on a spreadsheet. 

Once content models are recorded on a spreadsheet, the developers would review them and have further discussions with the team before implementing them on the CMS. At this point, the ownership of the content model transfers to the developers but enhancements to those models are encouraged to keep them relevant.

Content modelling on a headless CMS is not a buzzword, nor is it a new concept. It’s an evolution of data modelling and content modelling in traditional CMSs. Content modelling has evolved to be a more collaborative process earlier in the Software Development Life Cycle to make your content and content models more resilient over time.