Principle of least astonishment - Wikipedia https://en.wikipedia.org/wiki/Principle_of_least_astonishment

最小惊讶原则

Principle of least astonishment

From Wikipedia, the free encyclopedia

The principle of least astonishment (POLA) (alternatively "principle/law/rule of least astonishment/surprise")^[1]^[2] applies to user interface and software design.^[3] A typical formulation of the principle, from 1984, is: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."^[4]

In general engineering design contexts, the principle means that a component of a system should behave in a way that users expect it to behave; that is, users should not be astonished by its behavior.^{[citation needed]}

[hide]

Formulation[edit]

A textbook formulation is: "People are part of the system. The design should match the user's experience, expectations, and mental models."^[5]

The choice of "least surprising" behavior can depend on the expected audience (for example, end users, programmers, or system administrators).^[1]

In more practical terms, the principle aims to leverage the pre-existing knowledge of users to minimize the learning curve, for instance by designing interfaces that borrow heavily from "functionally similar or analogous programs with which your users are likely to be familiar".^[1] 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,^[1] and widgets of Microsoft Windows programs are expected to follow certain conventions with respect tokeyboard shortcuts.^[6] In more abstract settings like an API, the expectation that function or method names intuitively match their behavior is another example.^[7] This practice also involves the application of sensible defaults.^[4]

When two elements of an interface conflict, or are ambiguous, the behavior 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.^[4]

Examples[edit]

A web site could declare an input that should autofocus when the page is loaded,^[8] such as a search field (e.g., Google.com), or the username field of a login form. Sites offering keyboard shortcutsoften allow pressing ? to see the available shortcuts. Examples include Gmail^[9] and Jira.^[10]

The F1 Function key in Windows operating systems is almost always for opening a help program associated with an application, and similarly for some of the Linux desktop environments. The corresponding key combination in Mac OS X is ⌘ Command+⇧ Shift+/. Users expect a help screen or similar help services popup when they press this key. Software binding this key to some other feature is likely to cause astonishment if no help appears. Malicious programs are known to exploit users' familiarity with regular shortcut keys.^[11]

In programming, a good example of this principle is the common ParseInteger(string, radix) function which exists in most languages and is used to convert a string to an integer value. The radix is usually an optional argument and assumed to be 10 (representing base 10). Other bases are usually supported (like binary or octal) but only when specified explicitly; when the radix argument is not specified, base 10 is assumed. Notably JavaScript did not originally adopt this behaviour, which resulted in developer confusion and software bugs.^[12]

References[edit]

^ Jump up to:^a ^b ^c ^d Raymond, Eric Steven (2003). "Applying the Rule of Least Surprise". The Art of Unix Programming. faqs.org. p. 20. ISBN 978-0-13-142901-7. Retrieved 2014-01-23.
Jump up^ James, Geoffrey (1987). "Law of Least Astonishment". The Tao of Programming. 4.1. ISBN 0-931137-07-1. Retrieved2014-02-05.
Jump up^ Seebach, Peter (2001-08-01). "The Principle of Least Astonishment". The cranky user. IBM DeveloperWorks. Retrieved 2014-01-23.
^ Jump up to:^a ^b ^c Cowlishaw, M. F. (1984). "The design of the REXX language" (PDF). IBM Systems Journal. 23 (4): 333.doi:10.1147/sj.234.0326. Retrieved 2014-01-23. Could there be a high astonishment factor associated with the new feature? If a feature is accidentally misapplied by the user and causes what appears to him to be an unpredictable result, that feature has a high astonishment factor and is therefore undesirable. If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.
Jump up^ Saltzer, J. H.; Kaashoek, Frans (2009). Principles of computer system design: an introduction. Morgan Kaufmann. p. 85. ISBN 978-0-12-374957-4.
Jump up^ Petroutsos, Evangelos (2010). Mastering Microsoft Visual Basic 2010. Wiley. p. 133. ISBN 978-0-470-53287-4.
Jump up^ Bloch, Joshua (2006). "How to design a good API and why it matters". Proceeding OOPSLA '06 Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications. Association for Computing Machinery. pp. 506–7. doi:10.1145/1176617.1176622.ISBN 1-59593-491-X.
Jump up^ "Forms in HTML". Mozilla Developers Network. Mozilla. Retrieved 2013-07-27.
Jump up^ Vivian (2013-06-21). "Keyboard shortcuts for Gmail". Google. Retrieved 2013-07-27.
Jump up^ "Using Keyboard Shortcuts". Atlassian. Retrieved2013-07-27.
Jump up^ Keizer, G. (1 March 2010). "Microsoft: Don't press F1 key in Windows XP". Computerworld.
Jump up^ "Why does the radix for JavaScript's parseInt default to 8?". Stack Overflow. 8 April 2011.

External links[edit]

Principle of Least Astonishment at Portland Pattern Repository

Categories: