Now that we've covered Content Modeling in Part 1 of "Structuring your Headless CMS", we are going to put said content models into action! Today, in Part 2 of the series, we are going to take a look at structuring the Content Tree. How can we create a Headless CMS hierarchy that's both logical and easy to use for both Content Editors and API sources? How can we separate content from page-layout & navigation? And how can content modeling benefit from content structures beyond the boundaries of a website? Find out today!
CMS Hierarchy
In the world of Headless CMS's, there are dozens of options to choose from. For returning readers it won't be a surprise that the examples used in this article are based on the Umbraco CMS. But not just any version of Umbraco but in particular the Headless SaaS offering from Umbraco themselves, Umbraco Heartcore! The examples explained in this article aren't exclusive to this particular CMS, but a different CMS may have implications on the various implementation options that CMS offers.
As mentioned in the introduction, the goal for this article is to explain how and why to define your content structures & hierarchies. To define such a structure, we'll have to set a couple of rules to adhere to. Opinions may vary, but personally I would consider the following five requirements to be the primary boundaries to adhere to when setting up our content structure:
- Ease-of-use. Creating a friendly user-experience for content editors for both creating, editing & deleting content, as for navigation through the CMS itself.
- Reusability. Separating content as much as possible to allow reusability on multiple platforms.
- Independent. Separating your content from any form of presentation, and making it independent of any context or structure.
- Scalability. Being able to scale your hierarchy no matter how many platforms, collections, content or pages you may have, both now and in the future.
- Security. Being able to protect content on various levels, on both an API and content editor level via various permissions.
To achieve these five requirements, I've come up with a CMS structure that separates the Document Tree into various groups. From a Root level, we are starting with two folders, one for "Content", and one or more for "Platforms".
Content Structuring
What is Content? And maybe more importantly, what is content not? If we look at the Cambridge Dictionary, Content is defined as: "Content (/ˈkɑn·tent/), noun, the subject or ideas contained in something written, said, created, or represented", which gives us a broad idea of what we're working with. The highlight of that sentence for me are the words 'in something', where I would read the sentence as; Content is what you write within whatever you are trying to represent. We want to structure our content to be a unique set of parts to be enclosed to a different location before it is presented, and therefor have our content be totally separated from any form of visual representation.
One of the ways we can achieve this, is through various collections of items. Items that only contain whatever content they are trying to discuss, that are tagged based on their subject, and only contain the necessary information to spread the message it's trying to bring across to the user. So what could such a CMS structure look? Let's take a look!
Attachment 1. Example of a Content Structure in a Tree Based Content Management System
A very simplified example of a Content Structure could be one as shown above. Starting with a Content collection on a root level, and the level below being various kinds of collections separated by their content type. You could go as far as separating various 'types' of collections too, whether said content is meant to be used 'stand-alone' or if it is used as sub-parts of a content model, like Authors or Tags commonly are.
Within each collection you have the option to create various sub-folders for further structuring and organizing depending on the content type, but for a News collection the separation for Global and National news could be an example use-case! After that, we end up at the lowest level content-type being the final contents, like a News Article. This article contains the actual fields containing the content for the article, like a Title, Rich-Text field, Media, a reference to an Author, and various Tags as the descriptors for the article. Do note that the contents specifically don't mention anything to present anything involving representation, e.g. SEO titles & descriptions, page lay-outs, navigation structures, etc! Where do those belong? The answer to that would be underneath the various Platforms!
Platform Structuring
What is a platform? For the scope of our Content Management System I would define a platform as "Any third-party channel that requires a form of customization and/or utilizes one or more sources of Content". Where traditionally a CMS would exclusively be used for one or more websites, because of the headless nature of our setup we can target a broader set of platforms, including but not limited to:
- Websites
- Mobile Apps
- Email Campaigns
- IoT Devices
- Chatbots
- AI Learning Models
To separate our content from our platforms, we will be working with a different setup of collections defining the structure & meta-information of our platform. The goal for our structure will be to determine the various page structures and how they relate to each other, to control shared-elements like navigation elements, and to manage page-specific information like meta tags & SEO information. Let's take a look at an example:
Attachment 2. Example of a Platform Structure in a Tree Based Content Management System
In this example we can see that we have separated our collections of platform types on a Root level, separating the various websites from mobile apps, campaigns, et cetera! Within each collection we create the start of each unique platform itself, like a primary website and multiple campaign sites. With each each site, we have two paths: The Homepage node, and the Settings node.
- The Homepage node is the root of our website URL structure, usually being the '/' path of our website that a front-end framework like VueJS or React would access first, and use to build up the various other URLs. Each subsequent item underneath the Homepage root is a unique page that's accessible via it's URL corresponding to it's location in the tree.
- The Settings node is a separate part of our platform and can be used to store additional configuration that is not part of a website/page structure, or not part of any particular page. A common use-case would be to store a configuration for your header and footer navigation underneath this location. This location choice is a matter of preference, as some would prefer to have it be part of the Root for the platform itself. Personally I think this route makes it more scalable for the future!
When working with subsequent pages underneath our Homepage example, we have to take into account the separation of page-information and content. For every field that you wish to add to your page, think "Does this field describe something specifically for this page, or does it say something about the content on the page?". If its the latter of the two, the field should be part of an item underneath the Content tree. Depending on the type of page, we can determine what it should store! If it's any old 'content page', you would for example have a page with a page title, meta title, meta description, and a reference to a Rich Text Content Item which is stored underneath Content. Further information about Content Modeling can be found on Part 1 of the series.
If you would create a 'News Overview' page, the page could have the same meta-information as a content page, but also have a reference to one or more articles to display underneath the overview, which using a CMS like Umbraco Heartcore, could automatically expand to contain all the details of the content. If you would like to make the overview even more dynamic, instead of referencing articles directly you could reference the Tags collection instead, and have the Front-end automatically fetch the articles from the Content Collection based on a dynamic set of tags & filters.
The result of creating a seperated CMS using the examples given above, is a clean CMS that separates the structures of the various platforms and the actual content displayed on the platforms, making each and every content item reusable, interchangeable and scalable.
Summary
The foundation of a Headless CMS lays in its structures & hierarchies. To ensure the ease-of-use, reusability, and scalability of both your content & platforms, it is important to think these choices through ahead of time before creating your content. By separating your content you ensure that your information is reusable no matter what platform, structure or style it is displayed in. Combine that with a separate structure for managing your various platforms, and you maintain full control over more than just your websites, without losing any of the benefits of using a Headless CMS. 🔥
If you have missed Part 1 of this multi-part series where we discuss Content Modeling, what it is and how you can benefit from it, click on the following link! 🚀
If you have any further questions, feel free to contact me over at my socials available at the Contact page, and I'd love to hear about either your success stories, or further troubles to help improve this blog! 😄
