The trouble with the CMS paradigm. Or considering constant and casual editors.

stairsgraphicFor anybody dealing with a large amount of distributed web content, the content management system (or CMS) falls somewhere between a blessing and curse, between a true solution and a necessary evil. But a couple things last week made me wonder if it’s being approached all wrong.

First, my excellent co-worker Joe Fitzsimmons sent me a great article by Paul Boag titled (aptly) Everybody Hates their Content Management System. A few quotes stood out, articulating things I’ve long pondered yet not seriously considered:

For a start most content management systems are not fit for that purpose. That is because content management system vendors overestimate the skills of the average user. The majority of content management systems are not easy to use. They contain far more functionality and complexity than the average user needs.

Furthermore, with this distributed model, most CMS users only update the website occasionally. This means they are not becoming familiar with how these systems work and forget any training they have received.

The second paragraph correlated with the second thing that stood out to me last week. Our longtime web coordinator and head CMS support whiz, Pat MacNeill, recently took a well-earned retirement and our bright new webcomm associate hadn’t yet started. So I was fielding a lot of questions from people who hadn’t touched the CMS in months who needed help. They are all bright, engaging people for whom remembering how to navigate the vagaries of a CMS isn’t quite their specialty.

After troubleshooting several requests, none of which involved terribly complicated things, I suddenly had an epiphany: I’m spending 15 to 30 minutes explaining to them how to solve a problem that I might have solved in 15 to 30 seconds. I’m a big fan of efficiency in repetitive tasks, so this struck me as a grand waste of time for several people.

Boag’s article articulates this well. You have casual users who don’t often use (or even want to use) a CMS having to make an annual contact to our office for a refresher. Knowledge comes through repetition, but if tasks are hardly ever repeated, they can’t be learned easily. Throw in the bugs, glitches and complications of any CMS, and your user-support time piles up.

One of the biggest problems with CMSs are that implementers tend to train on the system, but not on the most important part — which is creating quality content. Without people understanding content, a CMS is no solution; a set of stairs only takes you to the next floor if you make the effort to climb. Without human effort and investment, a content management system will not give you content, management, nor a system.

But does it have to be this way? When you have scant central resources, as we do, is spending so much effort reminding or retraining editors on how to do something like insert an email link really a good use of time? A CMS editor is not a one-size-fits-all description. After having some kind of role in web management for around a decade, I’d have to say the majority of such editors fall into one of two categories:

Constant editors: Many higher ed web pages require frequent updates. There’s no getting around it. And we have an appreciable amount of what I’d call constant editors, updating pages at least once a week, especially during busy periods. Constant editors make regular use of the CMS and gain a considerable amount of skill and experience, so we only hear from them if they are bouncing ideas off us or attempting something ambitious. They are the stars of the distributed editor model because they bring subject matter and technical knowledge together to provide exemplary web experiences.

Casual editors: A college’s casual editors may touch the CMS as little as once a year to make updates to staff or events or other annual rituals. Or maybe every six months or so, or about how often many people have a dental exam — and they might find using a CMS about as enjoyable as visiting the dentist. Maybe they’re a swamped department secretary who has to go in and add new faculty and remove the departed. In higher ed, the jobs of department secretaries are among the most busy, demanding and valuable on campus; using a CMS is one of nearly 100 tasks on their plate. They simply don’t have time for trial and error for what should be simple.

All this comes into focus, and I believe it lays out the problem — that it’s flawed to consider a universal CMS “solution” that encompasses the dichotomy of experiences spanning from constant to casual editors. But what about the solution?

I have some thoughts on that … stay tuned!

7 Comments

Filed under Web

7 responses to “The trouble with the CMS paradigm. Or considering constant and casual editors.

  1. Good stuff, Tim. I look forward to reading your ideas!

  2. Pingback: Educational Policy Information

  3. Ditto. Secretly hoping you’re going to pitch for a completely centralized content model…

  4. We use Hannon Hill’s Cascade Server and I would say 80-90% of our users are happy with the system

  5. Great post! How many times has our Web Content team said these very things! (Too many!) I especially appreciate: “One of the biggest problems with CMSs are that implementers tend to train on the system, but not on the most important part — which is creating quality content.”

    The casual editors are usually skilled neither in using the CMS nor in crafting good content. It’s a problem. We have just under 400 CMS users (down from approximately 800 just a few years ago), and we’ve moved to a centralized published system for academic content, which has helped.

    I’m looking forward to hearing your thoughts on the solution!

  6. As well as thinking quite hard about the editor interface when the system was being developed, I get round some of the issues by having a support website and running a course every month so they can do a refresh. I don’t make the course handout available unless they come to the course. Plone uses a model of folders and pages that most people understand straight away, which was one of the reasons we chose it.

    My users haven’t embraced sharing issues with each other, although there is a mailing list that would allow this.

  7. At the University of Wisconsin-Superior, we’ve tried to think of ways to make it easier for users to contribute content without touching the CMS (CommonSpot. One way — we’ve created a simple web form for events, which goes into an inactive queue that we (University Relations) edit and publish in the CMS.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s