It is a truth universally acknowledged, that a single user in possession of a good CMS must be in want of a better CMS.
(Yours truly – with apologies to Charlotte Brontë)
I wrote last week on the topic of user satisfaction in WCM and how complicated it is to categorize and evaluate underlying data to make product management decisions. I wanted to expand that concept out even further to acknowledge another universal truth – in many cases there are active conflicts in WCM system design and philosophy that are often actively contradictory and hard to resolve. If you work to make one task easier for one group, you are often making a task harder for another, or you end up making multiple interfaces/approaches, leading to customer confusion about which one to use.
In general, this conflict leads to a situation where (if you are looking at blended aggregates in the data) you see mixed or negative results across the board. I used to joke that everyone hates their CMS; users think it’s too locked down and difficult to use for their liking, and developers/information architects think it’s not locked down enough (to stop users from doing horrible things to the visual design or content model).
It’s glib, but it at least kept me grounded in realizing that in most cases there are trade-offs and you either need to make sure your product UX choices are properly aligned to user tasks, or accept the reality that improving overall usability for all users and tasks is hard work.
Visual design (Layout-centric) vs. Structured Content
This is one of the fundamental conflicts going back for quite some time now. Back in “WCM 1.0” all systems had a form-like entry for content, which was then run through a transformation to create static HTML to deploy to the server. Having a system that gave a clear indication of the underlying content and the ability to edit in-line was a massive innovation and helped shift WCM from “decoupled” systems to “coupled/live” systems which pulled content dynamically into those components. It ushered in a trend where content authors, not developers, had a clear sense of control of what visual components were on a page, and how the page would look in production in real-time.
However, this trend has some downsides. The rich-client applications needed to drive this level of interactivity often leads to editing UI performance issues and author confusion due to complexity (“What content am I actually editing here? Is it live or draft? Why can’t that component go in that box? Why are there so many buttons?”).
I might argue the trend is reversing somewhat, and WYSIWYG editing and component layout is getting less important these days. We often hear the cry from authors: “Why can’t this be as easy as WordPress?” – and, notably, Gutenburg is not a full in-line WYSIWYG editor. I would describe it more as “What you see is what you need*” (* – in the case of writing/publishing). So clearly you don’t need full WYSIWYG to be considered by many the gold standard of authoring experience. Similarly, the rise of headless and static-site generating systems, it seems clear that many organizations are making a choice towards omnichannel content and authoring agility and actively questioning the priority on in-context editing in their vendor selection.
The conflict between the two approaches leads to mismatches in some cases. A purely visual layout system often makes structured content or re-use cases difficult. As a result of trying to resolve the conflicts, various vendors have tried different approaches; Adobe added Content Fragments to their primarily visual page composition system in AEM. Sitecore went the other way – originally they had their form-based Content Editor, then added the Page Editor (since renamed to Experience Editor) which cleverly layered visual design on top of that structured content. They then acquired what was to become the Sitecore Experience Accelerator (which brought even more Adobe-like drag-and-drop editing to the system in an attempt to resolve that visual design vs. structured content conflict in sales situations; “We can do both!”).
The term “hybrid headless” is often used to describe systems than can do both WYSIWYG editing as well as structured content storage and API delivery, but the actual meaning and functionality can vary considerably depending on the vendor. Some have less robust channel APIs (or lack a built-in CDN), some still have heavy editing interfaces, some rely on “bolted on” headless content in the visual system – so the definition can be muddied significantly.
Meanwhile, it seems that visual design on the web has (for better or for worse) settled into a rhythm where page layout is standardized to be very modular and based on repeatable concepts (logo top left, hamburger navigation on mobile view, screen width hero banner “above the fold”, three major sub-elements on the home page, major call to action in the top right, corporate boilerplate at the bottom in columns, etc.)
In many ways, this is no surprise as the primary goal is to help visitors accomplish their tasks (and non-standard navigation typically does not help with usability). Mobile/desktop views mean the grid system is also key in making designs flow naturally in those varied formats. Also, nobody likes to re-invent the wheel, so this is enabled by the fact that often martech stacks are re-using elements from common shared services; Twitter bootstrap, JavaScript frameworks like React, Vue, Angular, Google web fonts, WordPress themes (which themselves have mostly common design elements as they are based on common WordPress underlying principles of page/blog/tags), etc.
Compare the websites of Shopify, Contentful, Contentstack, Sitecore and Episerver and tell me that you can’t see the underlying visual layout design patterns are nearly identical. These patterns used ubiquitously across the web can be described in plain English and any author versed in web basics can intuitively understand what those elements mean: “hero image, call to action text, call to action button with link reference”, “two-thirds block, large image on left, smaller body text and header on right”, “three column table, header text, body text” etc. And if you and your authors can do that, you can use a headless system, set up a content model, name the elements appropriately, and have your authors intuitively understand what the output will look like in the web channel.
(As an aside, Every print designer I know is happy their investment in decades old principles is finally paying off – granted there are differences in current day applicability, but I would argue that modular grid-based layout is more fundamental to design now that it ever was, so you should have Josef Müller-Brockmann on your bookshelf, if only to impress nerdy houseguests like me).
Meanwhile, at the same time that layout is getting standardized (commoditized?), content itself is becoming more important. Companies now have to deal with pushing content to numerous channels; web, responsive web, responsive mobile, mobile-native, email, social, voice, kiosks, IoT devices, etc. and the differences in these formats has the effect of reducing atomic content to the lowest common denominator that works effectively across these channels (even to the point that in some systems HTML is no longer necessarily the preferred default storage format for rich text).
So what does this mean as a site owner?
Look at your use cases, the task tasks your team is trying to accomplish and the skills they have to work with. As a start, often the type of WCM system will dictate some of these choices for you – and in many cases they have been architected (with a bias) around a particular demand. For example, if you are a publisher, look to a system that lends itself to that use case – it’s likely the approaches and trade-offs have been tailored to you already.
Next – look to your team. If your primary goal is omnichannel and the team is skilled (and willing enough) to sacrifice WYSIWYG for agile development and content re-use then it’s worth considering that choice (many product and framework developments are trending to make this shift easier by the day). Similarly if you are reliant on external agencies to build sites with a “visual design” menu for your marketers, and your industry relies visually rich pages to sell (think something like travel and tourism) then a WYSIWYG system may still be the better choice.
Future articles to be published shortly will address the following topics;
- “Users vs. Developers”
- “New users vs. Experienced users”
- “Agility vs. compliance”
- “Simplicity vs. scale”
- Configuration vs. customization
(All of those are in quotes since the categories and problems are not as cut-and-dried as you might think).