:principle of least astonishment

{{Redirect|Least surprise|the principle of least surprise in the Bayesian brain hypothesis|free energy principle|and|Bayesian approaches to brain function}}

In user interface design and software design,{{cite web |url=https://www.ibm.com/developerworks/web/library/us-cranky10/index.html |title=The Principle of Least Astonishment |work=The cranky user |first=Peter |last=Seebach |publisher=IBM DeveloperWorks |date=2001-08-01 |access-date=2014-01-23}}

the principle of least astonishment (POLA), also known as principle of least surprise,{{efn|Alternatively a law of least surprise or rule of least surprise.{{cite book |url=https://www.catb.org/~esr/writings/taoup/html/ch11s01.html |chapter=Applying the Rule of Least Surprise |title=The Art of Unix Programming |first=Eric Steven |last=Raymond |author-link=Eric S. Raymond |page=20 |publisher=faqs.org |year=2003 |isbn=978-0-13-142901-7 |access-date=2020-08-23}}{{cite book|url=https://www.canonical.org/~kragen/tao-of-programming.html#book4|first=Geoffrey |last=James|author-link=Geoffrey James (journalist)|isbn=0-931137-07-1|title=The Tao of Programming|at=4.1|year=1987|publisher=InfoBooks |access-date=2014-02-05}}}} 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 corollary 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.

Origin

An early reference to the "Law of Least Astonishment" appeared in the PL/I Bulletin in 1967 (PL/I is a programming language released by IBM in 1966).{{Cite journal |last=Southworth |first=R. N. |date=December 1967 |edition=PL/I Bulletin no. 5 |url=https://dl.acm.org/doi/10.1145/1139502.1139504 |journal=ACM SIGPLAN Notices |title=Proposal for PL/I Pseudo-name |language=en |volume=2 |issue=12 |page=6 |doi=10.1145/1139502.1139504 |issn=0362-1340 |s2cid=12180929 |editor-last1=Southworth |editor-first1=R. N.|url-access=subscription }} By the late 1960s, PL/I had become infamous for violating the law,{{cite book |last1=Date |first1=C. J. |title=Database Dreaming Volume I: Relational Writings Revised and Revived |date=11 February 2022 |publisher=Technics Publications |isbn=978-1-63462-984-3 |url=https://books.google.com/books?id=ISVeEAAAQBAJ&pg=PT47 |language=en|at=Ch.2, Reference 36|quote=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.'}} for example because, due to PL/I's precision conversion rules,{{cite book |last1=Tremblay |first1=Jean-Paul|last2=Sorenson|first2=Paul G. |title=The theory and practice of compiler writing |date=1985 |publisher=McGraw-Hill |location=New York |isbn=9780070651616|quote=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.}} the expressions {{code|25 + 1/3}} and {{code|1/3 + 25}} would either produce a fatal error, or, if errors were suppressed, 5.33333333333 instead of the correct 25.33333333333.{{cite journal |last1=Holt |first1=Richard C. |title=Teaching the fatal disease: (or) introductory computer programming using PL/I |journal=ACM SIGPLAN Notices |date=May 1973 |volume=8 |issue=5 |pages=8–23 |doi=10.1145/986948.986950|url=https://plg.uwaterloo.ca/~holt/papers/fatal_disease.html|quote=unfortunately, the expression '25 + 1/3' yields 5.33333333333333|url-access=subscription }}{{cite journal |last1=Golden |first1=Donald |title=A plea for friendly software |journal=ACM SIGSOFT Software Engineering Notes |date=October 1980 |volume=5 |issue=4 |pages=4–5 |doi=10.1145/1010884.1010885|doi-access=free|quote=Lest the non-PL/I programmer come to the erroneous conclusion that PL/I is without flaws, consider the following examples of PL/I's hostility. The rules for type conversion in PL/I are enough to give programmers ulcers. What other language would produce a fatal error when evaluating the expression (25 + 1/3)? (Just as bad, if you suppress the error checking, the result of evaluating the expression is 5.3333...)}}{{cite book |last1=Stansifer |first1=Ryan D. |url=https://archive.org/details/studyofprogrammi0000stan/page/122/mode/2up?q=astonishment |title=The Study of Programming Languages |date=1995 |publisher=Englewood Cliffs, N.J. : Prentice Hall |isbn=978-0-13-726936-5 |page=123 |url-access=registration|quote=PL/I is infamous in this regard, as it converts nearly any type into any other type, sometimes with surprising results. Consider the expression 1/3 + 25. In PL/I this expression has the value 5.33333333333. Why? One-third is computed to 15 digits of precision, 14 to the right of the decimal point. Then 25 is coerced to the same precision, losing the most significant digit 2! This does raise an error in PL/I, but the default is to ignore it. This first appeared in print in Barron 1968, where it is given as a violation of a folk law of language design: 'the law of least astonishment.'}}{{cite web |title=Enterprise PL/I for z/OS 5.3 - Language Reference |url=https://www.ibm.com/docs/en/SSY2V3_5.3.0/lr/lrm.pdf#page=110 |publisher=IBM |pages=57–62 |date=March 2021|quote=Consider the following expression: 25+1/3. The result of evaluating this expression is undefined and the FIXEDOVERFLOW condition is raised because FIXED division results in a value of maximum implementation defined precision. [...] The results of the two evaluations are reached as shown in Table 29.}}

The law appeared written out in full in 1972:

{{blockquote|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.{{cite journal |last1=Bergeron |first1=R.D. |last2=Gannon |first2=J.D. |last3=Shecter |first3=D.P. |last4=Tompa |first4=F.W. |last5=Dam |first5=A. Van |title=Systems Programming Languages |journal=Advances in Computers |date=1972 |volume=12 |pages=175–284 |doi=10.1016/s0065-2458(08)60510-0|isbn=9780120121120}}}}

Formulation

A textbook formulation is: "People are part of the system. The design should match the user's experience, expectations, and mental models."{{cite book|last1=Saltzer|first1=J. H.|last2=Kaashoek|first2=Frans|author-link2 = Frans Kaashoek | title=Principles of computer system design: an introduction |url=https://books.google.com/books?id=I-NOcVMGWSUC&pg=PA85|year=2009|publisher=Morgan Kaufmann|isbn=978-0-12-374957-4|page=85}}

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.{{cite book|last=Petroutsos|first=Evangelos|title=Mastering Microsoft Visual Basic 2010|url=https://books.google.com/books?id=x7LZTSVKZDoC&pg=PA133|year=2010|publisher=Wiley |isbn=978-0-470-53287-4|pages=133}} In more abstract settings like an API, the expectation that function or method names intuitively match their behavior is another example.{{cite book |chapter-url=https://portal.acm.org/citation.cfm?id=1176622 |chapter=How to design a good API and why it matters |last=Bloch|first=Joshua |author-link=Joshua Bloch |publisher=Association for Computing Machinery |year=2006 |pages=506–7 |doi=10.1145/1176617.1176622 |isbn=1-59593-491-X |title=Proceeding OOPSLA '06 Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications |s2cid=27230400 }} 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.{{cite journal

|url=https://www.cs.tufts.edu/~nr/cs257/archive/mike-cowlishaw/rexx.pdf |title=The design of the REXX language |first=M. F. |last=Cowlishaw |journal=IBM Systems Journal |volume=23 |issue=4 |year=1984|page=333|quote=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.

|doi=10.1147/sj.234.0326|author-link=Mike Cowlishaw|access-date=2014-01-23}}

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

Examples

Websites offering keyboard shortcuts often allow pressing {{Key press|?}} to see the available shortcuts. Examples include Gmail,{{cite web | url=https://support.google.com/mail/answer/6594 | title=Keyboard shortcuts for Gmail | author=Vivian | publisher=Google Inc. | date=2013-06-21 | access-date=2013-07-27}} YouTube,{{Cite web |title=Keyboard shortcuts for YouTube - YouTube Help |url=https://support.google.com/youtube/answer/7631406?hl=en |access-date=2022-08-16 |website=support.google.com}} and Jira.{{cite web | url=https://confluence.atlassian.com/display/JIRA/Using+Keyboard+Shortcuts#UsingKeyboardShortcuts-AccessingtheKeyboardShortcutsDialogBox | title=Using Keyboard Shortcuts | publisher=Atlassian | access-date=2013-07-27}}

In Windows operating systems and some desktop environments for Linux, the {{keypress|F1}} function key typically opens the help program for an application. A similar keyboard shortcut in macOS is {{keypress|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.{{cite news

| url= https://www.computerworld.com/article/2520194/microsoft--don-t-press-f1-key-in-windows-xp.html

| title= Microsoft: Don't press F1 key in Windows XP

| newspaper= Computerworld

| first= G.

| last= Keizer

| date= 1 March 2010

| access-date= 10 Nov 2019

}}

A programming language's standard library usually provides a function similar to the pseudocode ParseInteger(string, radix), which creates a machine-readable integer from a string of human-readable digits. The radix conventionally defaults to 10, meaning the string is interpreted as decimal (base 10). This function usually supports other bases, like binary (base 2) and octal (base 8), but only when they are specified explicitly. In a departure from this convention, JavaScript originally defaulted to base 8 for strings beginning with "0", causing developer confusion and software bugs.{{cite web |url=https://stackoverflow.com/questions/5600366/why-does-the-radix-for-javascripts-parseint-default-to-8 |title=Why does the radix for JavaScript's parseInt default to 8? |date=8 April 2011 |work=Stack Overflow}} This was discouraged in ECMAScript 3 and dropped in ECMAScript 5.{{citation |work=Mozilla Developer Network (MDN) |title=parseInt() |date=15 March 2024 |url=https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt |quote=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.}}

Some development communities like FreeBSD{{cite web | url=https://docs.freebsd.org/doc/4.6-RELEASE/usr/share/doc/faq/book.html#DEFINE-POLA | title=Frequently Asked Questions for FreeBSD 2.X, 3.X and 4.X | publisher=FreeBSD | date=2002-06-11 | access-date=2023-02-15}} use POLA as one of the guidelines for what makes an unsurprising user experience.