Case Against the Browser?
The problem of rich text editing is really a subset of the broader challenge of using a universal "thin client" (the Web browser) to manage content. Relative to desktop applications, browsers force a variety of design trade-offs, including confusion about the back button, link ambiguity, having to repaint the screen with nearly every interaction, and the inability to drag and drop items. "Browsers just feel slower," concludes User Interface Engineering's Spool.
CMS vendors have tried to address these shortcomings by creating ever thicker clients, usually Java applets and ActiveX controls that run inside a browser. But these often bring accessibility problems and mitigate against the ease and universality that a thin client brings.
One CMS vendor, Mediasurface, has taken this to the extreme by developing a Windows desktop application it calls "Morello." Morello is slick. You can drag and drop files and employ many of the same standard commands that you would use in any other Windows application. But keep in mind, authors still have to learn new icons and metaphors. Morello pops new windows that contributors have to know how to manipulate and close. Every new interface brings a learning curve.
Erik Hartman, an independent CMS consultant based in The Netherlands, counsels against using browsers and rich text editors for casual contributors. "They know Outlook and Word, so use those." Indeed, many vendors now provide plug-ins to Outlook. Word is a bit trickier because the environment is so unstructured. Microsoft's new alternative for structured authoring is InfoPath. While it comes from Redmond—land of the friendly client—InfoPath still suffers from the same problem as other desktop alternatives: it's not Word. Hartman suggests "abusing Word as a forms editor" by creating templates. This may be possible for some content types in some organizations, but implementing it broadly across an enterprise represents significant change.
Is change always bad? Not for the enterprise. Business leadership may want to impose more control (perhaps for new regulatory reasons) or obtain more value from structured content. BBC's MacMillan found that business unit leaders at the network were very clear about corporate goals such as multichannel publishing and the development of new, hybrid content packages through greater chunking and classification. But "however much this is discussed with staff, it all remains very theoretical for people at the ‘coal face,' so for authors, the system had to be usable as well as decrease their time to publish."
BBC also found many contributors were motivated by creative freedom. This is probably universal: witness the success of blogging packages, which are all about the personal freedom to publish anything, anytime. On the other hand, many large enterprises have significantly reined in distributed Web publishing projects—from hundreds of users to dozens of users—after all that freedom became counterproductive.
This tension between freedom and control underlies many usability discussions in large enterprises, and should be addressed directly before any CMS project begins. However, those enterprises that want to exert more control should do so only in exchange for ease of publishing if they want the system to be adopted. Spool helpfully reminds us, "People aren't coming into work saying ‘oh, what a great day—I'm going to use the CMS!'" Employees have real work to accomplish, so perhaps the best thing a CMS can do is stay out of their way.
Usability and Product Selection
Given a growing profile and increasing attachment to business success, usability requirements are beginning to appear in product selection processes. The U.S. Department of Health and Human Services has established a variety of usability metrics to measure CMS bidders in a forthcoming procurement. A client of Step Two's Robertson in Australia attended user training sessions for multiple vendors before deciding which system was the most usable.
There is an emerging consensus that as project and contributor groups get larger, interfaces need to get simpler. This completely inverts traditional IT thinking, because—even if the enterprise can't define exactly what "simpler" means—major enterprise CMS products are nothing if not complicated. Put another way, the bigger the project, the less you should spend on a software solution.
A growing emphasis on usability also upends a marketplace heretofore focused heavily on features. Features and architectural fit still matter in any software acquisition, but should they be decisive in yours? At the same time, buyers should not be lulled into believing that good design will come cheaply. As Spool and others frequently point out, good design is a skill, takes experience and time, and is expensive.
In any case, you can add usability to the expanding list of reasons you should test CMS products with real users before buying anything. Employ scenarios and trust users of the system to judge if a product is right for them in the absence of being able to articulate in advance just what they will and won't find usable.
Perhaps this is a new paradigm for CMS product selection: if it feels good, buy it.