Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!ucsd!cogsci!norman From: norman@cogsci.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) Newsgroups: comp.cog-eng Subject: consistency Summary: Consistency is good, but sometimes violations are better Keywords: consistency, desktop metaphor, interfaces, computing environments Message-ID: <714@cogsci.ucsd.EDU> Date: 6 Feb 89 17:35:02 GMT Reply-To: norman@cogsci.UUCP (Donald A Norman-UCSD Cog Sci Dept) Organization: UC San Diego Department of Cognitive Science Lines: 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