Why you think your CMS is bad — and why it might not be.
A brief history of getting content onto the web and why that matters for effective content management system design and implementation.
“I can’t do what I want in my CMS. This CMS sucks!”
You’re either the individual on the marketing or content team saying this, or the vendor or developer on the receiving end of this feedback.
One time a business came to me looking for a new CMS because they determined their current one was terrible. Why? It wouldn’t allow them to change the colour of their page heading. That ask put me into a bit of a spot, because I had to decide if it was worth explaining to this very frustrated team that their CMS might actually be good, if I could even pull off that explanation at all. Knowing they weren’t in the mood to find out why they might be wrong, I simplified things down to “we’ll take a look, and see if the CMS implementation could be improved first.”
Now that I’ve got a little time here to think, I’ll attempt the full explanation:
No matter how good or how bad your CMS is, when it comes to allowing you to enter the types of content you want or produce the types of layouts you want, every CMS is going to fail you at some point. It’s inevitable, and that’s because it always boils down to the exact same issue: presentation flexibility vs. content structure. And to explain what I mean, we’re going to travel back in time.
1998.
The web was not very sophisticated in 1998. Getting content on to the web meant using tools like Microsoft Publisher or Dreamweaver, or if you were comfortable with coding, you could write your own HTML directly (which is what tools like Dreamweaver converted your content and layout to under the hood). However you made your HTML files, you would upload the produced files to a web server and voila, you had a website. You couldn’t criticize your CMS because you had no CMS at all. Content is instead entered directly into the website’s presentation, wherever it needed to be, giving you complete presentational flexibility. Whenever you want to change your content’s presentation and layout you just could, in any way possible (limited visual abilities of the web in 1998 aside). Add a data table in between paragraphs? Sure. Change the left rail of your page to green? Go for it. Make your page heading bold? Easy.
But this presentational flexibility comes at the cost of content structure. Your has no content structure at all. If you create a page describing a product you’re selling, your product’s title isn’t defined as a product title in any kind of managed system where you enter it once and it appears across your site wherever it needs to. Your product title is your product title because you formatted some text at the top your page to be bold. If you create a second product, you will have to maintain that same styling to keep your content consistently structured. And it will be up to you to make sure you enter that same product title wherever it should appear on your website.
All your content is tightly coupled to the presentation you give it and doesn’t exist outside of it. This does allow a content author complete control over the look of their content but it also requires they consistently govern the layout of an entire website, page by page, green rail by green rail. It’s onerous, prone to introducing mistakes and failing to detect them, hard to scale, difficult to maintain, and if you want to make the presentation look like it wasn’t made in 1998, you need to know your code.
But back then, this was the only way to bring content to the web.
2008.
The web and the technology powering it evolved. Also TV dramas were getting really good.
The CSS specification was adopted and broadly supported by web browsers in the early 2000s. Standing for Cascading Stylesheets, this allowed HTML, the code that embedded both content and styles, to have styles applied to them separately, granting the technical ability to separate presentation from content. Geriatric millennials like me cut their teeth on this concept with CSS Zen Garden, a website showcasing how the exact same content could be presented in myriad ways by applying different styles by swapping out a CSS file.
Another huge innovation was server side scripts could run on a web server in programming languages like PHP to dynamically output HTML. No longer did you have to upload static HTML files to make your site, instead software was engineered that replaced those HTML files with logic that would read and write any content you create to and from a database and that would generate the pages of your site on the fly. The Content Management System was born. Now instead of your content being locked directly into HTML code, it was stored as plain language in individual fields in a database.
Having content stored as structured fields unlocks a ton of convenience and power, and allows users to ditch knowing code or the need to touch every facet of the layout in order to manage their content. It’s why almost all marketing teams require content management systems today for their web presence. But it also means that if you want to create new content for a web page that there isn’t an applicable field for in the CMS, your hands might be tied and you might start to hate your CMS. That’s the trade off — presentation flexibility vs. content structure.
Let’s work through an example of building a recipe detail web page to demonstrate the trade off of presentation flexibility vs. content structure.
The 1998/hard-coded way allows a content author (skilled in something like Dreamweaver) or a full-fledged coder the ability to make a table, put in all the recipe ingredients, along with their measurements. Maybe the measurements are italicized to visually separate it from the ingredient itself. You’d have to painstakingly italicize each measurement for each ingredient, but you could do it. And of course if you ever wanted to change that look, you’d have to go back to each recipe page and manually remove the italicization on each and every ingredient’s measurement. Oof.
In 2008, a content author (using a CMS powered website tailored to the type of content they need to put on the web) would enter in each ingredient into an ingredients field in the CMS, along with their corresponding measurement in a measurements field (and the measurements field could be made real slick to reduce content entry and prompt the author for a number only while providing a drop down between common measurements like tablespoon, cup, etc.). The page would then be automatically generated (from the layout the developers have implemented). All measurements would be italicized automatically because that theming is baked in to the page by a developer, though a developer now has the flexibility to change them to be unitalicized, across the entire site, with a quick CSS change. And because the content isn’t tied to presentation, you can do amazing things, like maybe the developers added a toggle on the page to allow a visitor to switch between metric and imperial measurements. Multiple recipes could roll up into a single index page automatically from the fields you’ve ever entered. This level of functionality and reusability isn’t possible without structured content.
Now, say you want the layout to allow for your ingredients list to be split into two sections, one for the main dish, and the remaining ingredients for the sauce. With the full presentational control of a 1998 style hard-coded approach, a content author (again, very comfortable manipulating HTML files directly, and having to do this manually on each and every page it’s required) could quickly split the table in two, adding a label of “sauce” between the two tables for a particular recipe and it’s done. In the structured content approach of a CMS, you’d have to develop a new feature to have multiple lists of ingredients, along with title fields for each list, supported by the CMS interface because the CMS fields aren’t currently allowing you to do that. You now hate your CMS and think it’s bad, despite the amazing power and scalability it’s giving you, because sometimes the lack of flexibility is an impediment.
2018.
Cloud services became ubiquitous to the point where the concept of “serverless” computing had taken shape for web developers, and out of this the Headless CMS was born. A complete decoupling of content from presentation — a Headless CMS captures content only, and makes zero assumptions about how it will be presented on the web, or if it will even be presented on the web at all.
The Headless CMS by default is nothing but structured content, with zero presentation flexibility. Because of this, it makes the ideal CMS to support multiple digital channels — content could be published from your Headless CMS to your website, but it could also be sent out to digital signage, to a mobile app, etc. And this is where presentation-agnostic content structure really shines. Imagine updating the results of a tournament. Updating the final match scores in your Headless CMS could update your website, the digital signage at the event and a mobile app all it once, and there’s zero risk the results will be formatted incorrectly anywhere because the CMS grants zero control on how the results are presented and will not impact it. Instead the presentation of the tournament results are baked into each medium by careful design and development. Of course if a content author ever wanted to change any aspect of the look of that results content in the website, they couldn’t. Zero presentation flexibility. Complete content structure.
Now because a Headless CMS is unopinionated on how content is structured, you can absolutely develop a content model that acts just like a traditional 2008 style CMS. A 2008 style CMS, with some extra work, can also have its content modelled to take presentational control out of the equation as well (this was the case in our recipe example earlier). So knowing this, every project that isn’t a hardcoded 1998 style website always requires planning how the CMS will structure content—and some project teams will work this out together, with designers, developers and the content team bashing out the approach, or the task of CMS design may fall solely on the developers if no one cares to think about it, but the choices have to be made.
Striking the right balance is difficult, and a well crafted CMS by a developer will likely blend flexible presentational control in content areas where presentation matters more than structure, and rigidly structured content where content needs logic, reuse and scalability to be most useful.
Let’s work through an example of building a web page of frequently asked questions to demonstrate the trade off of presentation flexibility vs. content structure.
A CMS crafted with presentational flexibility in mind may have lots of different components for authors to choose from, such as an accordion component. The accordion UI pattern on the web is a pretty common, you tap on the title and out opens more detailed content below. This component could be used to represent an FAQ on the web page — the accordion title field can be repurposed to be the question of the FAQ, and the accordion main content field can be the answer. With this component, you can now create an FAQ page by placing as many accordions as you have questions. But you could even use accordions on other pages, and not always for FAQs, but maybe other types of content where it may be a useful pattern. Through this approach content authors now have more layout control throughout the entire site. Lots of presentation flexibility for content authors, but little content structure.
But say you wanted FAQs sprinkled on various pages and have them automatically roll into one filterable central page that showed all FAQs on the website. The downside of an accordion component that allows layout flexibility is that it does not actually know if the content within it is an FAQ or something else. Maybe an accordion component was used on the website to tuck away a legal disclaimer, or to place a seasonal promotion. This means a developer cannot build a page that automatically pulls the content of all accordions across the site into a central page to surface FAQs, since nothing would ensure what shows on that page are FAQs. But in a CMS that crafted FAQs purely based on their content, and not as a presentation, intead of an accordion component we would have a content type that has fields explicitly for an FAQ question and its associated FAQ answer. The content model more accurately reflects the content, and now you can have pages that pull in all FAQs into a page dynamically. They might be shown as accordions, or in some other format, but this is now dependent on what’s been developed for the website and not what a content author chooses for presentation. Little presentation flexibility for content authors, but lots of content structure.
These are the trade offs of focusing on representing the content accurately, vs. representing the presentation, via the fields in the CMS. You might even determine you want both types of content entry. Accordion components and FAQ content types.
You can see why CMS design is complex.
Present day.
Phew, we made it back safely. And you might be surprised to learn that all three of those past approaches of bringing content to the web remain in frequent use today. And all three can be great approaches. Let’s review them:
Content hard-coded into presentation
- Full presentational flexibility… but really only for those confident with code
- No content reusability
- Difficult to scale
- Requires developers to build the site and manage all content
Content structured with presentation
- Some presentational flexibility
- Some content reusability
- Requires developers to build a CMS and iterate on it as needed, content authors can manage most content and have some layout control within pages without developers
Content structured agnostic of presentation
- No presentational flexibility
- Content fully reusable for any use case and multiple digital channels
- Easy to scale
- Requires developers to build CMS and iterate on it as needed, content authors can manage all content but have zero layout control without developers
My personal website is made entirely in the vintage 1998 style — I haven’t structured content into a CMS for use on a website, instead I hardcoded all the content and styles right into the page. A perfect solution for a lone web developer making a single page website, but completely untenable for a marketing team to manage a site at scale.
So for the rest of us, the challenge is crafting a content management system that invokes a balance of all three approaches where it might make sense: offering presentational control when that flexibility is important for authors, structuring content when reuse, scalability and ease of authoring is needed, and mixing in hardcoded elements for robust theming and visuals that authors don’t need to change. And deciding on that balance is why, at some point, you will hate your CMS. Because it can’t be flexible in all the ways you need it to be, while also structured in all the ways you need it to be at the same time.
But why? Why can’t we have the perfect balance? If the website requirements are clear and the developer team is proficient in designing and developing how your CMS is structured and used for your website, why can’t a CMS do everything we want?
- You can’t know everything you’ll want ahead of time. It can be a hard enough task just for a team to identify the most important needs to deliver for a digital experience. If your website is an e-commerce business, your requirement gathering focus should be on prioritizing what features your end users need for a smooth checkout, rather than thinking if you’ll anticipate the need for content authors to have tools to switch between Helvetica and Helvetica Nueue in their content authoring.
- Your needs will always change. Say you do manage to document absolutely everything you need your CMS to do to not impede content authors. Even in this unlikeliest of scenarios, if the team nails it, it will only result in everything working exactly as it should on day one. But what about day two? Day three? Your content needs are going to evolve, and no one knows what’s next. You might start a TikTok social campaign and now need to embed them on your website — there are things you can’t plan for that your CMS won’t support without developer involvement.
- It’s costly. Let’s go back to the FAQ example. You can have it all — both a comprehensive FAQ system and a flexible accordion component you could place across your website. But then both systems need to be developed. Do you need both? Which one’s really the priority? The constraints of delivering a project on time and on budget may require foregoing one of the options. But that also means there may come a time when you wish you had the other option. And you might think your CMS is to blame, when it was the time and money you had available to build it.
- It’s risky. The more power content authors have in a CMS to deviate from a content’s structure in order to do something different with the presentation, the harder it gets to manage. Even something as innocuous as say, providing colour formatting tools for a page heading in the CMS — like that one client wanted — for the off chance an author needs a different colour, introduces challenges. An author could treat some text with a colour they think looks good, but is not legible enough for accessibility and it creates a risk for the website. To mitigate that issue, the whole authoring team needs more robust training in using accessibility checkers before they can use the CMS properly. But even if the authors are good at ensuring accessibility, what if the brand evolves and the website needs to change its colours? Now all the page headings that had their colour changed from the default need to be found and updated manually. Don’t miss a spot!
- The web is too sophisticated. 2008 style CMSes, which allow for structured content but also control elements of presentation (unlike their 2018 style Headless counterparts) would sometimes extend complex controls to content authors to be able to do developer-like tasks such as compose page grid layouts, make dynamic views of structured content, or allow for injection of CSS code for custom styles (the image of Drupal above even showed HTML code editing). A very technical, developer-like content author could potentially use these interfaces to expand the capabilities of their CMS without a developer being involved. And for a time back in 2008, their efforts might have produced acceptable results. But while this was onerous and difficult back then, it’s prohibitive today. With an ecosystem of different devices sizes and capabilities, WCAG 2.1 AA accessibility requirements becoming commonplace, and a myriad of others reasons, these tools aren’t capable of producing acceptable results. Proper design, development and robust QA testing is required to deliver the experiences users expect today.
So your CMS doesn’t suck.
I hope you see now why even a modern, capable CMS expertly customized by developers to balance authoring power and flexibility with structure, will disappoint you at times. Inevitably there will be a point when you decide you want a layout to look different, or a colour to be changed, or new types of content to be captured and nowhere within the CMS are you granted that level of control.
In a perfect world, you’d be able to have that control, just as you need it, and you’d pull off a new layout for the site that somehow just works responsively for all devices without requiring any developer intervention or quality assurance testing.
In reality, bringing content to the modern web is complex and your CMS probably doesn’t have the feature your authors now want for one of the practical reasons listed above. But regardless of CMS, if you require a feature for authors to change a colour on a particular piece of content, it can be added by developers.
The web is meant to be iterated on, and it’s a responsible approach to develop these features as you learn you have a need for them rather than speculating you might need something in the future.
Or maybe your CMS actually does suck.
There may be real problems with your CMS that aren’t easily implementable as your site evolves. The user interface of the CMS may be difficult for authors to use and impossible or cost prohibitive for developers to overhaul it. The CMS may enforce certain opinions about how developers structure content that prevent them from being able to create reusable components and systems that allow for layout flexibility with content structure. The CMS may be end of life, and in desperate need of upgrades. The CMS may be low performing for the type of content it needs to show. The CMS may have a shrinking developer community that makes it difficult to find support to grow it as your needs evolve. The list goes on and on.
Your CMS might actually be bad for your needs, and that’s something you should evaluate if you’re having troubles. But content authors being unable to change a the colour of a page heading they originally never knew they ever wanted to change is not the reason your CMS is bad.
And that’s the full explanation I wanted to give to that frustrated business, and maybe now you can see why I held back.
