Book Review: Coordinating User Interfaces for Consistency

Home/Publications/Best Practices Newsletter/2002 – Best Practices Newsletter/Book Review: Coordinating User Interfaces for Consistency


April 2002

Book Review: Coordinating User Interfaces for Consistency

CIDMIconNewsletter Reviewed by Henry Korman, Partner, Wordplay

Hobnobbing with the Hobgoblins

“A foolish consistency is the hobgoblin of small minds…” wrote Ralph Waldo Emerson. How many of us have been reminded that we left out the “foolish,” and in so doing changed the meaning of his statement? But how often have we been reminded also that we’ve left out the ellipsis? Emerson indeed went on to conclude: “…adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do.” Indeed? Is it consistency in general that he’s finding fault with after all? In the remainder of his essay, Self-Reliance, Emerson investigates the idea of consistency with great care, in detail, and with a subtlety belied by the abstracted adage. To reap the rewards of Coordinating User Interfaces for Consistency, we must be no less careful in our approach.

Edited by Jakob Nielsen, and first published in 1989, this reprint is warranted by the strength and durability of several of its nine articles. Nielsen admonishes that “…usability methods are much more durable than the average computer technology…. This book is about the methods needed to coordinate the efforts of multiple designers …so that the resulting designs form a coherent whole where users can transfer their learning from one design element to the next.” In my experience, these messages have yet to be absorbed by many companies, and although the articles were written with UI design in mind, they apply with equal force to the arena of technical communication. The principal reason for this state of affairs is the relative ease in formulating rules and guidelines and the difficulty in setting out and gaining agreement for a coherent, communicable vision which can direct the application of the rules during the hurly-burley of development. This difficulty, involving, one might say, consistency itself, rears its head in Nielsen’s unintentional subverting of the seriousness of his message when he refers to replicating the usability of Apple’s Macintosh interface by using “most of the same tricks.”

[Emphasis added.]

Similar contradictions appear elsewhere. The book is permeated by the conflict between trying to act from a methodology of interface design based on the user’s point of view and the deeply ingrained habit of adopting the system’s point of view which is embedded in the environment and works silently to compromise change or prevent it entirely. This relict must first of all be recognized in ourselves when it surfaces. For instance, this tension appears in the contradictory consecutive sentences from “New Ways to Consistent Interfaces” by Ianne Howards Koritzinsky: “Developing a design concept consistent with the end-user’s expectations is critical to the success of the interface. The design concepts embody the high-level goals of the system.” Shouldn’t the second sentence rather read, “The design concepts embody the high-level goals of the user?” A meticulous sorting out of such contradictions increases the odds of making good use of all the practical advice Koritzinsky offers.

Nielsen opens the book with his own “Executive Summary” of the advantages, dangers, and dimensions of consistency, and methods for achieving it. Although he advises that it’s the chapter to read if you have time for only one, a reader needs an in-depth background to these issues in order not simply to take in the bullet-points and go off half-cocked.

The importance of communicating the essentials of the design is addressed in Michael Good’s case study, “Developing the XUI Style.” He reviews the methods of the team at Digital Equipment Corporation, including creating a style guide, programmer’s toolkit, consulting with usability engineers, and heavy use of electronic communication. “What we did not know then, but would soon find out, was how much more we needed to do. While these methods were important, they were not sufficient by themselves to produce a consistent XUI style…. Developers following the Style Guide Specifications were creating very different types of interfaces to their products,” concludes Good. He nails down what he means by comparing interface style with architectural style. “In the art and design worlds, styles are often instantly recognizable after seeing a few examples…. Bauhaus style is easily distinguished, at a glance, from Post-Modern style. No list of rules is used to make the distinction, and probably no list of rules could ever be written.” Good goes on to discuss the sharing of early scenario-based prototypes and the holding of user interface fairs as means for developing a unified design in which establishing good relationships among all the players is key.

In “The Dimensions of Consistency,” Wendy Kellogg sets out the salient factors for assessing consistency. The descriptive component encompasses the consistency of the interface structure and features, its internal consistency. The evaluative component looks at the relationship between the interface and things outside the system, such as user knowledge and task domain, its external consistency. Only by understanding contexts of use and user’s tasks can beneficial inconsistencies be recognized, which is central to avoiding “foolish” consistency. Kellogg also has useful advice to give in the all-too-common situation where context of use information is not available. There, “designing for consistency is still possible by assessing the range of possible contexts of use and …by promoting higher-priority consistencies in the design.” This dovetails neatly with Good’s advocacy of scenario-based design. (And I would add, with the development of narrative user portraits and explicit, documented user models.) Her examples illustrate the issues sufficiently to adequately represent their complexity as well as how to deal with it.

The article on cost-benefit analysis by Daniel Rosenberg presents a useful, if familiar, set of dimensions for evaluation. Unfortunately, the sample sizes in the examples are too small to generalize from. This lack is somewhat obscured by authoritative-looking tables and charts.

Bruce Tognazzini’s overview of “Achieving Consistency for the Macintosh,” like Good’s article, gets to the root causes of inconsistency and its consequences. The article provides enough detail to make it a useful starting point for outlining a program of your own. At the outset, he relates corporate and developer commitment. Without “a willingness to embrace the ideal of consistency, our efforts at Apple would surely have failed…. We had spent many years `kind of’ wanting a consistent interface on the Apple II and never achieving it…” His discussion makes clear that without this willingness, no results would have been possible. Tognazzini rounds out the picture of involved players by pointing out issues of importance to users, dealers, and the press. Among other factors he discusses are the roles of guidelines and key applications, flexibility (inconsistency!), evolution, quality-assurance, and user testing, of which he states categorically, “We have found no substitute for testing human interfaces on members of the target audience.”

Ianne Howards Koritzinsky, in addition to tools mentioned by others, makes good cases for employing object oriented design and call back design-a method for having the user interface invoking the application’s routines rather than vice-versa. She tackles the interpersonal aspects from the local context-in which most of us find ourselves operating-and relates the effort to a broader corporate context in which cultural change is the goal. Managers need to be shown the benefits of a consistent interface and be assured that costs won’t run amok. Engineers need to have a sense of ownership. Although, as she recommends, a task force of engineers who are interested in the new methods is necessary to persuade other engineers and management, I’ve found that often one engineer alone is needed to fully commit and who will then persuade others from whom such a task force will be drawn. Moving into a wider context, her advice is invaluable and true to my experience of similar situations. “The key to developing a shared vision is to present the message quietly and frequently. The process is gradual, as the vision cannot be forced upon people.” CIDMIconNewsletter

About the Author