Path: utzoo!attcan!uunet!mcvax!cernvax!pan!aratar!chac From: chac@aratar.UUCP (Chuck Clanton) Newsgroups: comp.cog-eng Subject: Consistency Message-ID: <338@aratar.UUCP> Date: 15 Feb 89 20:25:04 GMT Reply-To: chac@aratar.UUCP (Chuck Clanton) Organization: Adasoft AG, Solothurn, Switzerland Lines: 88 - Foolish consistency is the hobgoblin of little minds. (?eliot?) - For every principle of user interface design, there is an equal and opposite principle of user interface design. clanton Before arguing the principle of consistency, it is important to understand what purpose is served by principles of interface design. I can see two. Interface design is a communications art much like literature, graphics design (not to be confused the entirely different subject of with computer graphics), photography and the decorative arts. How do you learn to write, take photographs, or become a doctor? You can start with education, but the real learning comes from practice and experience. A statement of principles has some value not because it defines what is right, but because it provides a hook on which to hang examples and a focus for discussion and thought. The goal for the budding interface designer is to develop taste and style. Another purpose, equally important, of a statement of principles is to help mediocre designers produce competent interfaces. Most software interfaces are going to be produced by ordinary programmers in the forseeable future. Not everyone needs to be a James Joyce, but Strunk and White can help the majority of people to write an understandable paragraph. In this sense, fashion (like the Mac "style" guide) can substitute for style (the ability of a skilled designer to create an interface that is distinctive and usable). Judged on the grounds of meeting these needs, the principle of consistency has a serious problem of ambiguity. What should be consistent with what? "Consistent with user expectations" is almost tautological, and where it is not, it is wrong. Software interface can be analyzed in terms of three levels of interaction. The lexical level consists of components like key presses and mouse motions. The syntactic level organizes these components into distinct interactions such as menu selection and text highlighting. The semantic level provides the users perception of the what the software is doing at the conceptual level. As with natural language, there is much to gain from a consistent alphabet of components. These should be consistent on both the input and output sides. I would not typically design an interface to consist of double clicks, triple clicks, quadruple clicks, etc. I strive for a small set of useful primitives. All labels are in the same typeface, and only a small set of point sizes are used as needed. Redundancy is used to clarify the interface; user enterable fields have a different typeface as well as other indications of their distinction from labels. The limited and consistently used lexical elements are composed to form the syntax of the interface. The syntax is represented by interactors or widgets, two words gaining popularity to describe interactive software components for building interfaces. Again, I believe that a small set of such components should be used to build an interface. The user can learn how to interact with each widget then carry that understanding over to other instances independent of the semantics of the widget in the application. At the semantic level, the principle of consistency has little value. Like language, lexical and syntactic consistency makes it easier to master the tools of expression and interaction, but the richness of what can and must be expressed is so great that I can not imagine reducing it to any regular form. In the last decade, I have been involved in the design of perhaps a score of application interfaces, as well as the internal design of perhaps a third of those. These systems range from process control to office automation. One thing is certain, the face of these programs does not match the innards. While the internal algorithms are often interesting, they are formal and regular because that is how you "design in" reliability, performance, maintainability, and all those other software engineering virtues. User expectations are neither formal nor regular. Matching the internal design to the user's needs is the job of the interface, which must clarify the relationship of the machine's world with that of the user. My experience is abounding with proof that interface consistency at the conceptual level is unlikely to match the user's expectations and desires. Of course, I also have a theory to explain the highly irregular nature of the user's requirements based on the sociology of organizations from which those requirements emerge. In brief, reality presents complex challenges, and organizations evolve their models for addressing those challenges over time. At any point in time, the current solution contains the entire ontogeny of the organization's past in dealing with a problem. Like the layers of vegetation and rock in the earth's crust, you can see this stratigraphy of solutions in the language and concepts used to describe the requirements, as well as whatever current systems are used which the software must reflect. The QWERTY keyboard of a color bitmapped computer workstation is a very simple example. Another fundamental reason for inconsistent semantics has to do with the complexity of modeling reality. The behavior of the real world is so complex that people and organizations use heuristics rather than analytic solutions. A characteristic of heuristics is their limited domain, and sudden inapplicability when certain conditions are not met. This shows up in interface design requirements as irregularities and apparent contradictions at the borders between two methods of solutions.