norman@cogsci.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) (02/07/89)
In an earlier article I cited some research of Jonathan Grudin that demonstrated that the common interface design rule of "be consistent" was sometimes best violated. I gave some examples of my own. This theme has recently been picked up by Aaron Sloman of Sussex and Daniel Kimberg of Princeton. So perhaps it is time to see Grudin's own words on the subject. I originally gave the incorrect citation for the work: it is actually an MCC tech report. The paper was presented at a recent workshop on HCI at which it received a controversial hearing. Too bad. I think it an intelligent analysis of the topic and recommend it highly. My suspicion is that there are a lot of design rules, consistency being one, but that these rules can sometimes lead to conflict. When conflicts occur, the rules have to take on priorities, and it is here that the consistency rule should sometimes be violated in favor of some stronger, more important principle. (Grudin and I are discussing the possibility of writing a paper that expands on this theme.) But enough -- I asked Jonathan to provide a summary of his paper for the net, and it now follows: don norman Donald A. Norman [ danorman@ucsd.edu BITNET: danorman@ucsd ] Department of Cognitive Science C-015 University of California, San Diego ---------------------------------------------------------------------- Date: Sun, 5 Feb 89 15:06:49 CST From: grudin@mcc.com (Jonathan Grudin) This is a brief summary of an MCC Technical Report Number ACA-HI-002-89 titled "the case against user interface consistency," mentioned by Don Norman. It is available from me (grudin@mcc.com) but will NOT be given at CHI'89 -- my paper there is "user interface design in large corporations: coordination and communication across disciplines." "The case against user interface consistency" argues through a series of examples that "build consistent interfaces" is not a good design principle. First of all, where some kind of consistency is desirable, the hard part is discovering which dimensions to be consistent along. For example, in abbreviating a set of two dozen command names, which is the best algorithm: truncation, vowel deletion, or single-letter-at- all-costs (even if it doesn't match the first letter of the command)? As explained in the paper, any of these could be the best design solution, it depends on aspects of the users' tasks. More importantly, consistency is often not desirable at all. A recent proposal for an international standard suggested placing the arithmetic function keys on numeric keypads across the top row in the order +, -, x, / because "that is consistent with the way we learn and remember these functions." True, but the most frequently used keys are generally the zero, ENTER, and plus keys, and this placement would maximize the distance from the plus key to the other two, thus maximizing the keying time and the likelihood of errors. A better solution is the more standard arrangement, with the plus key above the ENTER key, but this has nothing to do with "consistency," it is based on knowledge of the hand, motor control, and the data entry task. The paper also looks at menu defaulting and file management examples. Finally, a good user interface consultant is likely to find that a large, important part of the job consists of arguing AGAINST consistency. Because some of the most controversial and difficult user interface problems arise when the developers map the system architecture onto the user interface: when the user interface is consistent with the underlying implementation design but in conflict with how the user sees things. Sure, a lot of interface problems are due to careless inconsistencies, but when these are pointed out, generally everyone gets the point; it is more difficult to get designers to agree to user interface changes that are inconsistent with underlying software modularization. The negative message in the paper is that good design can't be found by looking at formal properties of interfaces, by a "consistency checking" or "consistency generation" program. The positive message is that for all of the examples described, one approach will lead to the design that is better than "consistent" designs. That approach is a close examination of the users' and their work, broadly defined to include sensory, motor, and cognitive psychology, users' work environment as well as their computer-specific tasks, and a broad picture of the system environment they will work within. This isn't easy, especially for product developers who may envision a wide range of users, but it is the approach that has to be taken. "Be consistent" is only a good rule of thumb when you are working in relative ignorance of your users and their work environments. Jonathan Grudin MCC P. O. Box 200195 Austin, Texas 78720 grudin@mcc.com
jeffries@hplabsb.UUCP (Robin Jeffries) (02/08/89)
Nick Flor says: > Anyways, I view the whole consistency/efficiency issue as follows: > > If we can believe that users when presented with a task involving the > use of a software tool, use the problem solving techniques of > abstraction and decomposition to break up the task into more manageable > pieces, we can envision a mental task tree -- where all subtrees of a > node must be satisfied before the task the node represents is satisfied, > [yeah, I know damn those CS metaphors]. At the top of the tree is the > root node which represents the overall task, at the bottom - the > physical actions necessary to accomplish the overall task. We can use > this task tree as the basis for discussing efficiency and consistency. > > If the task trees for two separate software applications are similar, > then the two applications are said to be totally consistent with each > other. If they differ in just the leaf nodes, then the user interface > is inconsistent. That's an interesting definition of inconsistency, but if its the "right" one, then Jonathon Grudin is exactly right -- consistency doesn't matter. Some recent research (don't ask me to look up the references, but some of it was done by John Anderson and other by Peter Polson (that stuff may not be published) very strongly indicates that if the only differences are in what you call the leaf nodes, then it is very easy to learn the second application, and, in particular, there is no negative cost of having learned the first one when you go to learn the second one -- the advantage of having learned all those intermediate nodes in the tree overwhelms the small negative cost of having to learn a new set of leaf nodes. This work was done with text editors in both cases, so its hard to argue that their stuff doesn't apply to what you are talking about. The costs of inconsistency seem to be at much different levels. For example, there is some research that suggests that having multiple ways to do a task (perhaps within an application, perhaps because you know two applications and each one does it differently) can be very costly -- presumably because of the mental cost of having to decide which one to use each time. My interpretation of the research I mentioned above is that if that cost is paid late in the tree it is relatively cheap, but if it has to be paid higher up in the tree, then it can screw you up. I doubt that is the only reason that certain forms of inconsistency are bad, but I believe it is one of them, and it seems consistent with what Grudin says.
rdh@thumper.bellcore.com (Ralph Hill) (02/08/89)
In article <714@cogsci.ucsd.EDU>, norman@cogsci.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) writes: > In an earlier article I cited some research of Jonathan Grudin that > demonstrated that the common interface design rule of "be consistent" > was sometimes best violated. > ... > The paper was presented at a recent workshop on > HCI at which it received a controversial hearing. > ... > don norman I was in the audience at this "controverial hearing." I, and many of the audience, are sympathetic to what Jonathan is saying, but there are some tricky issues here... I think the problem is not with "consistency", but the simple guideline "be consistent." Quoting Jonathon's summary: > For example, in abbreviating a set of two dozen command names, which > is the best algorithm: truncation, vowel deletion, or single-letter-at- > all-costs (even if it doesn't match the first letter of the command)? > As explained in the paper, any of these could be the best design solution, > it depends on aspects of the users' tasks. Notice that each is a different form of consistency. The question is not "to be consistent or not to be consistent?" it is "which consistency is best?" Continuing the quote: > More importantly, consistency > is often not desirable at all. A recent proposal for an international > standard suggested placing the arithmetic function keys on numeric keypads > across the top row in the order +, -, x, / because "that is consistent > with the way we learn and remember these functions." True, but the most > frequently used keys are generally the zero, ENTER, and plus keys, > and this placement would maximize the distance from the plus key to the > other two, thus maximizing the keying time and the likelihood of errors. > A better solution is the more standard arrangement, with the plus key > above the ENTER key, but this has nothing to do with "consistency," it > is based on knowledge of the hand, motor control, and the data entry task. And here we get into an agrument about consistency: I claim Jonathon's "better solution" is better because it is consistent with common usage of the keys. Again the question is "which consistency is best?": consistency with learning order (the proposed standard) or usage (the "better solution")? In this case (an over-learned task) usage is believed to be a better consistency. In other cases, say, recently learnt tasks, learning order may be better. I think Jonathon is giving half the argument: he is against bad consistency. So am I. He left out (or minimized) the argument for good consistency. And then, there is the really hard part: What is good consistency? How do you recognize it? Where do you look for it? I think Jonathon has made a good start in the right direction. Unfortunately (for all of us), we have a long way to go. My opinion: Consistency is not bad, it is simple application of simple rules like "be consistent" that is bad. If good interfaces good be designed by simply following simple rules, why are there so few good interfaces? Ralph D. Hill Bellcore rdh@thumper.bellcore.com Don't blame other members of the audience for things I have said.
grudin@sundown.ACA.MCC.COM (Jonathan Grudin) (02/10/89)
Ralph Hill and I don't differ fundamentally, but I don't think it is worth trying to defend "consistency" to the degree he does -- it is not useful and can be misleading. When examined carefully, his position reduces to "consistently do the best thing in every situation" -- we can all agree on that but it isn't useful. I attended a two-day workshop on User Interface Consistency at the CHI'88 conference. We spent several hours trying to define "consistency," then gave up and moved on to a discussion of how to achieve this thing we could not define. Why was it so hard? At least in part, it was because we wanted consistency to be "good" and thus tried to contort the definition to cover good designs and exclude bad ones, and that wasn't doable. My paper does note the positive aspects of many forms of consistency, especially for learning, although there are exceptions there too. But it emphasizes the other side, which is that a consistent interface is often a bad one. As I said in the summary, a leading cause of stubborn poor design is consistency, consistency with the software architecture or some other factor.. And consistency is often absent in a good design: Consider an efficient typewriter keyboard (QWERTY, Dvorak or whichever is your favorite). In what sense is it "consistent" with anything other than itself? Setting aside the problem of learning a new keyboard, the most efficient keyboard may vary depending on what language is being typed and depends crucially on aspects of the hand and motor control. But saying the keyboard is "consistent with the language" or "consistent with the hand" doesn't seem useful. But if you are determined to defend "consistency," here is one possibility: "Consistently maximize user efficiency and satisfaction." Because in order to do that, you will have to focus your attention on the users' work, which is where your attention is most usefully focused. Jonathan
ruffwork@mist.cs.orst.edu (Ritchey Ruff) (02/11/89)
I think if you separate the goal's from the actions (or "acts") in the interface you might get a bit closer to that elusive "consistency" definition. That is (using the mac as an example), clicking selects something, dragging moves something, etc. instead of "file commands go in a menu". With the mac, if the consistency at this "act" level is violated it is *very* confusing (ever use a mac program where a double-click does not select, or where a single click chooses but a double click does not select that item???). In article <83@sundown.ACA.MCC.COM> grudin@sundown.ACA.MCC.COM (Jonathan Grudin) writes: >And consistency is often absent in a good design: Consider an efficient >typewriter keyboard (QWERTY, Dvorak or whichever is your favorite). In what >sense is it "consistent" with anything other than itself? Yes, keyboards are not 'consistent', they are 'standardized'. Don Norman's book "The Psychology of Everyday Things" goes into many of these issues, and is very lucid. The main problem is to get a 'transparent' interface that the user doesn't really realize they are using. Many things lead to this, like - natural mappings (e.g., laying out labels on the screen for function keys in the same physical layout as the function keys are on the keyboard); - obvious usage (e.g., pictures of buttons to inform the use that you "push" these to get the action); - standardization (e.g., keyboards...no "natural mapping" available so define a standard and everyone learns it). Many more points are made in this book. While it's written about things like light switches and doors, every point made is directly applicable to use interface design too. Should be required reading for use interface designers!!! --Ritchey Ruff ruffwork@cs.orst.edu
SIAC@applelink.apple.com (Eric Ulevik) (02/12/89)
In article <8799@orstcs.CS.ORST.EDU> ruffwork@mist.cs.orst.edu (Ritchey Ruff) writes: > Don Norman's book "The Psychology of Everyday Things" goes into many > of these issues, and is very lucid. > [...etc...] > like light switches and doors, every point made is directly > applicable to use interface design too. Should be required reading > for user interface designers!!! To digress a little, I hope this book points out that light switches in the USA operate in the opposite direction to light switches in many other parts of the world. This inconsistency is still annoying me (after two months here) - I keep on trying to turn lights on, and merely making sure that they're off. I hope user interfaces for programs destined for international markets don't assume light switches work a certain way! Eric Ulevik email: SIAC@applelink.apple.com -- The above comments are mine!--
chac@aratar.UUCP (Chuck Clanton) (02/16/89)
- 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.dconway@rhea.trl.oz ( Switched Networks) (02/20/89)
In article <8799@orstcs.CS.ORST.EDU>, ruffwork@mist.cs.orst.edu (Ritchey Ruff) writes: > Don Norman's book "The Psychology of Everyday Things" goes into many > of these issues, and is very lucid. .... While it's written about things > like light switches and doors, every point made is directly > applicable to use interface design too. Should be required reading > for use interface designers!!! Could you give a full reference for this book? damian. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ who: Damian Conway email: dconway@rhea.trl.oz where: Network Analysis Section phone: (03) 541 6270 SNRB, Telecom Research Labs quote: "Consistent: adj. Not modeling Clayton South building (CS) the real world." 22 Winterton Road Clayton 3168 AUSTRALIA
ria@pbhyg.PacBell.COM (Richard I Anderson) (02/21/89)
In article <714@cogsci.ucsd.EDU> norman@cogsci.UUCP (Donald A Norman-UCSD Cog Sci Dept) presents some words of Jonathon Grudin: >---------------------------------------------------------------------- >Date: Sun, 5 Feb 89 15:06:49 CST >From: grudin@mcc.com (Jonathan Grudin) > > ..., one approach will lead to the >design that is better than "consistent" designs. That approach is a >close examination of the users' and their work, broadly defined to >include sensory, motor, and cognitive psychology, users' work >environment as well as their computer-specific tasks, and a broad >picture of the system environment they will work within. This isn't >easy, especially for product developers who may envision a wide range >of users, but it is the approach that has to be taken. "Be consistent" >is only a good rule of thumb when you are working in relative >ignorance of your users and their work environments. > I think the same can be said for many guidelines other than "be consistent" also. Project personnel often identify/select design guidelines to which a product's design is to adhere. Too little of this identification/selection (and too few design specifics) is (are) based on analyses of users' thoughts, tasks, experiences, ... Iterative design may actually promote this somewhat, because some believe that iteration will "take care of everything." However, as I argued in a presentation at a recent User Interface Symposium, iteration doesn't always succeed adequately, even when the testing on which iteration is based is conducted by "usability laboratory" personnel, and particularly if testing is restricted to a laboratory (where it fails to be impacted by work environment, other user tasks, ...). R. I. Anderson Human Factors Analyst Pacific Bell 2600 Camino Ramon, Room 2E850 (415)823-3715 San Ramon, CA 94583 {att,bellcore,sun,ames,pyramid}!pacbell!ria