Hello, I'm Chris Murphy — I specialize in creating engaging, user-centric interactive experiences.

How to Fix Your Broken CMS: Part 2

Sometimes the "quick wins" on a project can turn out to be long-term losses. Has your CMS project turned into a win or loss for your organization? Perhaps it's time to take a step back and re-evaluate your CMS strategy or development roadmap.

Author’s Note: Considering the subject matter and length of this particular article, I’ve decided to split it into two separate articles.

Related Articles:

  1. How to Fix Your Broken CMS: Part 1
  2. How to Fix Your Broken CMS: Part 2

Background

In Part 1 of this series, I wrote at length about the current state of CMS software in general, and proposed a dramatic shift in our attention from features to user experience. At the end of the article, I offered a possible direction in terms of how to build a better CMS, and how we might better fulfill end user expectations (needs vs. wants).

In Part 2 of this series, I’ll be addressing the elements of what I feel would make a truly effective CMS.

Read on…

A Recipe For a Truly Effective CMS

Rather than approach a CMS as the alpha and omega of managing content, we need to approach it fundamentally: as tools to support people (and their myriad flavours of an editorial process).

Keep it simple. Keep it lean. Keep it efficient.

Ingredients

We need a few ingredients:

  1. A system to facilitate the editorial workflow
  2. A system to act as the delivery mechanism (loosely coupled with the presentation layer)
  3. Enhanced user-profiles to determine access levels and the end user experience

Profiles

Let’s begin with the last ingredient (the element that binds all others together): the user profile.

The fundamental need here is to deliver a user-experience designed for a wide range of end users without becoming homogenous, meaning that the interface with which an editor performs her job can differ dramatically from that of an content author.

Generally speaking, a single individual can act in one or all of the following capacities:

  1. The physical author of a piece of content
  2. The reviewer of a body of content
  3. The one delegated with the authority to promote content into another process

Note: these are fairly general roles, and granular capabilities/responsibilities/access rights should be introduced to reflect the organization’s needs.

The goal of a profile is to allow users (and those governing the process) to determine their desired user-experience based on both their role in the workflow, including selecting or customizing the interface that is ideally suited for their job function.

Everything else can be considered excess unless it promotes efficiency or enables productivity.

Example:

For simplicity’s sake, let’s assume that we’re talking about a content author—we’ll use Karen McNally as our archetype—whose only responsibility is to craft a piece of information and then promote it into the workflow.

Karen’s profile grants her access to a collection of her work (material that is still considered a work-in-progress, e.g. a “draft”), which she can edit or revise as necessary. When the piece of content is crafted and ready for review, she promotes it into the workflow.

Karen Smith has now fulfilled her fundamental role and responsibility as a content author. It is now up to another person—Michael Bloor, our ‘editor’ archetype—to review and make suggestions that she can implement.

Michael will then review Karen’s recent draft, suggest changes, contribute to the subject matter, and later promote it back into the system where it is then promoted further into the production chain.

What Karen likely sees in terms of an interface is a streamlined set of screens that:

  • Allows her to quickly access her work
  • Allows her to manipulate and edit her work, likely including suggestions for supporting material and media
  • Allows her to “check-in” her work into the editorial workflow

In the example above, we know that Karen only needs a certain set of screens and features in order for her to fulfill her responsibility as a content author. At this point, the material is then subject to an editorial process that might repeat once or several times before it is then delegated to someone else in the workflow.

In her role, Karen has little interest in formatting for final presentation—that is someone else’s responsibility. She does care about ensuring some basic formatting to communicate the subject matter, and it’s likely that she does have an interest in providing other source material to support her work.

As for Michael, he likely sees a set of of screens that:

  • Allows him to quickly access one or several drafts submitted to the editorial workflow
  • Allows him to make modifications and re-assign the draft back to the original author
  • Allows him to promote the draft into the production chain

In Michael’s case, he has a narrow set of responsibilities; however, his profile provides him with similar screens as Karen along with a series of screens that she would not otherwise see. On top of this fundamental difference, Michael has enhanced privileges that allow him to promote content or delegate content for other systems/processes.

The Delivery Mechanism

It’s a fundamental truth that a website will undergo change at some point—it might not be today or tomorrow—but it will likely evolve either through the introduction of new content or other factors like a redesign.

In the case of a redesign, many aspects of a website are affected: the underlying architecture, the look and feel, and in all likely hood—the content.

Considerations:

  • Most CMSs tend to be focused on short-term execution, e.g. getting a website developed and running
  • Most CMSs promote data-warehousing—a concept that is both dangerous in terms of potential liabilities for the organization, and inefficient in terms of productivity for the long-term users
  • Most CMSs are developer-centric and unfriendly to those who are not familiar with the developer’s philosophy around content management and the resulting methodology applied to the system in question

What we’ve experienced are systems that are designed for short-terms success for a small group of users and long-term frustration for the intended users (Karen McNally and Michael Bloor in our previous example).

What we want is is a system that is still intended to facilitate the production of a website, but is a process that is loosely coupled with the task of managing content. This means that our once feature-bloated CMS should now be an efficient tool for developers and web-designers to execute the website’s look and feel and features without having to juggle data-entry at the same time.

Essentials:

  • Integration with the editorial workflow
  • Light replication of data in the form of content instances that can be modified according to the rules of the presentation layer (the website)
  • A role-based interface for web-designers to execute the Information Architecture (IA) and Interaction Design (IxD) of the website, and apply presentation rules to content instances
  • A role-based interface for developers to visually access an manipulate data specifically related to the features and functionality of the website
  • An API for developers (font-end and back-end) to interact with content for enhanced presentation purposes or develop features for content dissemination

The marketers behind most CMSs tend to advertise the ability to manage all of a site’s information in one place, but they forget that information does not begin and end with the CMS. Content needs to live on in a universally accessible and secure location and should in all likelihood be subject to both the organization’s information governance policies and content strategy.

Given the above, we must now assert that a website should not to be used as an organization’s information warehouse, and that the concept of a content management system is most definitely a misnomer.

The solution that manages the nuts and bolts of a website is a system designed to do exactly that (and perhaps a little bit more if you need it to), but it should not be responsible for the long-term management of content.

This now leaves us with answering the workflow issue.

The Editorial Workflow

The editorial workflow is a system designed to support the creation and governance of content. All of the objects that comprise content (subject matter, media, resources, etc) are managed and governed by this system.

We can expect that a system like this can get convoluted and complex very quickly, but let’s distil things down to essentials before we start thinking about the additional requirements that are needed to support the essentials.

Essentials:

  • Integration with desktop systems/software (e.g. minimum: importing documents into the workflow; ideal: leveraging existing software like word processors to provide a familiar interface)
  • Version control and revision history to track the changes that are applied to a single unit of content
  • The ability to apply a strong taxonomy with support for folksonomy
  • The ability to link a unit of content with a collection of [supporting] source material (resource management)
  • The ability to promote a unit or collection of content from one user to another
  • Ensure access to the workflow is governed by user-profiles
  • Ensure that interfaces for the workflow customized according to roles and preferences
  • The ability to audit the collective content inventory (reporting)
  • The ability to provide data mappings

The above list address both process and the need for flexibility for organizations that might have a strict or collaborative workflow.

Some considerations:

  • Not all content is created equal, meaning that while text is the easiest to manipulate and consume, the method of presentation for the subject matter is what people experience; organizations will produce content in many forms—text being the most common—and the workflow is there to track and move it along from one process to the next. Assembly and integration into the presentation layer should handled elsewhere, e.g. promoted to another process.
  • The workflow overlays the repository and it’s complexity, meaning that while content is still created by people it needs to reside somewhere and in some mutable form—a database for all intents and purposes; however, that does not mean that the complexity of the database be reflected in the user-experience. Quite the opposite is needed.

Sounds like a tall order? It’s not—the only thing that makes software complex is our unrealistic expectations. But we still need something to bridge the gap between the delivery mechanism and the editorial process.

The Secret Sauce: Data-mapping (aka, our “bridge”)

What is it?

Data mapping* is the process of creating data element mappings between two distinct data models. Data mapping is used as a first step for a wide variety of data integration tasks including:

  • Data transformation or data mediation between a data source and a destination
  • Identification of data relationships as part of data lineage analysis
  • Discovery of hidden sensitive data such as the last four digits social security number hidden in another user id as part of a data masking or de-identification project
  • Consolidation of multiple databases into a single data base and identifying redundant columns of data for consolidation or elimination

* Source: Wikipedia: Data Mapping

The point that we’re most interested in here is: “Data transformation or data mediation between a data source and a destination”

What we want to do is map content that resides in the editorial workflow to areas in the presentation layer (the website templates, pages, parts, elements, what-have-you). This means that we are only referencing the source content, storing an instance of that content, and applying presentation rules derived from the presentation layer (the website).

Let me re-iterate that: the intent is to avoid directly handling and manipulating the source material.

Further considerations:

  • Instances of content are loosely-coupled, such that changes made to the source content do not necessarily affect the instance in the presentation layer until explicitly updated—we do this to preserve workflow and ensure governance
  • Content changes are one-way, meaning that instances of content are just that—modification of the instances, such as formatting, do not necessarily affect the source content—we do this to maintain the integrity of the source content and ensure compliance with governance policies
  • Instances are disposable, meaning that an instance of content might have a limited shelf-life; once decommissioned, the instance does not disappear completely. It still exists in it’s raw form in the editorial workflow

The reason we implement data mapping is simple: A CMS is a tactical system and should be decoupled as much as possible from the workflow, which is an operational system.

Effecting Change

For the record, this is why I think this approach would work:

  1. The approach aligns with user’s needs (not wants)—we focus only on what the end user needs, and build only the features and systems that will help that end user be productive and efficient.
  2. The approach bridges a fundamental gap between software and process—that is, it brings people back into the equation.
  3. We are not re-inventing the wheel—that is to say that traditional models and workflows have continuously proven to work, and we can learn a lot from the hard lessons others have had to struggle through.

I originally wrote this segment of the article to reflect the top three reasons why this approach would work. Instead, I changed my mind half-way through to reflect the crux of my argument: Content begins with people and ends with people.

That is the single fundamental that we need to understand.

I wish I could simply say that the only reason why this approach would work is that, “We need it to,” but that would be pure fantasy. In the real world we’re faced with an infuriating mess of business requirements, politics, and budget constraints.

If we’re going to effect change, we need to build an effective business case that brings people back into focus, and only you—yes, you—can do that. If you’re a consumer, developer, or in a position to make these kinds of critical decisions, you have an opportunity (and responsibility to yourself and the people who work with you) to choose a better way.

What’s Left?

I’ll round this off with a challenge to the industry and to consumers. My hope is that someone with enough patience to have read through this rather long-winded series of articles, will embrace the fundamentals and concepts proposed here and evangelize them.

A Message for CMS Developers & Marketers

I am not alone in feeling that software falls short of our expectations when it comes to managing content; after all, we see content published everyday and in all manner of forms.

It should not be this painful.

As a response to the overwhelming volume of poor implementations of content management software currently being marketed, I say this:

Forget the bloated features. Forget about development paths and methodologies; spare us the complexity. The act of managing content should not be obfuscated by deep click-paths or radical dependencies upon development skills or fanatic devotion to technology—it should begin and end with the end user (we, your true customers) in mind.

We want software that helps us do our jobs better, not by imposing what you feel should be our workflow and methodology—we’ll determine that, thank you very much—but by supporting our processes with tools designed to promote efficiency and with productivity in mind.

A Message for CMS Users

We are part of the problem and we need to make a full stop. We need to re-assess our current expectations of a CMS are and what is realistic.

Forget the marketing crap. You’ve been misled.

Your CMS is broken. You know it. I know it. But does your company’s leadership—the decision-makers who bought into the CMS know it? Does your IT group resent you for having to do your job on top of dealing with their own?

You need to speak up.

You need to find a way to clearly articulate why your CMS is broken, and influence your decision makers to move in the right direction: not by wasting more time and money on trying to fix what was broken from the beginning, but by stepping back and re-evaluating expectations.

You know that you hate wasting time and feeling incompetent and frustrated—its especially frustrating when you see it done so well in other forms. You want that. And by ‘that’ you mean the process(es) that help traditional media get their content from concept to publication.

Adopting a better approach begins with knowing what you really need and tempering your expectations with pragmatism. You need to build a compelling business case for change.

farfromfearless

Comments on This Post:

  1. How to Fix Y…
    Date: July 14, 2010
    Time: 8:17 am

    [...] Next Entry [...]

Add a Comment: