How I Learned to Expect More From My CMS

As an early adopter of database-driven web content management, I sometimes forget what it was like when the kinds of systems I now advocate for were new. So I made a little trip down memory lane to remember how daunting it was in the early days.

​​My first glimpse into the future was unimpressive. I had been tasked with evaluating some of the new “content management systems” (CMSes) on the market circa 2009 to see if our interactive agency could use them.

We had embraced Dreamweaver templates, but our clients wanted to be able to update their website content faster and more easily. Tools like Blogger and WordPress were being embraced for their no-code way of blogging, opening up the door to no-code ways of managing more types of web content.

After a web search of top CMS products, I installed a few on my computer and tried them out. Instead of seeing a place to slot in text and images on a web page, I was faced with a nearly blank screen and a link to “Add new content.” How did this relate to a website? How was this useful? I decided that a CMS wasn’t for us.

Not long after that, someone excitedly showed us a website they’d built with a CMS that used structured content. They showed how when you add a piece of information in one place in the CMS, it automatically shows up in multiple different places on a website. And with a taxonomy, elements on the web page come together dynamically. I was in awe.

The demo hooked me on the value of separating content from presentation. Suddenly, as a content manager, I could add content to a website without dealing with code or Dreamweaver templates.

To be clear, this was only a precursor to today’s headless CMS and a more modern composable content platform. It was still tied to a single website. However, it used many of the principles that eventually led to the broader adoption of a composable content platform, including the use of structured content, separation of content and presentation, and dynamic listing of content items.

As we enter the composable era, businesses need to think differently in order to keep up with heightened customer expectations for personalized, contextual experiences across channels, devices, and situations.

Content needs to be modular and programmable so that it's quick and easy to adapt to market changes, innovate, launch new things, and deliver more tailored experiences.

My early adoption of a structured content approach means I have high expectations for tools that create, manage, and publish content. You don’t have to be an early adopter to enjoy these benefits. In fact, if you are just starting to implement structured content, consider yourself lucky that today’s technology is built for that.

These features help me keep my content structured appropriately while making content management easier.

Content types are containers for storing content with a common structure and purpose. When considering the meaning and subject of the content itself, it becomes a resource—a digital stand-in for the thing itself—rather than a representation. For example, a product rather than a product landing page.

Content types are the heart of structured content. They are unique based on each context in which they are created. I’d much rather have a blank canvas to set up content types than have to hack what is already there based on a generic, preconceived notion of what types of content I’ll have.

Not only should I be able to specify each content type based on my content model, but I should be able to define the fields to meet the needs of my content strategy. Treating content as data is essential to be able to deliver personalized content to any channel or device from a single source of truth.

That means I should be able to create custom fields without limitations on hierarchy with programmable validations and functions. This might mean that I have to rely on a developer to create them for me, but I’m willing to give up short-term control for long-term effectiveness.

I want content to be connected. That means the content types need to be able to reference each other. This creates explicit relationships that computers can understand to mean “this instance of the thing I’m creating connects to that instance of another type of thing.”

For example, when creating an event session, I want to specify people as speakers. The event session and speakers are different content types. I can manage that information separately and connect them without re-creating the content.

This kind of connection comes with some content management complexity. So I also want my CMS to tell me when I’m about to break a connection by unpublishing or deleting a piece of content.

Sometimes content is a large, narrative chunk that seems like it can’t be divided into smaller chunks without losing the flow. Think about an the body of an article or blog post. We can't always anticipate how long the text will be or what assets or references we’ll want to include.

It is tempting to fall back to the comfort of a “what you see is what you get” (WYSIWYG) editor in this case. Since I don’t want to mess with any layout or visual design decisions, I’d rather have a rich text editor that allows me to chunk the content into blocks.

"Blocks" isn't just descriptive; it's now a technical term. A block is an individual front-end component that displays data. Blocks allow users to edit their content without needing to write code. Like physical blocks, digital blocks can be assembled over and over to form different things.

This is how we keep structure in our long-form content. While there is a standard set of blocks,  we can also create custom blocks. They provide a way for content creators to maintain consistency and flexibility. It takes away the need to know or remember how to add a call to action in the middle of an article while providing many options for future content creators to use.

Some of the standard blocks are Paragraph, Header, Image, Table, Video—things that are certain to be used by anyone at any time. Some typical custom blocks I create include call to action, related content, newsletter signup, and alert. Each of these has a set of fields to which I can add content. When I want to add one of these blocks, I just select it from a list.

While we often talk about the user experience of websites, apps, and products, we tend to give far less attention to the editorial experience of the CMS. Since content is the heart of that end-user experience, it is essential that the tool people use to create and manage content is set up to fit their unique needs.

Every organization’s content operations are a bit different. And I expect to be able to configure my CMS to fit our processes for creating and publishing content.

That means it should be easy to create and find content items. I need a good internal search and the ability to navigate to a particular content type and its instances.

Content types are often ordered alphabetically by default. But what if the content we most often create or review is Testimonials, which would be near the end of that list? I’d love to be able to determine the order of content types in the initial listing. Groupings and list order are important aspects of usability.

Any content technology likely has dozens or even hundreds of users who should not be treated equally. I want to be able to create custom user roles to control settings and permission to access, edit, and publish content as granularly as possible—at least at the content type level, but preferably down to the field level.

I also want to set workflow rules by content type. Some content types require a lot of approvals, but others can be actioned right away. Take a press release as an example. It may need to get sign-off from top executives and then be published instantly by a content manager. On the other hand, a conference manager should be able to add conference speakers as soon as they're confirmed—no additional approvals needed.

For the press release, I may also need to reliably schedule it to go live at midnight Pacific Time, so that I don’t have to wake up in the middle of the night.

The bottom line is that I want the platform where my team works to work for them. This can only happen if I have the flexibility to change any aspect of the interface to suit our needs.

Thanks to all cloud-based software, we've come to expect that multiple people can work in a single document simultaneously. If I want to make an update to a piece of content right now, and so does my colleague, neither of us should be locked out of the document or lose our changes because we hit save after the other person.

But not every CMS offers the same level real-time collaboration. For me, this is a non-negotiable feature that allows teams to collaborate quickly and seamlessly.

Images are an important content asset. But there are so many places the same image might appear that a single aspect ratio or resolution doesn’t work. At the same time, I don’t want to have to create several different graphics to accommodate all the ratio sizes.

What I really want is to upload one image asset and have it adjust in size and resolution based on how it needs to look.

Despite my love for structure behind the scenes, I still want to know what any content component is going to look like when delivered to a particular place. And when the content and design are separate, it can be hard to trust that things will look right in so many places.

That is why I want live previews of my content—in all the places that content would show up. I don’t want to publish an update and wait upwards of 30 minutes to make sure it still looks right. In fact, I don’t necessarily want to publish that content at all. I just want to see what it looks like as I create or update the content and have confidence that it will look good before publishing. Not only does this give me peace of mind, but it opens up doors to synchronous collaboration with business stakeholders, designers, and developers.

This desire isn’t limited to getting previews of a single webpage. It also includes social media, search engine results pages, and any other place where the content will get displayed.

Just as writing has begun incorporating artificial intelligence (AI) assistants, we can expect AI to evolve to support content management. Being able to automatically perform governance tasks—like auditing, updating, and archiving—becomes much easier when the content is broken into its smallest reasonable components. Using a composable platform that integrates or can incorporate new AI tools will be essential in the near future.

We’ve lived with subpar content management systems for too long. It’s time to expect more from the technology we use. It’s time to stop compromising our content needs. When we leave the routine work to computers, we gain precious time to be creative in ways only humans can be.