Hello, I'm Chris Murphy — I specialize in creating engaging, user-centric interactive experiences.
How to Fix Your Broken CMS: Part 1
Are you or your organization considering implementing a CMS? Do you have one in place already? Before you move ahead with your CMS project, you may want to take a few minutes to consider your expectations of a CMS before you commit your resources to the project.
Author’s Note: Considering the subject matter and length of this particular article, I’ve decided to split it into two separate articles.
In recent weeks I’ve been fielding a number of questions from prospective clients and visitors to my site regarding criterion for selecting the right CMS for their website. More often than not, I tend to direct them to an article I wrote previously on this particular subject: Top 3 Myths of Content Management Systems – Feb. 6th, 2009
The article offers some recommendations on selecting the right CMS for your organization, and some insights into common myths surrounding CMSs in general; however, the article does not necessarily provide the desired criterion for determining what makes a good CMS (or not).
The reality is that they are all pretty much the same—big (and getting bigger), feature-bloated, and a serious impediment for efficiency.
In short: your CMS can most certainly be considered a serious productivity killer.
From my perspective, the issues I’ve mentioned above stem from a series of false expectations on the part of CMS consumers that exploited by CMS developers by and large.
In my previous article I ranked the following as the number one myth surrounding CMSs:
“Myth No. 1: A CMS Should Manage Everything”
The statement asserts what I feel to be one of the most misleading notions of CMSs—the ability of a single software solution to manage every aspect of a website. After further consideration on this particular myth’s origins, I’ve come to realize that most of this stems from aggressive and misleading software marketing. And we—the consumers—are partially to blame for this.
For some absurd reason, we have this strange notion that a single solution is all we need, and in response, software vendors develop and market to that notion. The current market is saturated by systems both open-source and licensed and all of them tend to suffer from the same problem: feature-bloating.
Feature-boating is one of the tell-tale signs—to me—that a solution is trying to be too many things for too many people. The solution in question is trying hard to manage too many things when really it should only manage a handful of tasks or better: support a well thought out workflow that is tailored to the organization.
It seems to me that the software vendors—CMS developers in this case—tend to forget the end user and their experience.
The Tired Debate(s)
There are several ongoing debates about the merits and flaws of content management systems and content management in general. Chief amongst these debates are the following:
- Content Management Systems are for IT only:
The notion of managing the assets and objects of a website are the sole responsibility of IT for the simple fact that it is seen as a technical task and not an operational responsibility.
- Distribute the responsibility of managing content:
The notion of decentralizing content management and enabling “content owners”—those seen to be subject matter experts or authors—to take responsibility of conceptualizing and publishing their content.
These are diametrically opposing views serve to illustrate the chasm dividing opinion as to how to circumvent the issue of poorly implemented CMSs. There are strong advocates of better practices and better approaches to managing content, with some strong arguments and proposals in favour of better processes.
For the most part these debates only touch the surface of the issue. The typical approach/solution is to look at the the type and makeup of the organization, its stakeholders, and their particular roles/responsibilities as it applies to the website’s business requirements. At that point, whomever is in charge of making the ‘big decision’ then selects a solution with enough features to address 80-90% of these business requirements.
The selection of a CMS is almost as politically driven as the content that it is supposed to manage.
The resulting solutions places the organization back into the same vicious cycle created by lack of infrastructure, inhuman methodologies, and an understandable fear of technology. As a result, expectations are not met and the organization falls prey to its old habits, falling back into old patterns.
And the familiar debate begins anew.
A Different Approach to The Problem
What if we’re looking at the issue from the wrong perspective? What if it’s not enough to simply circumvent the issue with more systems and software?
It seems to me that given the emphasis on trying to become software agnostic by re-focusing on process alone, or attempting to become software-gnostic by relying exclusively on the software, we overlook the fundamental problem: the software we choose is still broken.
What we should be doing is focus on the following:
- A sound editorial process—a tailored (read: organization specific) workflow for getting content from concept to creation and eventually online.
- A better understanding of what is content vs. resources—the difference between the subject matter of a website and the assets and objects that help to communicate the subject matter.
- A shift in software development from Features to User Experience informed by Content Strategy—a fundamental movement by software vendors to move away from creating yet-another-CMS-with-identical-features-as-it’s-predecessors (accepting that the market will buy into software that addresses a fundamental need rather than a perceived notion).
The last two points—previously mentioned—are perhaps the two most underappreciated facets of building a better solution.
Resources vs. Content
In 2005 Adam Mathes published an interesting paper titled, “Source vs. Resource Ontology”. In his paper, Mathes attempts to present a better definition of resources in the context of electronic documents on the web.
There are some interesting insights in his work, and I particularly appreciate his pragmatic view of what resources are perceived to be in the real world.
A significant issue is that even pages we often refer to as being static are not in a strict sense, static, complicating things. “Small” edits over time, for example spelling corrections, change the resource content depending on your perspective. In many cases a “base” of static content is surrounded by dynamic content. For example, a news article that contains advertising. The “article” in one sense doesn’t change, but it is a dynamic resource in an important sense as the advertisements change. Other examples of small amounts of dynamic content in generally static resource include having the current day and time displayed on a page, even if the rest of the page is unchanged. Adam Mathes, 2005
This brings me to my point: we’ve been led to believe—through pervasive feature-focused marketing—that CMSs are able to effectively manage all aspects, assets, and objects of a website, e.g. “the content”. Resource are not Content. Resources are resources, and a CMS is little better than a crippled operating system sitting on top of a very complex database.
“Content” in the context of a CMS is both erroneous and problematic. It is erroneous for the fact that the fundamental experience of web is still text-based, and this is evidenced by:
- Continued emphasis on producing text-based content first and media later;
- Reliance on text-based search
- Ease of access
The notion is problematic for the following reasons:
- Content is abstracted to the point that a single piece of information cannot be distinguished from another by the fact that the “system” sees all as being equal. And often we see CMSs without strong implementations of a Taxonomy or Folksonomy solution to give the resources any meaning.
Note: abstraction is necessary where software is concerned—after all, defining meaning and purpose is a human’s task and not the sole province of the the software; however, you still need your software to support that fundamental task.
- As we incorporate more resources to communicate the subject matter of our content, the software intended to manage the resources requires a proportionate amount of systems or features to “connect-the-dots”—meaning that a a software’s complexity can be directly linked to the degree of abstraction as previously described. What we end up with is more “power tools for developers” and less productivity for those responsible for the long-term management of content (read: real people).
Victor Lombardi’s article on Boxes and Arrows is an excellent resource that presents a good case for managing the complexity of content management systems.
- CMSs emerge on the market with nearly identical features and with only small variations on their approach—and yet again, we still experience the emphasis on short-term development and less on long-term strategy and governance.
Emphasise “User Experience & Content Strategy” vs. “Software Features”
So far, I’ve made reference to several sources that go back as far as 2004—what that simply indicates is that serious issues with CMSs are not an emerging trend. They are in my observation, a continuing trend. And we continue to support that trend.
We the consumers—being a fundamental contributor to the problem of CMSs—have made it acceptable for software vendors to saturate the market with products that miss the mark completely when it comes to addressing a fundamental aspect of content management: Content begins with people and ends with people.
The Impact of Poor CMS implementations
If I am to sum up the impact of a poor CMS implementation it would be, quite simply: Frustration and Abandonment.
Both Erin Kissane, and Jeff Cram blogged about their particular frustrations and perspectives on CMSs and CMS implementations and their impacts on the organization. What’s interesting in both articles is that we see the continuing trend of the CMS getting in the way of efficiency and productivity. While Cram’s article nicely illustrates the frustrations of a poor CMS implementation (are there any good ones?), Kissane urges us to refocus on workflow.
…Create a workflow that works for your organization. Make sure your CMS supports that workflow. Erin Kissane
Users don’t care about the technology; they take it for granted that the technology will be there to support their jobs, but the sad reality is that the technology gets in the way. Again.
What users do care about is their experience with the CMS. Was it a good experience? Was it a bad experience? These are questions that influence decisions as to whether or not they will repeat the experience or abandon it.
When we talk about “user experience” in the context of a CMS, we’re talking about aspects like productivity, efficiency, and overall comfort level with the system in question. It is pretty clear to me that the vast majority of CMS developers take it for granted that their particular methodology of working with content (ahem, resources) is The Way To Go with little consideration for reality. And reality in this case is the end-user’s experience.
On Software Features
Software developers have proven that their ability to build pretty much anything in terms of systems to facilitate getting data into and out of a database. The feature lists of many of the available CMSs alone are enough to illustrate that point. But features alone do not make one CMS better than the next.
Unfortunately for the rest of us, those feature-bloated systems fall short in fulfilling expectations—one expectation in particular is that: I as a subject matter expert or content author should be able contribute to the creation of a body of information, without getting lost in the nuts and bolts of my CMS or without fear of liability (read: breaking the system).
Packing more features into the CMS compounds the issue. Stop. Take a good look at the audience—the people—who end up with the task of actually using the CMS after the development team has implemented it.
When it comes to audiences, it doesn’t matter if it’s an individual, a small business, or an enterprise-level organization that is using the CMS—they all have at least one thing in common: the end users are people who have jobs to do, not a heck of a lot of time to do it, and likely don’t have the patience to tackle the learning curb for that nifty new Cadillac of CMS [that is supposed to make their lives easier].
And when it comes to enterprise—there’s just a whole heck of a lot more of the same folks who share those same traits.
On Content Strategy
When it comes to the user experience with Content Management Systems, it has become increasingly difficult to discuss the topic without bringing Content Strategy into the conversation. And for good reason.
You cannot effectively implement a CMS solution without the Content Strategy to inform its use or role in the process.
There are some refreshing forward-thinkers out there like Kristina Halvorson, who make a compelling case for the necessity of a Content Strategy to help organizations effectively define and identify their priorities for content, and to teach better/pragmatic ways of approaching content for the web. In her book, Halvorson addresses the concept of a strong workflow to audit, capture, and produce better content through several phases.
What is compelling about her argument is that it is once again focused on people, not software.
Halvorson’s book, Content Strategy for the Web, does not cover—in full—CMS strategy (Software selection, design, and implementation)*
* Content Strategy for the Web, Kristina Halvorson, 2010, “What this Book Is Not”
Before we can start to improve the software we must also examine other models that have implemented a solid combination of software and process to provide a productive and efficient workflow that, well, works.
Case Study: The Traditional Editorial Process (aka Publication Production):
In an traditional news publication, the responsibility of conceptualizing/determining what is news worthy is left in the hands of the editors and may also be subject to a schedule [in the case of features].
It is the responsibility of the writing staff to develop the stories and craft them into something appropriate for the readership. Stories are then subject to editorial review and approvals, after which, it is promoted to the production cycle.
It is the responsibility of the production team to format the content into a presentable form—ready for mass consumption.
In the above example, we might see a single story evolve from concept to creation, and further evolution through review, contribution, and editing until it’s ready for publication. This is one flavour of the traditional editorial process, and may be present in more intricate or rudimentary forms in other organizations.
What’s notable about this example:
- A single story goes through a process and is handled by more than just one person (editorial process)
- A single story is always subject to a form of governance (editorial responsibility)
- The resulting story is then delegated to another process that shapes it according to the requirements of the medium (presentation)
- The system described above is a collection of several processes—the system of Publication Production.
What is still amazing to me is the fact that despite the evolution of software and the emergence of technology, the editorial process is still relevant. And they’ve been doing this every single day for decades without pause.
That begs the question: why—with all of the technology and knowledge at our disposal—are the content management systems unable to effectively replicate the efficiency and scalability of a traditional publication system?
The answer: software is the impediment—we the consumers and developers—expect software to do anything and everything with our content, forgetting that first and foremost that content begins with people and ends with people.
What we want is a solution (or set of solutions) that enables people to contribute to an organization’s collective knowledge, and ensure that the responsibility of disseminating content is left in the hands of people who [should] know where it goes and how best to present it.
A Little About the End Users
We need to recognize a few things about the typical end user:
- Software developers have proven—ad nauseum—their ability to manipulate data in all kinds of interesting ways—the typical end user doesn’t care.
- The typical end user doesn’t care about the fact that your CMS uses stored procedures or that you’re using ORM for database modeling.
- The typical end user doesn’t care a wit about the technical marvels you—the software developer—have pulled off in order to make your CMS function the way it does.
- The typical end user is concerned largely with the fact that they have a job to do and very little time to do it, but instead are starring dumbfounded at a screen loaded with all kinds of strange and confusing doodads that require a user-manuals thick enough to break windows.
- Lastly, [most] people care about people—human interaction is essential in organizations, and the reason workflows, work, is due to human interaction that drives the workflow.
This leaves us with a fundamental question to answer:
Q: If the goal is to de-emphasise feature development and emphasise developing better user-experiences for the end user, how do we do that?
A: We start by clearly establishing expectations (wants vs. needs) of what a CMS is and what it should do for us—the end users, and stop letting the software dictate our limitations.
A Unifying Concept
All of this talk about state-of-the-market and fundamentals is all well and good, but putting it to practice—truly developing and empowering CMS—is another thing altogether.
What we need is a unifying concept: the flux-capacitor to transcend the barrier of… well, you get the picture.
What this means is:
- If we’re going to start with the user, we need to ensure we address the end user’s fundamental expectations by providing an experience that is designed for them, and not a homogenized user experience that is meaningless—one size does not fit all.
- Content should not be managed in a silo but as part of a collaborative workflow—informed by strategy*, regulated through governance, and supported by technology.
- The system should not enforce workflow through strict methodology or present technical barriers but provide flexibility—allowing greater access to the process/system to effect productivity and promote efficiency.
* I wrote earlier about the necessity of a CMS being driven by strategy—forgive the double-speak—but when I talk about strategy in the context of a CMS, I do mean both the Operational Strategy (the workflow, logistics, etc) and the Content Strategy (the heart and soul of Content).
Let’s summarize what we’ve been talking about so far into a set of actionable principles:
- A CMS should not be the start-point and end-point of a content creation process (the editorial workflow), in fact managing content should be considered an on-going process.
- A CMS should be a system that allows instances of content to be formatted and manipulated according to the requirements of the presentation layer (the website). Instances by nature can be disposable.
- A CMS should be—at the very least—a set of loosely coupled systems: the first to facilitate the editorial workflow; and the second to facilitate production/publication for the presentation layer
With these concepts in mind, let’s focus on what’s needed executing the concept…