From Clutter to Clarity - Making the Most of Your Headless CMS

There are hundreds of Content Management Systems (CMSs) out there. 

And if that wasn’t enough, someone proposed a Headless Content Management System (HCMS) and now we have hundreds of those too.

What are CMSs anyway? 

The simplest answer is they manage content for you.

So, how do they do that?

Developers spend time translating a UI design into a structure called a “Model” or a "Content-Model" which is the meat and bones of the CMS. These models have text inputs, rich text editors, dropdowns to choose other models, and several groups of these in any combination whatsoever.

A non-technical user or a content writer can then use these models to add content that later gets shown to the world on a shiny website or a blog.

Some CMSs like WordPress are so powerful that they let you build the pages and manage the content all in the same place. This can save development costs and time.

We had CMSs, what did we need HCMSs anyway?

The advancements in designs, the need for more slick websites, and the evolution of Ajax, led us to the invention of Headless CMSs. These CMSs work similarly to their ancestors but don’t care where the content ends up eventually.

Now, let’s try to understand what headless CMSs are.

Understanding HCMS

Developers connect these models to pages of a website or a blog. All the content is available through APIs. These APIs are exposed by the CMS itself to provide a smooth way of accessing the content.

Traditionally we had monolith applications, where the server and the UI reside in a single unified capacity. Eventually, we got to the point where we segregated backends and frontends to achieve greater flexibility and scalability. With segregation between frontend and backend, we segregate design and content in frontend as well. This gives us  even more flexibility and scalability.

A team can work on the content without having to worry about the design implementations and vice versa. But sometimes developers might also manage content, so watch out for that. That's a red flag there because it is not something they should be doing.

From now on, we’ll assume that you have some understanding of models and the workings of CMSs in general. If you’re new to CMSs, don’t worry, you will still learn a lot from this blog.

What Should A Model Be?

It depends on the type of the content. 

Sometimes, the content is just too obvious, for example, a testimonial. A testimonial will almost always be a standalone model. 

This model can have an Author Name, a quote, the author's company, etc. as shown in the image below.

The image shown above is from Strapi CMS. 

You can see an actual model named “Customer Testimonial” that represents the testimonials shown all over the Arbisoft website. 

You can also see various fields in this model e.g. name, designation, etc, which represent all of the elements of a testimonial. 

By looking closer, you will also notice some unrelated fields like category, priority, and page. 

These fields, though unrelated to a testimonial, are essential to make the testimonial meaningful. They don’t contribute to the content per se but they determine where and how the testimonial should be displayed. 

For example, the page field determines which page this testimonial should go on. The priority field tells us which testimonial to show first in a list.

So, here’s the key takeaway: 

“A model doesn't have to include only the information visible to the end user; it can also contain fields that control how the content is displayed.”

The testimonial example might be too basic for understanding the CMS model. How about we talk about an entire page? Heck, let’s just talk about the Arbisoft’s Home Page.

The Arbisoft home page previously had a very crude implementation. And this whole idea leads us to our second key concept which is “Encapsulated Models”. Let’s go over this in detail by looking at Arbisoft’s previous homepage model.

You can see in the above image that each section on the page is defined by its own unique model in the CMS. 

This isn’t really a scalable approach. 

Why? 

Because we were creating hundreds of models that were not strictly reusable. 

Each page can be different from others and by creating models for each section, we can end up with hundreds of models with only a single entry for each of them like we did at the time.

On taking a closer look, you can see our testimonial model linked to this model. The link has a field name of “clientTestimonials”. 

And that’s the “Relation”-ship you could see everywhere. 

You could co-relate models at your own ease and continue building complex models. After all, a page is just another model in the CMS.

Encapsulated Models

We saw how we created a lot of models that didn’t have to contain more than one corresponding entry because they represented only one section on a particular page. 

Any developer can see this mistake easily but, funny enough, they still continue making this mistake. 

To overcome this, their best bet is to give the model a name that is “reusable”. 

Let’s, for example, take the “Card” model on the home page. 

Now this isn’t a good approach to naming the models and re-using them. Here’s why:

This is a screenshot of the Card model entries. 

There are more than 200 “Cards” in the CMS being used everywhere on the website. 

If you try to “reuse” this model and add it to a page, you will have to scroll through these 200 entries or search for your card in order to add it to the page. 

Not very friendly. 

And this brings us to our third key point: 

“Does Headless even mean anything to you, brother?”

Headless in HCMS

The word headless has great significance here. 

It's not just a razzle-dazzle word added to sell more CMS. 

The headless part specifically means that this particular CMS is totally unrelated to the Design and Development of your website, a blog or anything user-facing. 

This means our CMS is best maintained in a way that doesn’t represent the UI but rather represents the content in a fashion that is understandable and usable for the content management teams.

And, as we saw earlier, the Card model is a mistake or rather a blunder. 

The word ‘Card’ doesn’t have any content significance. It’s a UI term. 

Also, how do you even define what a card is? 

It should have a title, some text content, an image, and a button (optional).

Right? Right. 

Ok, then what does a Banner have? Isn’t a banner and a card the same in terms of their content? 

Absolutely. 

Their only difference is in the way they are designed for the end user. 

A headless CMS should not be concerned with a Card or a Banner. 

This takes us to the newer implementation of the Home page:

Now, the dynamic zone is an advanced concept. So, we will only focus on what's important to us.

The blocks that you can see in the screenshot, i.e., Value, Testimonials, etc, are components.

These components are lightweight models that only exist for this page. 

Yes, they do represent different sections, but they don’t require creating additional models for each section. All of this is encapsulated inside the Page model.

(On a side note, the dynamic zone gives us a great feature of changing the position of these sections which we didn’t have in the previous relational approach. We can change the section orders in the CMS, and it will change the sections on our home page.)

One Last Example to Wrap it Up

One last example that I want to show you to build upon the encapsulated models is this particular model shown above. 

You can see a lot of stuff going on here. 

You'll notice a dynamic zone along with several basic CMS fields. This makes it a complex model, more intricate than a single page. Because it not only holds content to build a page but also encapsulates all the information related to this content. 

Now, you might be thinking that we could simply take some stuff out of here and put in another model e.g. a card or we could be more sophisticated and build a new model named “Only this content’s Card”. 

But that's not the best approach.

Keeping everything within this single model helps manage the content in one place. Any front-end application can query data using a single scheme from this model. 

When we need just the title and intro, we consult this model to retrieve them. When we want to create an entire page, we can still turn to this same model to access the dynamic zone.

This approach works great because it streamlines content management and allows for efficient data retrieval. 

It keeps things simple for both content teams and developers, ensuring all related information is easily accessible without unnecessary fragmentation.

Conclusion

Headless CMSs give us a lot of features and we need to understand what works best for our use-case. Here are a few points to remember:

• Most of the time, having tiny models that represent UI elements is a bad approach. It can lead to a cluttered CMS which is hard to manage.
• If you need something that corresponds to a particular UI element, consult the documentation of your CMS. It will most likely have a built-in way to handle your use case. In the case of Strapi, for example, it’s the “Components.”
• Grouping related content works better than segregating it. Segregation will lead to either too generic models e.g. card, banner, etc., or less efficient models that would only have a couple of entries of data.

A headless CMS is all about flexibility and efficiency. 

By structuring your content wisely, you make life easier for both your developers and content teams. For tailored CMS solutions, our software consulting services can guide you through the process.

So, keep it simple, keep it organized, and let your CMS do the heavy lifting.