Principle of least astonishment
The principle of least astonishment (POLA), aka principle of least surprise (alternatively a law or rule), applies to user interface and software design. It proposes that a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users. The following is a formal statement of the principle: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."
The principle has been in use in relation to computer interaction since at least the 1970s. Although first formalized in the field of computer technology, the principle can be applied broadly in other fields. For example, in writing, a cross-reference to another part of the work or a hyperlink should be phrased in a way that accurately tells the reader what to expect. In a book about fishing for bass, "For recipes on how to cook your catch, see chapter 4" should not lead the reader to a chapter about bass fishing seasons in various locations.
An early reference to the "Law of Least Astonishment" appeared in the PL/I bulletin in 1967. By the late 1960's, PL/I had become infamous for violating the law, for example because, due to PL/I's precision conversion rules, the expression
1/3 + 25 resulted in
5.33333333333, rather than the expected
25.33333333333. The law appeared written out in full in 1972:
For those parts of the system which cannot be adjusted to the peculiarities of the user, the designers of a systems programming language should obey the “Law of Least Astonishment.” In short, this law states that every construct in the system should behave exactly as its syntax suggests. Widely accepted conventions should be followed whenever possible, and exceptions to previously established rules of the language should be minimal.
A textbook formulation is: "People are part of the system. The design should match the user's experience, expectations, and mental models."
The principle aims to leverage the 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". 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, and widgets of Microsoft Windows programs are expected to follow certain conventions with respect to keyboard shortcuts. In more abstract settings like an API, the expectation that function or method names intuitively match their behavior is another example. This practice also involves the application of sensible defaults.
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.
The choice of "least surprising" behavior can depend on the expected audience (for example, end users, programmers, or system administrators).
Websites offering keyboard shortcuts often allow pressing ? to see the available shortcuts. Examples include Gmail, YouTube, and Jira.
In Windows operating systems and some desktop environments for Linux, the F1 function key typically opens the help program for an application. A similar keyboard shortcut in macOS is ⌘ Command+⇧ Shift+/. Users expect a help window or context menu when they press the usual help shortcut key(s). Software that instead uses this shortcut for another feature is likely to cause astonishment if no help appears.
A programming language's standard library usually provides a function similar to the pseudocode
Some development communities like FreeBSD use POLA as one of the guidelines for what makes an unsuprising user experience.
- DWIM (do what I mean)
- Convention over configuration
- Human interface guidelines
- Look and feel
- Occam's razor
- List of software development philosophies
- User experience design
- ^ 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 2020-08-23.
- ^ James, Geoffrey (1987). Law of Least Astonishment. The Tao of Programming. 4.1. ISBN 0-931137-07-1. Retrieved 2014-02-05.
- ^ Seebach, Peter (2001-08-01). "The Principle of Least Astonishment". The cranky user. IBM DeveloperWorks. Retrieved 2014-01-23.
- ^ 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.
- ^ "Default Batch Priority - User Survey". Computing Center Newsletter. Michigan: University of Michigan. 1978-04-05. Retrieved 2020-08-25.
- ^ Holmes, W. N. (December 1967). "Proposal for PL/I Pseudo-name". In Southworth, R. N. (ed.). PL/I bulletin no. 5. ACM SIGPLAN Notices. Vol. 2. p. 6. doi:10.1145/1139502.1139504. S2CID 12180929.
- ^ Barron, David William (1968). Comparative programming languages. American Elsevier, NY.
- ^ Stansifer, Ryan D. (1995). The study of programming languages. Englewood Cliffs, N.J. : Prentice Hall. p. 123. ISBN 978-0-13-726936-5.
- ^ Tremblay, Jean-Paul; Sorenson, Paul G. (1985). The theory and practice of compiler writing. New York: McGraw-Hill. ISBN 9780070651616.
PL/I is the major bad example here; it is strewn with constructs which do not do what the programmer thinks, as exemplified with FIXED division.
- ^ Date, C. J. (11 February 2022). Database Dreaming Volume I: Relational Writings Revised and Revived. Technics Publications. Ch.2, Reference 36. ISBN 978-1-63462-984-3.
As a friend of mine once remarked to me—this must have been sometime in the late 1960s—whatever else you might say about it, there's one thing that PL/I is most definitely not, and that's "the language of least astonishment."
- ^ Bergeron, R.D.; Gannon, J.D.; Shecter, D.P.; Tompa, F.W.; Dam, A. Van (1972). "Systems Programming Languages". Advances in Computers. 12: 175–284. doi:10.1016/s0065-2458(08)60510-0. ISBN 9780120121120.
- ^ Saltzer, J. H.; Kaashoek, Frans (2009). Principles of computer system design: an introduction. Morgan Kaufmann. p. 85. ISBN 978-0-12-374957-4.
- ^ Petroutsos, Evangelos (2010). Mastering Microsoft Visual Basic 2010. Wiley. p. 133. ISBN 978-0-470-53287-4.
- ^ 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. S2CID 27230400.
- ^ Vivian (2013-06-21). "Keyboard shortcuts for Gmail". Google Inc. Retrieved 2013-07-27.
- ^ "Keyboard shortcuts for YouTube - YouTube Help". support.google.com. Retrieved 2022-08-16.
- ^ "Using Keyboard Shortcuts". Atlassian. Retrieved 2013-07-27.
- ^ Keizer, G. (1 March 2010). "Microsoft: Don't press F1 key in Windows XP". Computerworld. Retrieved 10 Nov 2019.
- ^ "parseInt()", Mozilla Developer Network (MDN),
If the input string begins with "0" (a zero), radix is assumed to be 8 (octal) or 10 (decimal). Exactly which radix is chosen is implementation-dependent. ECMAScript 5 clarifies that 10 (decimal) should be used, but not all browsers support this yet.
- ^ "Frequently Asked Questions for FreeBSD 2.X, 3.X and 4.X". FreeBSD. 2002-06-11. Retrieved 2023-02-15.