Principle of least astonishment

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The principle of least astonishment (POLA/PLA) applies to user interface design, software design, and ergonomics. It is alternatively referred to as the rule or law of least astonishment, or the rule or principle of least surprise (POLS).

A textbook formulation is "People are part of the system. The design should match the user's experience, expectations, and mental models."1 What is least surprising may however depend on the expected audience, e.g. end users, programmers or system administrators.2

In more practical terms, the principle aims to exploit users' pre-existing knowledge as a way to minimize the learning curve for instance by designing interfaces borrowing heavily from "functionally similar or analogous programs with which your users are likely to be familiar."2 User expectations in this respect may be closely related to a particular computing platform or tradition. For example, Unix command line programs are expected to follow certain conventions with respect to switches,2 and widgets of Microsoft Windows programs are also expected to follow certain conventions with respect to key bindings.3 In more abstract settings like an API, the expectation that function or method names intuitively match their behavior is another example.4 This practice also involves the application of sensible defaults.citation needed

When two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the user; in particular a programmer should try to think of the behavior that will least surprise someone who uses the program, rather than that behavior that is natural from knowing the inner workings of the program.citation needed

Contents

Examples

This section may contain original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research may be removed. (January 2012)
  • A user is about to enter his username and password for a program or website when he receives an instant message. Some instant messaging clients will immediately grab the keyboard focus and move it into their own response field, because they assume the user will want to respond to the new message immediately. In reality, the user may be astonished to find that they have just typed their password into their IM client and sent it to their friends. This conflict arises because the two programs are not aware of each other's existence, and cannot easily determine when they might get in each other's way. To avoid such conflicts, operating systems may restrict the interaction of different programs, for example by preventing the IM client from stealing the focus.
  • A user interface may have the behaviour that pressing Ctrl+Q causes the program to quit. The same user interface may have a facility for recording macros, a sequence of keystrokes to be played back later, intended to be able to control all aspects of the program. The user may want to record a keystroke sequence that includes Ctrl+Q as part (most likely the last part) of the macro. The principle says that pressing Ctrl+Q while recording a macro should not quit the program (which would surprise the user), but rather should record the keystroke (assuming the program is obviously recording a macro, likely through visual state).
  • The F1 Function key (in Windows operating systems) is almost always for opening a help program associated with a software. Users expect a help screen or similar help services popup when they press the F1 key. Software binding this key to some other feature is likely to cause astonishment at the lack of help. Malicious programs are known to exploit users' familiarity with regular shortcut keys.5 The corresponding key in Mac OS X is ⌘ Command+⇧ Shift+?.

See also

References

  1. ^ Saltzer, J. H.; Kaashoek, Frans (2009). Principles of computer system design: an introduction. Morgan Kaufmann. p. 85. ISBN 978-0-12-374957-4. 
  2. ^ a b c Raymond, Eric S. (2004). The art of Unix programming. Addison-Wesley Professional. p. 20. ISBN 978-0-13-142901-7. 
  3. ^ Petroutsos, Evangelos (2010). Mastering Microsoft Visual Basic 2010. John Wiley and Sons. p. 133. ISBN 978-0-470-53287-4. 
  4. ^ Bloch, Joshua (2006), How to design a good API and why it matters, Association for Computing Machinery, pp. 506–507 
  5. ^ http://www.computerworld.com/s/article/9164038/Microsoft_Don_t_press_F1_key_in_Windows_XP

External links