Oh What A Feature: Functional Usability of Web Content Management Systems

Page 1 of 3

May 04, 2005

May 2005 Issue

      Bookmark and Share

In Part I of this series, I looked at CMS interfaces and found that in general, users come to CMS projects with diverse expectations, leaving vendors struggling to match a product out of the box to a prospective customer's particular scenarios. As Jared Spool, founding principal of User Interface Engineering, puts it, "A CMS product is designed for an ideal, generic world, but none of us work in that world—it's like trying to sell everyone an average-sized shoe."

There is something to Spool's footwear analogy: CMS projects do come in different sizes, and system usability problems frequently stem from mismatches between the width of the problem and the girth of the proposed solution. But just as often, I think, CMS users find a system less-than-usable because the way specific features are implemented do not match their needs. For example, one Web site we'll look at below, the award-winning FirstGov.gov federal portal, publishes a scant 800 pages with only a handful of editorial staffers but nevertheless works off a deeply fine-grained content model accompanied by quite intense metadata requirements. For FirstGov, a prototypically "small" CMS won't work. 

So here in Part II, I'll examine usability through the lens of system functionality. What does it mean to have a usable workflow? Can a "Help" subsystem make up for the inevitable gaps in user training and understanding? How can authors find what they need? To the extent that you can answer questions like these for your CMS project, you are well on your way to developing a more usable—and therefore, by definition, a more effective—content management system.

From Pages to Content
Content management vendors and consultants often espouse the many benefits of moving from managing Web pages to managing discrete content items. "Contributors need to understand the meta-level—they are no longer making pages, but creating information that can be used to generate pages," counsels Erik Hartman of independent consultancy Hartman Communicatie.

Unfortunately, this transition is usually poorly understood among authors working in a component-driven CMS for the first time. As is often the case, part of the confusion stems from new terminology. For Dana Hallman, a content manager with the Department of Treasury, an entire first day of CMS training consisted of talking about the concept of the "placeless" content object. "You have to prepare yourself for different ways of working," she notes.

A new editorial approach can begin to present a usability problem when this new way of working feels like more work. For the FirstGov.gov portal team, deploying a CMS meant changing the way they edit their primary content type: annotated links to other federal pages. Instead of quickly opening and editing individual Web pages, authors must navigate through a CMS to modify a specific link. "It's a mixed bag," says Beverly Godwin, director of FirstGov.gov operations. "Some things take longer to do." On the "plus" side, the team can easily clean up bad links and publish single links to multiple category pages. They are also updating the site more frequently—several times a day instead of several times a week—now that they don't have to rely on external support to push changes into production. "From a citizen's perspective, it's much better," concludes Godwin.

Nevertheless, highly decomposed content models like those found on FirstGov bring another side effect. It takes contributors away from Word-like editors into a forms environment that can sometimes make even the most confident author feel like a data-entry clerk. The bad news is that some contributors may rebel at a loss of control over page layouts; the good news is that you can make a pure forms environment very simple for those with basic needs and who don't want an involved interface.

Page 1 of 3