How to choose the right CMS for your content model

How to choose the right CMS for your content model #

When having to choose a content management system for your company, there are several criteria to consider to make a successful and sustainable decision.  

In this article the 23 criteria on how to choose a fitting CMS to best support your content model from within the book "Real world content modeling" by Deane Barker are evaluated. This should be a step-by-step guideline on how to assess these criteria, including the key take-aways of the book.

Criteria #1 - What is the built-in content model?

The built-in model is the internal structure that a CMS (Content Management System) enforces for storing content. The editorial interface often reflects this model, making it essential to visualize when considering a CMS. Attributes like Title and Body are common in content models and understanding them is crucial for customization. While the built-in model may not fulfill all requirements, knowing it is essential for determining how to extend or modify it to meet specific needs.

Criteria #2 - Can the built-in model be extended with custom content types?

The critical evaluation criterion revolves around the CMS's capability to extend its built-in content model for custom content types. Some systems are designed for easy extension, while others may limit or outright deny this capability. The distinction between content and metadata, once significant, is less relevant in modern CMSs, which generally structure all data uniformly. The question of whether traditional metadata exists in the classic sense is raised, emphasizing that modern CMSs typically do not follow the content/metadata dichotomy. If a CMS lacks the ability to extend its built-in model, careful consideration is necessary, as such situations are uncommon and often specific to certain use cases or industry verticals. So, before making a CMS choice, assesssing the extensibility of the content model is crucial. 

Criteria #3 - What built-in attribute types are available?

Content types are crucial in a CMS and consist of unique attribute combinations. The ability to extend the content model for new types relies on understanding available attribute types, the building blocks for creating the model. Attributes, representing raw data, have names and types governing behavior. CMSs offer a variety of attribute types such as text fields, numeric values, dates, checkboxes, and more. The quantity and applicability of attribute types significantly impact a CMS's success in representing content accurately. Customizations for attribute types, like name, label, and settings, are common, ensuring a tailored editorial experience. Understanding the order of attributes, their universal settings, and the serialization code is essential for an effective content model. Attribute types play a vital role in maintaining a valid and resilient content model, defining rules for interactions between editors and the model. 

Criteria #4 - How is content represented in the API?

Imagine you're watching TV – you press a button, and it just works. You don't need to know the technical details; it's the interface that matters. Similarly, in programming, something called Object-Oriented Programming (OOP) is used. It's like having a TV remote – you interact with objects without worrying about the internal workings. 

In content management, a content type is like a class, a content object is an object, and an attribute is a property. Now, strong typing is the key. It ensures a smooth translation of content into code, making developers' lives easier. Some systems opt for weak typing, causing a bit more work for developers. Attributes can also be strongly typed, providing a true representation of data. This simplifies things for developers working with the data. Adding logic to your content objects can be handy. For instance, printing headers in a guide. You can make logic-driven pseudo-attributes, keeping your code clean and centralized. 

In a nutshell, a strongly-typed API lets you perform cool operations in your code. It's not just about your content model; it's about maintaining clean and efficient code, making your integration efforts a breeze. 

Criteria #5 - How can attribute values be validated?

Attribute types are your trusty sidekick, ensuring editors enter valid values. Think of it like preventing someone from typing "War and Peace" in a map field – we've got to keep it on track! 

Value coercion is the superhero move here, but sometimes we need backup. That's where validation rules come in. They're the tests ensuring proposed values make logical sense, made to keep things in order. 

Starting simple, required attributes are like the basics. If an Article needs a Date Published, we make sure it's there before hitting publish. It's like requiring a TV remote to have batteries – you can't change the channel without power. 

But wait, what if there's more to it? Logical validation rules are here for that. Is that number really a release year? We're not just checking if there's a number; we want the right kind. Enter regular expressions, the detectives of pattern matching. 

Timing is everything – validation rules kick in when you save content. We want to catch errors early on, right? And if you need a preview before publishing, no worries. Some systems delay validation until the final step, giving editors more flexibility during the creative process. 

Defaults to the rescue! We can set default values for attributes, making life easier for editors. It's like having your favorite snack always stocked in the pantry – a pleasant surprise! 

But what happens when rules overlap? Who takes charge? We discuss rule precedence and conflicts. It's like deciding if the TV volume rule beats the channel-changing rule when your favorite show is on. 

Custom validation might be your secret weapon. When the system's rules aren't enough, you can create your own. It's like adding a personal touch to your content model. 

Enforcing attribute validation is the key to a resilient content model. It prevents confusion down the publishing pipeline and helps editors discover the system better. 

Criteria #6- How is the model supported in the editorial interface?

Picture this: no need for custom interfaces. Your CMS does the heavy lifting, creating a user-friendly space for editors. It's all thanks to your well-defined content model – the backbone of the operation. 

Now, labels are the heroes in this story. Clear names and explanations guide editors through the interface. No more head-scratching over cryptic fields – it's all about usability. 

Talking elements – your interface adjusts based on attribute types. Whether it's a text editor, date picker, or dropdown menu, it's tailored for smooth editing. No more guesswork for your editors! 

Organization is key, too. Arrange attributes logically, group them sensibly, and watch your interface shine. Error messages? Crystal clear. Validation issues won't be hiding in the shadows – your editors will know exactly what's up. And the power move? Suppressing elements. Hide or lock attributes when needed. It's all about control without sacrificing functionality. 

Now, let's talk findability. Your system supports easy content discovery. Editors can search, filter, and navigate content hassle-free. Icons? They're the secret sauce for visual cues – a game-changer for usability. 

So, why does editorial usability matter? It's not just about preventing errors; it's about making the editor's journey enjoyable. Confusion leads to mistakes – and we're here to avoid that. Your content model isn't just about structure; it's about creating a smooth, stress-free editing experience. 

Criteria #7 - Can an attribute value be a reference to another object?

In content modeling, referential integrity plays a crucial role in establishing relationships between objects. Unlike discrete content modeling, which keeps objects self-contained, relational content modeling involves linking objects. Referential attributes, holding references to other objects, streamline information, enhance efficiency, and create a network of connections. However, maintaining referential integrity is vital, as deleting a linked object can lead to issues. Systems typically offer options like preventing deletion with inbound references or providing tools for editors to manage links. 

Considerations include the unidirectional or bidirectional nature of references, with challenges in finding inbound links. The user interface for managing referential attributes is essential, involving dropdowns, two-pane interfaces, browsing, or searching. Permissions and type limitations ensure that editors can only link relevant objects. Additionally, referential attributes enable composite modeling, assembling objects with minimal content into larger structures. While powerful, caution is advised when extending object content beyond its original boundaries to avoid unintended consequences. 

Criteria #8 - Can an attribute value be an embedded content object?

The concept of embedded content objects as attribute values is explored, offering a fully-contained approach within an attribute. Unlike referential attributes, embedded objects cannot exist independently and are accessible only within their owning object's context. This enhances editorial usability and allows for custom rules in both the owning type and the embedded object. Typed attributes, like embedded objects, provide flexibility by serving as standalone objects in the repository and attribute values, contributing to a comprehensive content type description. 

Criteria #9 - Can custom validation rules be built?

Custom validation is vital in a Content Management System (CMS) for tailoring validation beyond built-in assumptions. It often involves server-side coding and is less common on the client side due to external system interactions. It becomes necessary when unique criteria require validation, such as checking product numbers against a live catalog. Custom validation is crucial for enforcing specific rules, ensuring content resiliency. However, in some cases, a complete rewrite of the attribute's interface and data storage may be needed, requiring fully custom attributes. 

Criteria #10 - Can custom attribute types be created?

Custom attribute types in a CMS fill gaps for unique needs like displaying elements, specific validation, and interfacing with external systems. For instance, complex cases, such as RGB color selection, require custom code for the editorial element, validation, value type, serialization, and search indexing. Well-designed systems offer extensible frameworks for API support, allowing custom attribute types to inherit from built-in types and ensuring flexibility across content types in the CMS. 

Criteria #11 - Can attribute values repeat?

Repeating attribute values, allowing an attribute to hold multiple distinct values, enhance the editorial experience in a "one to many" relationship context. While not universally supported due to data model complications, early implementation proves beneficial. Ideal systems enable repeating entire attribute sets, offer validation for characteristics like uniqueness and quantity, and support ordering for correct value sequence. Despite its utility, this feature is not always prevalent and may be limited in some systems. 

Criteria #12 - Can types be formed through inheritance or composition?

Type inheritance and composition are crucial for managing complex content models in a CMS. Inheritance allows types to inherit attributes from a parent type, centralizing common attributes. However, it has limitations like difficulties with multiple inheritance paths. Type composition, on the other hand, involves composing types from pre-defined attribute sets, offering more flexibility. Both methods expand type boundaries, requiring careful monitoring of dependencies, abstract types, and potential circular references. While inheritance is beneficial, composition is often the more practical and useful tool in content modeling. 

Criteria #13 - Can content objects be organized into a hierarchy?

Another form of object relationships is a so called parent-child relationship in the form of an overarching content tree. The content tree is a hierarchical structure used to organize content in a CMS. 

In the content tree, each piece of content is represented as an "object" with its own set of attributes. Objects are arranged in a hierarchical tree structure, with parent-child relationships between objects. Each parent might have multiple child objects which each might again have multiple child objects and so on down the tree. A common example for a parent-child relationship would be a book that has multiple chapters. 

Often times, CMSs that use this kind of structure not only do so for the content modelling, but also for functionality. For example, a child object will usually inherit its parent’s permissions and continue it’s ancestral URL paths. Depending on the situation, a change in a single parent object might therefore cause changes for all connecting child items. This should also be considered when choosing a CMS. 

Content trees can be used to model complex content structures and are especially useful for websites with a deep hierarchy of content. A well-designed content tree can help to manage complex content and ensure consistency across a website. 

Criteria #14 – Can content objects inherit from other content objects?

Object Inheritance is a concept in content modeling where attributes and behavior can be inherited from one object to another. It allows for a more efficient and consistent modeling of content by avoiding redundancy and ensuring consistency across related objects.  

In content modeling, inheritance can be used to create a hierarchy of objects with different levels of specificity, from general to specific. For example, a general object like "Article" can have specific sub-objects like "News Article" or "Blog Post" that inherit its attributes and behavior. Inheritance can be implemented in different ways, such as through a parent-child relationship between objects or through the use of interfaces and mixins. 

It's important to consider the trade-offs of using inheritance in content modeling, as it can add complexity to the model and make it more difficult to manage and understand. For example, a challenge might be found in the requirements that a base object provides to the derived object (e.g. the base object requires a subtitle but you don’t want to use one for the derived object).  

Object inheritance can be especially fitting when content is deeply customized for specific delivery requirements, or when large amounts of similar content need a set of default values that can be updated in real-time. 

Criteria #15 – What is the relationship between “pages” and “content”?

The Page Model is a common approach to content modeling that treats content as a set of individual pages. In the Page Model, each page is a self-contained unit of content with its own set of attributes and behavior. Pages can be organized in a hierarchical tree structure, with parent-child relationships between pages.  

In some CMSs, pages and content are separate constructs. In those systems, pages are specifically designed to represent web pages with page-specific information like meta tags and title tags. Content objects are assigned to pages, which act as containers for the content. In systems where content objects are also pages, every content object is assigned to a dedicated URL and is directly addressable as a page. It's beneficial for a CMS to allow for both pure content that is never directly accessed and content that is represented in a page construct. This provides flexibility and efficiency in managing content, depending on the specific needs of the website or application. 

This Model is simple and easy to understand, making it a popular choice for content modeling. However, the Page Model can be limited in its ability to handle complex content structures and can lead to duplication of effort if the same content needs to be displayed on multiple pages. 

Some CMSs use a hybrid approach, allowing both the Page Model and other models like the Object Tree to be used depending on the specific needs of the content. 

Criteria #16 – Can access to types and attributes be limited by user permissions?

Model permissions refer to how permissions are assigned to different roles and users in a content management system. Permissions determine what actions a user can perform on content, such as creating, reading, updating, or deleting it. Permissions can be assigned to individual content objects or to groups of objects, and can be inherited through a hierarchy of objects. 

Some systems use an "Allow/Deny" model for permissions, where users are given specific permissions on a per-object basis, while others use a "Role-Based Access Control" (RBAC) model, where users are assigned to roles and roles are granted permissions. In some cases, permissions are also used to control access to specific features or areas of the CMS, such as the ability to create new content types or install extensions. 

There should be a balance between flexibility and complexity when designing a permissions model. Too many permissions can make the system difficult to manage, while too few may not provide enough control. It is recommended to use a role-based model with a limited set of roles and permissions that can be easily understood and managed. 

Criteria #17 – How can rich text fields be structured?

Rich text refers to text content that includes formatting, such as bold, italics, headings, and bulleted lists. It can also include embedded media like images and videos. It is commonly used in content management systems to allow for more expressive and visually appealing content. 

In a CMS, rich text is typically stored in a special format that can be edited and displayed within the CMS interface. There are several ways to represent rich text in a CMS: 

• WYSIWYG (What You See Is What You Get) editors: These allow users to format text and see the results in real time. 
• Text with markup: Users can enter text with special characters or tags that represent formatting, such as Markdown or HTML. 
• Visual editors: These allow users to drag and drop elements onto a page, such as text boxes and images. 

It’s important to consider the needs of content authors and the capabilities of the CMS. Rich text can add complexity to a content model and may require additional fields or properties to represent different aspects of the text, such as formatting, links, and media. 

Criteria #18 – What options are available for dynamic page composition?

Page composition refers to the process of combining different types of content to create a single page or view in a content management system. In a CMS, page composition is often achieved through a process of assembling content from various sources and presenting it in a structured way. Page composition can involve a variety of content types, such as text, images, multimedia, and custom components. There are several approaches to page composition in a CMS: 

• Component-based: Pages are built from reusable components that can be mixed and matched to create different layouts. 
• Template-based: Pages are created using predefined templates that define the overall structure and layout. 
• Block-based: Pages are built by arranging individual blocks of content in a flexible layout. 

Here, the flexibility and reusability of content, as well as the needs of content authors and site visitors should be considered. Considerations for page composition in a content model include the types of content that will be used, the ways in which content will be combined, and the constraints or rules for composition. 

Criteria #19 – Aggregation Structures

Content aggregation describes the grouping and combination of content. There are several ways on how to establish relationships between content. For each content model, a different way might be the best solution. 

You can either use internal or external structure. The first would be the case if a referential attribute or parent-child relationship is used because the information is included in one of the content objects. Example: a webpage links to another webpage. On the other hand, using external relationships does not integrate the information in the content objects, but somewhere outside of them. Example: several webpages are saved in the bookmarks folder in the browser.  

The usage of categories and taxonomies is another possibility. Categories are a hierarchical structure (often in a tree) and are created by the editors and assigned to the content later. There can be several child categories. Even tough categories and tags seem similar, the usage can be different, but they should not be used at the same time – it should be either or. Since tags can also be added by the writers, using categories is the more systematic approach.  

Additional external structures are menus, lists or collections.  

Criteria #20 – Change of content type after creation

When acquiring a CMS, you should consider, whether the following changes are needed in your organization and if the CMS supports it. 

While adding new attributes should be unproblematic, renaming an existing attribute can require a change in settings or template code. Splitting attributes needs to be accompanied by developers. Changing attribute types is mostly not possible. Deleting one can result in data loss. What can be an issue in regard to these conversions is the metadata.  

Useful CMS functionalities for those scenarios are tests or backups before applying those changes and validation rules for making changes effective. 

Criteria #21 – How the system handles file assets

Not all content that is to be stored it going to be text-based. File assets like PDFs, images, videos etc. are usually also needed. First, it is to be evaluated if the assets are modelled as content at all – meaning do they get workflows, versions or is additional information stored. In some older systems, this is not possible. 

Another option is the use of “detached assets” or “attached assets”. Some systems let you upload files as part of a specific detail (attached), limiting reuse. Others allow files to be used by many details (detached). Files can be important for supporting other content, needing a special web address for access. They might change based on how they're used, like resizing images or picking specific pages from PDFs. 

Understanding how a CMS manages files is crucial. Some systems are good for managing many files, like those used in media or stock photo websites. Others work better for documents and text. In short, choose a CMS that handles your files well, making it easy to manage and use different types of content on your website. 

Criteria #22 – How the content model is defined – by code or by UI

When choosing a CMS, it's crucial to understand how the content model, defining types and attributes, is created. There are two main approaches: UI-based and code-based. 

UI-based Model Definition: This approach Allows non-developers to shape the model, but can lead to mistakes without proper data modelling experience. Changes in the model might require coordination with developers for other code or templating adjustments. UI-based systems may require manual duplication of changes between environments or offer model import/export options. UI-based systems often require manual export from the source environment and import in the target environment, potentially leading to challenges if types differ. 

Code-based Model Definition: With this approach, content and attribute types are defined in code or structured markup files. Code-first systems offer advantages in version control, deployment synchronization with code changes, and ease of environment synchronization during development. It requires developers for model creation and changes, but it offers better security and stability. For maintenance and deployment of programming code (=development operations) Code-first systems benefit from versioned models and streamlined deployment alongside other code changes. Code-first systems can synchronize changes seamlessly during code deployment. 

As there are pros and cons to both approaches, you need to weigh flexibility versus manageability, since the choice determines if there is need for developers or if editors can maintain it themselves. 

Criteria #23 – What can you do in the system’s API

When a CMS's content features fall short, its API can help with the following tools/actions. Look at how well the system supports coding to decide what works best for you. 

Event-Based Programming: CMSs have events like content creation or deletion. You can use code ("hooks") to do things before or after these events. 

Webhooks: Systems can tell other systems about events using webhooks. 

Event Programming and Versioning: Some systems let you change content without making lots of new versions. 

Supplemental Indexing: Make special indexes outside the CMS for better searchability. 

Repository Abstraction: Get content from outside the CMS in real-time when needed. 

Content Synchronization: Copy content from outside into the CMS at scheduled times. 

Content Model Reflection: Use code to see how the content is structured for documentation. 

Recursive Content Models: Some systems let the model be part of the content. 

Resumé

Choosing the right CMS depends on many different factors as you’ve read in this article. You should weigh up the different criteria against each other prioritize the ones especially relevant for your specific use case. There is no "one fits all". It’s also about making compromises and finding the system that can fulfil the main purpose you are planning to use it for best. 

Where to go from here #

References #

Barker, D. (2019). Real World Content Modeling: A Field Guide to CMS Features and Architecture. Independently published. 
https://deanebarker.net/books/real-world-content-modeling/