`
`Usability Engineering
`
`JAKOB NIELSEN
`
`SunSoft
`2550 Garcia Avenue
`Mountain View, California
`
`MU
`
`Morgan Kaufmann
`
`An Imprint of Elsevier
`
`Amsterdam Boston Heidelberg London New York Oxford
`Paris San Diego
`San Francisco Singapore Sydney Tokyo
`
`Apple Inc.
`Exhibit 1017
`
`Page 001
`
`Apple Inc.
`Exhibit 1017
`Page 001
`
`

`

`This book is printed on acid-free paper.
`
`Copyright © 1993 by Academic Press.
`
`An Imprint of Elsevier
`
`All rights reserved.
`
`No part of this publication may be reproduced or transmitted in any form or by
`any means, electronic or mechanical, including photocopy, recording, or any
`information storage and retrieval system, without permission in writing from
`the publisher.
`
`Pemiissions may be sought directly from Elsevier's Science and Technology Rights Department in
`Oxford, UK. Phone: (44) 1865 843830, Fax: (44) 1865 853333, e-mail: permissions®elsevier.co.uk.
`You may also complete your request on-line via the Elsevier homepage: http://www.elsevier.com by
`selecting "Customer Support" and then "Obtaining Permissions".
`
`All brand names and product names are trademarks or registered trademarks of
`their respective companies.
`
`ACADEMIC PRESS
`
`An Imprint of Elsevier
`525 B Street, Suite 1900, San Diego, CA 92101-4495 USA
`http://www.academicpress.com
`
`Academic Press
`
`Harcourt Place, 32 Jamestown Road, London, NW1 7BY UK
`
`Morgan Kaufmann
`340 Pine Street, Sixth Floor, San Francisco, CA 94104-3205
`http://www.mkp.com
`
`Library of Congress Catalog Number: 93000488
`International Standard Book Number: 0-12-518406-9
`
`Printed in the United States of America
`04 05 06 07 08/12
`
`Apple Inc.
`Exhibit 1017
`
`Page 002
`
`Apple Inc.
`Exhibit 1017
`Page 002
`
`

`

`Apple Inc.
`Exhibit 1017
`
`Page 003
`
`Usablllty Heuristics
`
`\ M
`
`etaphors also present potential problems with respect to interna-
`tionalization, since not all metaphors are meaningful to all cultures.
`For example, a Danish interface designer might choose to use the
`pause signal as a metaphor for delayed system response, drawing
`upon the common knowledge that radio stations play a special
`endless tune of the same 13 notes repeated over and over when one
`show finishes before the scheduled starting time of the next.
`However, the concept of a pause signal would be quite foreign to
`users in many other countries, such as the United States, where
`radio stations fill every available moment with commercials and
`would never put on a special signal just to fill up time.
`
`5.3 Minimize User Memory Load
`
`Computers are very good at remembering things very precisely, so
`they should take over the burden of memory from the user as
`much as possible. In general, people have a much easier time at
`recognizing something that is shown to them than they have at
`having to recall the same information from memory without help.
`This phenomenon is well known to anybody who has learned a
`foreign language: Your passive vocabulary is always much larger
`than your active vocabulary. And of course, computers really speak
`a foreign language as far as the users are concerned.
`
`The computer should therefore display dialogue elements to the
`users and allow them to choose from items generated by the
`computer or to edit them. Menus are a typical technology to
`achieve this goal. It is also much easier for the user to modify infor-
`mation displayed by the computer than to have to generate all of
`the desired result from scratch. For example, when users want to
`rename an information object, it is very likely that they will want
`the new name to be similar to the old one, so the text edit field in
`which the user is supposed to enter the new name should be pre-
`populated with the old name, allowing users to make modifica-
`tions instead of typing everything.
`
`Interfaces based on recognition rely to a great extent on the visi-
`bility of the objects of interest to the user. Unfortunately, displaying
`
`
`
`129
`
`Apple Inc.
`Exhibit 1017
`Page 003
`
`

`

`_—_—_—_————
`Usablllty Englneerlng
`
`
`Usablllty Heurlstics
`
`AAAAAAAI
`BBBBBBB
`
`AAAAAAA
`CCCCCCC
`BBBBBBB
`
`Ar:
`
`WQASTE”
`
`too many objects and attributes will result in a relative loss of
`salience for the ones of interest to the user, so care should be taken
`to match object visibility as much as possible with the user’s needs
`[Gilmore 1991]. As usual we find that ”less is more."
`
`Whenever users are asked to provide input, the system should
`describe the required format and, if possible, provide an example
`of legal and sensible input, such as a default value. For example, a
`system asking the user to enter a date could do it as follows:
`- Enter date (DD—Mmm—YY, e.g., 2-Aug-93):
`
`An even better dialogue design would provide the example in the
`input field itself as a default value (possibly using today's date or
`some other reasonable date), thus allowing the user to edit the date
`rather than having to enter all of it.
`
`There is no need for the user to have to remember or guess at the
`range of legal input and the unit of measurement that will be used
`to interpret it. Instead, the system can supply that information as
`part of the dialogue, such as, for example:
`- Left margin:
`19 points [0—128]
`
`A famous example indicating the need to display measurement
`units to help the user’s memory was the positioning of a space—
`based mirror by the space shuttle Discovery [Neumann 1991]. The
`mirror was supposed to be aimed at a mountain top in order to
`reflect a laser beam, and the user had ordered the computer to
`point the mirror toward a point with an elevation of ”10,023 above
`sea level.” The user apparently entered the elevation as if it were
`measured in feet, whereas, in fact, the system used miles as its
`measurement unit, causing the mirror to be aimed away from the
`Earth, toward a point 10,000 miles out in space.5
`
`To minimize the users’ memory load, the system should be based
`on a small number of pervasive rules that apply throughout the
`
`5. With respect to measurement units, other usability principles often lead to a
`need allow users to select between several alternative units, such as inches,
`feet, miles, centimeter, meter, and kilometer, depending on their needs.
`
`Figure 13 A generic command: ”Paste” can be used to insert a line of C’s
`
`(text) as well as a striped square (graphics) at the insertion point.
`
`user interface. If a very large number of rules is needed to deter-
`mine the behavior of the system, then the user will have to learn
`and remember all those rules, making them a burden. On the other
`hand, if the system is not governed by any rules at all, then the user
`will have to learn every single dialogue element on its own, and it
`is impossible to predict the behavior of a dialogue element without
`already knowing (and remembering) how it works.
`
`The use of generic commands [Rosenberg and Moran 1984] is one
`way to let a few rules govern a complex system. As shown in
`Figure 13, generic commands make similar things happen in
`different circumstances, making it sufficient for the user to learn a
`few commands in order to work with many different types of data.
`One of the main advantages of generic commands is that they
`support transfer of learning from one application to the next, since
`users do not need to releam those commands they already know
`[Ziegler et a1. 1986].
`
`Generic commands need not perform exactly the same function in
`all circumstances, as long as the user can think of the command as
`
`130
`
`131
`
`Apple Inc.
`Exhibit 1017
`Page 004
`
`

`

`
`Usability Englneering
`
`—_——_‘
`Usablltty Heuristlcs
`
`a single unified concept, such as “insert the object from the clip-
`board” in the case of a paste command. As shown by Figure 13,
`this generic command may actually insert the clipboard and move
`some old objects out of the way, when it operates on text, but
`perform the insert operation without moving anything when it
`operates on graphics. The designer of a generic command will need
`to determine what ”naturally” feels like the same command to
`users, even if some details will differ due to the requirements of the
`different parts of the system.
`
`
`
`5.4 Consistency
`
`Consistency is one of the most basic usability principles. If users
`know that the same command or the same action will always have
`the same effect, they will feel more confident in using the system,
`and they will be encouraged to try out exploratory learning strate-
`gies because they will already have part of the knowledge needed
`to operate new parts of the system [Lewis et al. 1989].
`
`The same information should be presented in the same location on
`all screens and dialog boxes and it should be formatted in the same
`way to facilitate recognition. For example, my heating bill contains
`a comparison between my current heating use and my use in the
`same month in the previous year, listed as a table with the current
`year in the left column and the previous year in the right. To facili-
`tate my interpretation of these numbers, a footnote on the bill
`furthermore contains information about the average temperature
`in each of the two years. Unfortunately, the footnote mentions the
`previous year before (that is, to the left of) the current year, thus
`inverting the relation compared to that used in the table. Consis-
`tency considerations would have implied a design of this printout
`with the same spatial relation between the two periods for both
`kinds of information. An order where the previous year was
`mentioned before the current year might be preferred as being
`consistent with the way timelines work, but unfortunately one can
`also argue that the reverse order achieves a better match with the
`user’s task of assessing current heat usage. As is often the case in
`
`
`132
`
`user interface design, one would have to decide which of these two
`considerations was most important; once this decision had been
`made, one should follow it consistently and not mix the two layout
`rules.
`
`Many aspects of consistency become easier to achieve to the extent
`that one is following a user interface standard in the design, since
`the standard will then have specified many details of the dialogue,
`such as, for example, how to indicate a pop-up menu or which
`typeface to use in a list of font sizes. See Chapter 8 for a discussion
`of user interface standards and ways to increase compliance and
`thereby consistency. Unfortunately, standards compliance is not
`sufficient to ensure consistency, since the standards leave a fair
`amount of leeway for the designers. See the discussion of user
`interface coordination in Section 4.6 (page 90) for ways to promote
`consistency during interface design.
`
`Consistency is not just a question of screen design, but includes
`considerations of the task and functionality structure of the system
`[Kellogg 1987, 1989]. For example, Eberts and MacMillan [1987]
`found that subjects were more confused when they switched
`between using a command-line mainframe and a command-line
`personal computer
`than when they switched between the
`command—line personal computer and a graphical personal
`computer. From a screen design perspective, the two command-
`line interfaces were very similar, but the underlying operating
`systems were in fact very different. And the two personal computer
`interfaces were built on top of systems with the same basic philos-
`ophy and features.
`
`A study of a popular spreadsheet program found 10 consistency
`problems causing common errors for novice users [Doyle 1990].
`Seven of these problems were due to inconsistencies between the
`spreadsheet and the users’ task expectations, three were due to
`inconsistencies between the spreadsheet and other user interfaces,
`and only two problems were due to inconsistencies within the
`spreadsheet itself. The spreadsheet’s menu navigation method was
`classified as being inconsistent in all three ways and was therefore
`counted in all three categories. Of course, other systems may have
`
`133
`
`Apple Inc.
`Exhibit 1017
`Page 005
`
`

`

`____—_——_——————-
`Usablllty Engineering
`
`
`Usablllly Heurlstlcs
`
`different distributions of their consistency problems, but it is prob-
`ably quite representative that the larger scopes of consistency are
`the most difficult to get right.
`
`
`
`:5.5 Feedback
`
`The system should continuously inform the user about what it is
`doing and how it is interpreting the user’s input. Feedback should
`not wait until an error situation has occurred: The system should
`also provide positive feedback, and it should provide partial feed-
`back as information becomes available. For example, the way to
`write the German letter ii on many keyboards involves first typing
`the umlaut, ", and then typing the character that is to go under the
`two dots. Some systems provide no visible feedback as the first
`part of the character is typed,
`leading many novice users to
`conclude that the system does not know how to deal with umlauts.
`A better design would show the umlaut and then change the
`cursor in some way to indicate that the system was waiting for the
`second part of the character.
`System feedback should not be expressed in abstract and general
`terms but should restate and rephrase the user’s input to indicate
`what is being done with it. For example, it is a good idea to give a
`warning message in case the user is about to perform an irrevers—
`ible action, such as overwriting a file (see Section 5.9). Assume that
`the user is about to copy a file to another disk and that the copy
`operation would overwrite a file with the same name. The worst
`feedback (except none, of course) would be to state that a file was
`about to be overwritten, without giving its name. Better feedback
`would include the name of the file, and even better feedback would
`include attributes of the two files, such as file type and modifica-
`tion date, to help the user understand whether the copy operation
`was just replacing an old copy with a newer copy of the same file
`or whether the file being overwritten was in fact a completely
`different file that happened to have the same name.
`
`Different types of feedback may need different degrees of persis—
`tence in the interface [Nielsen 1987c]. Some feedback is only rele-
`
`
`134
`
`vant for the duration of a certain phenomenon, and can thus have
`low persistence, going away when it is no longer needed. For
`example a message stating that the printer is out of paper should
`be removed automatically once the problem has been fixed. Other
`feedback needs to have medium persistence and stay on the screen
`until the user explicitly acknowledges it. An example in this cate-
`gory would be a message stating that the user’s output had been
`rerouted to another printer because of some problem with the
`printer specified by the user. Finally, a few types of feedback may
`be so important that they require high persistence, remaining a
`permanent part of the interface. An example might be the indica-
`tion of remaining free space on a hard disk.
`
`Response Time
`
`Feedback becomes especially important in case the system has long
`response times for certain operations. The basic advice regarding
`response times has been about the same for many years [Miller
`1968; Card et al. 1991]:
`
`0 0.1 second is about the limit for having the user feel that the
`system is reacting instantaneously, meaning that no special feed-
`back is necessary except to display the result.
`0 1.0 second is about the limit for the user’s flow of thought to stay
`uninterrupted, even though the user will notice the delay.
`Normally, no special feedback is necessary during delays of
`more than 0.1 but less than 1.0 second, but the user does lose the
`feeling of operating directly on the data.
`. 10 seconds is about the limit for keeping the user’s attention
`focused on the dialogue. For longer delays, users will want to
`perform other tasks while waiting for the computer to finish, so
`they should be given feedback indicating when the computer
`expects to be done. Feedback during the delay is especially
`important if the response time is likely to be highly variable,
`since users will then not know what to expect.
`
`Normally, response times should be as fast as possible, but it is also
`possible for the computer to react so fast that the user cannot keep
`up with the feedback. For example, a scrolling list may move so
`fast that the user cannot stop it in time for the desired element to
`
`135
`
`Apple Inc.
`Exhibit 1017
`Page 006
`
`

`

`__—___—_———————
`Usablllty Engineering
`
`Sending the File “Usability Book.chapter5"
`Size: 157,841 Bytes.
`
`Estimated Time Remaining (min:sec): 1:30
`
`I
`100%
`
`Percent-done indicator for a hypothetical file-transfer
`Figure 14
`program. The design not only provides feedback expressed in the user's
`terms (the name of the file) and with respect to the progress of the transfer,
`it also provides an easy way out (cf. Section 5.6) in case the user gets tired
`
`of waiting or discovers that the wrong file is being transferred.
`
`remain within the available window. The fact that computers can
`be too fast indicates the need for user—interface changes, like anima—
`tions, to be timed according to a real-time clock rather than being
`timed as an indirect effect of the computer’s execution speed: Even
`if a faster model computer is substituted, the user interface should
`still be usable.
`
`In cases where the computer cannot provide fairly immediate
`response, continuous feedback should be provided to the user in
`form of a percent-done indicator like the one shown in Figure 14
`[Myers 1985]. As a rule of thumb, percent—done progress indicators
`should be used for operations taking more than about 10 seconds.
`Progress indicators have three main advantages: They reassure the
`user that the system has not crashed but is working on his or her
`problem; they indicate approximately how long the user can be
`expected to wait, thus allowing the user to do other activities
`during long waits; and they finally provide something for the user
`to look at, thus making the wait less painful. This latter advantage
`should not be underestimated and is one reason for recommending
`a graphic progress bar instead of just stating the expected
`remaining time in numbers.
`
`
`136
`
`
`Usabllity Heuristics
`
`For operations Where it is unknown in advance how much work
`has to be done, it may not be possible to use a percent-done indi-
`cator, but it is still possible to provide running progress feedback in
`terms of the absolute amount of work done. For example, a system
`searching an unknown number of remote databases could print the
`name of each database as it is processed. If this is not possible
`either, a last resort would be to use a less specific progress indicator
`in the form of a spinning ball, a busy bee flying over the screen,
`dots printed on a status line, or any such mechanism that at least
`indicates that the system is working, even if it does not indicate
`what it is doing.
`
`For reasonably fast operations, taking between 2 and 10 seconds, a
`true percent—done indicator may be overkill and, in fact, putting
`one up would Violate the principle of display inertia (avoiding
`flash changes on the screen so rapidly that the user cannot keep
`pace or feels stressed). One could still give less conspicuous
`progress feedback. A common solution is to combine a ”busy”
`cursor with a rapidly changing number in small field in the bottom
`of the screen to indicate how much has been done.
`
`System Failure
`Informative feedback should also be given in case of system failure.
`Many systems are not designed to do so and simply stop
`responding to the user when they go down. Unfortunately, no
`feedback is almost the worst possible feedback since it leaves users
`to guess what it wrong. Systems can be designed for graceful
`degradation, enabling them to provide some feedback to users
`even when they are mostly down.
`
`As an example, consider feedback to users of an automated teller
`machine (ATM). On February 13, 1993, all 1,200 ATMs belonging to
`a major bank in New York City refused to perform any user trans-
`actions for a period of four hours due to a bug in a software
`upgrade installed at the data center. According to newspaper
`reports, customers ”crisscrossed the city on futile scavenger hunts
`for an operating cash machine”6 since they did not know what was
`going on and hoped that other machines might be working. Since it
`would be unrealistic to expect a 1,200 node distributed computer
`
`137
`
`Apple Inc.
`Exhibit 1017
`Page 007
`
`

`

`________.__._._._.-_.-———-—————--—
`Usability Engineering
`
`
`Usability Heuristics
`
`system to function perfectly all the time without any software,
`hardware, or network failures, the user interface at the ind1v1dual
`ATMs should be designed to provide information to customers in
`case of any such downtime. Different messages should be given,
`depending on Whether the error is due to the central system (in
`which case customers need not waste time finding another
`machine) or whether the error is local. In order to inform customers
`correctly, the ATM needs to be able to perform rudimentary diag-
`nostics, and the entire system needs to be built with such dlagnos—
`tics in mind. Assuming that the system is designed for it, it should
`be feasible to give users meaningful information about the hkely
`cause and/or location of any system failures.
`
`
`
`5.6 Clearly Marked Exits
`
`Users do not like to feel trapped by the computer. In order to
`increase the user’s feeling of being in control of the dialogue, the
`system should offer the user an easy way out of as many situations
`as possible. For example, all dialog boxes and system states should
`have a cancel button or other escape facility to bring the user back
`to the previous state.
`
`In many cases, exits can be provided in the form of an undo facility
`that reverts to the previous system state [Abowd and DIX 1992;
`Yang 1992]. Users quickly learn to rely on the existence of undo, so
`it should be made pervasively available throughout the system as a
`generic command that undoes any state changes rather than being
`restricted to only undoing a special category of user actions. Given
`that undo and escape facilities are generally available, users Will
`feel encouraged to rely on exploratory learning since they can
`always try out unknown options, trusting in their ability to get out
`of any trouble without ill effects. A basic principle for user interface
`design should be to acknowledge that users will make errors no
`
`6. ”At a bank, automatic frustration machines,” New York Times February 14,
`1993, p. 45.
`
`
`
`138
`
`matter what else is done to improve the interface, and one should
`therefore make it as easy as possible to recover from these errors.
`
`As mentioned above, system response times should be as fast as
`possible. In cases where the computer cannot finish its processing
`within the 10-second limit for keeping the user’s attention,
`it
`should always be possible for the user to interrupt the computer
`and cancel the operation. In general, interfaces should show a high
`degree of responsiveness [Duis and Johnson 1990], to the extent
`that paying attention to the user’s new actions should get higher
`priority than finishing the user’s old actions. For example, if a
`graphics program takes a fair amount of time to repaint the screen,
`it should allow the user to scroll or to change the zoom level even
`before the screen has been completely redrawn.
`
`The various exit and undo mechanisms should be made visible in
`
`the interface and should not depend on the user ’5 ability to
`remember some special code or obscure combination of keys. Visi-
`bility is of course a general user interface design principle, with the
`possible exception of some dialogue accelerators, but visibility is
`especially crucial for exit support since users will need these mech-
`anisms in cases where they are in unfamiliar territory and may be
`afraid to lose data if they do the wrong thing.
`
`
`
`5.7 Shortcuts
`
`Even though it should be possible to operate a user interface with
`the knowledge of just a few general rules, it should also be possible
`for the experienced user to perform frequently used operations
`especially fast, using dialogue shortcuts. Typical accelerators
`include abbreviations, having function keys or command keys that
`package an entire command in a single keypress, double—clicking
`on an object to perform the most common operation on it, and
`having buttons available to access important functions directly
`from within those parts of the dialogue where they may be most
`frequently needed. Pen computers, vertual realities, and some
`mouse interfaces may may also use gestures as accelerators.
`
`
`139
`
`Apple Inc.
`Exhibit 1017
`Page 008
`
`

`

`________________________________________________—
`Usablllty Engineering
`
`*5
`Usability Heuristlcs
`
`A good example of a shortcut to make a frequent operation faster is
`the use of a sh'ucture generator in a hypertext authoring system
`[Jordan et al. 1989]. Since hypertext authors may often want to
`generate large numbers of similar hypertext structures with a given
`pattern of typed nodes and links (for example, each of the courses
`in an online course catalog might have nodes for course content,
`prerequisites, instructor, textbooks, and location), they can work
`faster if the system allows them to define templates of these struc-
`tures and to generate sets of nodes and links based on a template in
`a single operation. Macro and scripting facilities can be used to
`achieve similar effects in traditional command languages, and
`similar facilities are also being introduced to graphical user inter—
`faces.
`
`Type—ahead (typing the next input before the computer is ready to
`accept it) is not really a shortcut as such since it still requires the
`user to generate a complete sequence of input, but it can speed up
`the interaction by allowing the user to get ahead of the computer
`and not have to pay attention to all the steps in the dialogue. Simi-
`larly, in telephone-based interfaces and other speech-based inter-
`faces, users should be allowed to interrupt the voice prompts as
`soon as they know what to say. Graphical user interfaces can
`support a feature similar to type-ahead, in what might be called
`click-ahead: Users can click on the spot where the "OK” button will
`appear to dismiss dialog boxes before they have even appeared,
`and they can click in partly obscured windows before they have
`been made active. It is dangerous to allow type-ahead and click-
`ahead in all circumstances, however. For example, a critical alert
`message should not go away without having been visible, and the
`type-ahead buffer should be cleared in case there is an error in the
`execution of a prior command which would tend to make the rest
`of the user’s input invalid.
`
`Users should be allowed to jump directly to the desired location in
`large information spaces, such as a file or menu hierarchy. Often, a
`hypertext-like approach [Nielsen 1990a] can be used with links
`between information elements that are likely to be used together. In
`file systems, such links are often called aliases, since they provide a
`way to name an information object (file) without having to specify
`
`140
`
`the full pathname. Alternatively, popular locations may be given
`easy-to-remember names that have to be typed in by the user. This
`approach is popular on many videotex services. Finally, users may
`be allowed to give their own names to those locations they find
`especially important. By doing so, users can build up a list of book-
`marks that will enable them to return quickly to a small set of loca-
`tions [Bernstein 1988; Monk 1989]. Of course, following the
`”minimize—user—memory-load" principle,
`the user should have
`easylaccess to a list of the bookmarks defined by that user [Olsen
`1992 .
`
`Users should be able to reuse their interaction history [Greenberg
`1993]. A study of a command-line system showed that 35% of all
`commands were identical to one of the five previous commands
`and that 74% of the commands had been issued at least once before
`
`[Greenberg and Whitten 1988]. Thus, a simple menu of the last few
`things the user had done would make it possible for the user to
`reissue a large number of commands without having to reenter
`them. Also, word processors, hypertext systems, and other systems
`where users navigate large amounts of information should have a
`backtrack feature or other history mechanisms to allow the user to
`return directly to prior locations.
`
`Even though conunand reuse is simpler for command—language
`interfaces, some direct manipulation interfaces allow users to
`reissue the last formatfing command or repeat the last search
`command by a simple command-key shortcut. It is also possible to
`use a kind of comic strip to show previous states of a graphical
`interface as miniatures [Kurlander and Feiner 1992] using a prin-
`ciple called a visual cache to allow fast direct access to those states
`[Nielsen 1990g; Wiecha and Henrion 1987].
`
`As a simple example of the use of the user’s interaction history to
`provide shortcuts, some applications keep track of which files
`users often open in those applications [Barratt 1991]. The applica—
`tions can then offer users a special menu of the files they are most
`likely to open next, either because they have been used recently,
`because they are used a lot in general, or because they are normally
`used together with other files already opened in a particular
`
`
`141
`
`Apple Inc.
`Exhibit 1017
`Page 009
`
`

`

`____________——————-
`Usabillty Englneerlng
`_——___——__.——’—————
`
`
`Usablmy Heurlstlcs
`
`
`session. Statistics on such ”working sets” of files that are often used
`together are slightly harder to get right than statistics on the most
`recently used files, but they can offer users a convenient shortcut to
`get at several files in a simpler way than having to find them one at
`a time in the file system.
`
`System-provided default values constitute a shortcut since it is
`faster to recognize a default and accept it than having to specify a
`value or an option. In many cases, users do not even need to see the
`default value, which can remain hidden on an optional screen that
`is only accessed in the rare case where it needs to be changed.
`Defaults also help novice users learn the system since they reduce
`the number of actions users need to make before using the system,
`and since the default values give an indication of the kind of values
`that can legally be specified.
`
`
`
`5.8 Good Error Messages
`
`Error situations are critical for usability for two reasons: First, by
`definition they represent situations where the user is in trouble and
`potentially will be unable to use the system to achieve the desired
`goal. Second,
`they present opportunities for helping the user
`understand the system better [Frese et a1. 1991] since the user is
`usually motivated to pay some attention to the contents of error
`messages, and since the computer will often have some knowledge
`of what the problem is.
`
`Error messages should basically follow four simple rules [Shnei-
`derman 1982]:
`
`0 They should be phrased in clear language and avoid obscure
`codes. It should be possible for the user to understand the error
`message by itself without having to refer to any manuals or code
`dictionaries. It might be necessary to include internal, system—
`oriented information or codes to help systems managers track
`down the problem, but such information should always be given
`at the end of an otherwise human—readable error message and
`should be combined with constructive advice, such as “Report
`this information to your systems manager to get help.”
`
`I],
`142
`
`0 They should be precise rather than vague or general. For
`example, instead of saying, "Cannot open this document,”
`the computer should say "Cannot
`open
`‘Chapter
`5'
`because the application is not on the disk" (also
`following the principle about giving feedback by restating the
`user's input).
`
`0 They should constructively help the user solve the problem. For
`example, the above error message that a document could not be
`opened could be made more constructive by replacing the words
`"the application” with the name of the application, indi—
`cating to the user what should be done in order to read the docu-
`ment. The message could also offer to try to open the document
`with some other application that was known to accept data of the
`given type.
`
`One useful way of generating constructive error messages is by
`guessing at what the user really meant to say. In the case of
`textual input, spelling-correction methods have been available
`for many years [Peterson 1980; Bentley 1985], and these methods
`can be especially fast and precise when the set of correct user
`inputs is restricted to a known set of terms such as the names of
`files and commands [Bickel 1987]. Durham et al. [1983] found
`that even a simple spelling corrector could handle 27% of all user
`errors in a text-oriented interface, thus confirming the value of
`this cheap method. The Interlisp programming system eve