Applying Usability Principles to Your CMS

Page 3 of 3

      Bookmark and Share

BEST PRACTICES SERIES

Sidebar: Usability and the Vendors

"Vendors are the worst people to work on usability of their own products: they invented their own terminology and approach and remain too close to it," argues James Robertson of Step Two Designs. And yet vendors feel strong pressure for greater usability and some are beginning to undertake serious usability research.

Interwoven's new user interfaces for Version 6 of its TeamSite product resulted from analysis of various personas across its wide client base. The most important—though perhaps most controversial—lesson Interwoven drew was that interfaces need to be easily customizable. Many usability consultants find this a cop-out. Some large enterprises find it a necessity.

Day Software lab-tests its Communiqué CMS product several times a year with untrained users. Among other tasks, authors are simply told to "create a new page." Not surprisingly, notes the company's CTO, David Neuscheler, "users responded in unanticipated ways." From iterative testing Day came up with a sidebar approach to reducing clicks by, among other things, showing recently-accessed pages and trying to anticipate user needs based on their context.

Over time, Day's interface, like many of its competitors', has increasingly come to resemble Windows Explorer. But here again, further testing showed that too close a resemblance to Windows confused some authors, who tried to close the CMS pane, thinking it was a system folder. Day modified its interface to make it XP-like, but not exactly Windows.

Of course, one option for contributors is to use Windows itself. There is an old saw that the Windows (or Mac) file system is everyone's first content management system. We all know how to drag or copy files to folders. Many CMS vendors have extended this metaphor by enabling authors to drag files into a Web-based repository via an explorer window, often using an open standard called WebDAV.

What WebDAV doesn't govern, however, is how those files get transformed (e.g., into HTML), chunked, and classified. Rules can be created in many content management systems to accomplish some of these tasks, but additional user intervention is often required, especially to add suitable metadata. Which is another way of saying that there are limits to how much any system can—and should—do authors' thinking for them (more about this in Part Two).

Almost all open-source CMS packages suffer from very poor usability. I know from where I speak. On CMSWatch.com I use an open-source package, Midgard. It boasts great performance and an elegant object model, but I generally don't recommend it for others, since it can be quite confusing out of the tarball for non-technical contributors. Other prominent open source projects, such as Plone, allow developers to modify interface "skins," but, particularly because they eschew almost any desire to emulate a familiar Windows environment, even packages like Plone typically engender a comparatively steep learning curve.

To their credit, open-source CMS project leaders have come to recognize their usability problems and in some cases recast their packages as "platforms" atop which other developers can create specific solutions, presumably including more usable interfaces. A cynic might argue that project leaders are punting on the whole problem of usability, while a more charitable explanation would suggest that they are just being realistic about their own lack of design experience and allowing the community to shape packages simply for particular scenarios.

Are there canonical attributes of a CMS that would make it simpler for anyone? The notion of universal rules makes most usability consultants queasy. It smacks of a deterministic approach for which usability guru Jakob Nielsen (among others) is frequently pilloried by his colleagues. I believe there are some general guidelines to pursue.

One guide worth perusing is Research-Based Web Design & Usability Guidelines, developed by the U.S. Department of Health and Human Services and available for free download at www.usability.gov. Although geared to Web site design, some of the findings ought to provoke thought about your CMS as well. Consider, for example, the following admonitions:

Detect errors automatically and provide reasonable explanations. Some Content Management Systems can't natively validate content on entry and provide obtuse explanations of problems when they do. At a minimum, you will need to configure the system to establish required (as opposed to optional) fields. However much we want systems to work "out of the box," no vendor can be expected to know the details of your particular content and process models.

Label form fields clearly. Some CMS systems (particularly open-source ones) use database field names as the default form field names. Do you know what an EmpLastID is? Neither do I.

Use color for grouping, but not to convey information alone. This is an accessibility issue as well. Many CMS buyers focus on accessible output, but quietly conspire with CMS vendors to ignore the accessibility of content input interfaces; this is beginning to change, however, as public institutions take more notice. Dutch consultant Erik Hartman advises, "Just use the word ‘Publish,' rather than color-coded symbols."

Other trail wisdom can also be helpful. Many large CMS implementations end up "turning features off" for casual contributors, where fewer choices and distractions may be more usable. Tabbed interfaces—long the bane of Windows applications—often confuse people in CMS applications too.

Most authors seem to find multiple browser windows a usability problem. Day, RedDot, and others have had to work to reduce this. The magic number seems to be two windows. Hallman from the U.S. Treasury argues that, "three windows are a lot, because it forces you to think more, and you have a greater chance of accidentally closing one and killing an important process."

Beyond this short list lies controversy. For example, one consultant I talked to suggested that a CMS should automatically clean up Word-generated HTML content rather than give options to leave it formatted as-is or paste it as simple text. However, a potential problem may arise when the cleaned up HTML then appears very different to the author, who could be confused why the now seemingly quite unusable system is messing with her formatting. So what's good for the goose is not always good for the gander. Whatever the expense of customization and attendant upgrade pain, perhaps the most usable CMS is the one that can be customized for all your scenarios.


Sidebar: Companies Featured in this Article

BBC Online www.bbc.co.uk
Day Software www.day.com
Erik Hartman www.hartmancommunicatie.nl
Department of Health and Human Services www.usability.gov
Interwoven www.interwoven.com
Intranet Focus www.intranetfocus.co.uk
Steve Krug www.sensible.com
MediaSurface www.mediasurface.com
Midgard www.midgard-project.org
Jakob Nielsen www.useit.com
Plone www.plone.org
RedDot Solutions www.reddot.com
Stellent www.stellent.com
Step Two Designs, Pty. www.steptwo.com.au
User Interface Engineering www.uie.com

Page 3 of 3