Psychology Wiki

Assessment | Biopsychology | Comparative | Cognitive | Developmental | Language | Individual differences | Personality | Philosophy | Social |
Methods | Statistics | Clinical | Educational | Industrial | Professional items | World psychology |

Philosophy Index: Aesthetics · Epistemology · Ethics · Logic · Metaphysics · Consciousness · Philosophy of Language · Philosophy of Mind · Philosophy of Science · Social and Political philosophy · Philosophies · Philosophers · List of lists


{{PsyPersepctive]] 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 GUI 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]

Examples[]

  • A website may declare an input that should autofocus when the page is loaded,[5] such as a search field (e.g. Google.com), or the username field of a log in form.
  • Sites offering keyboard shortcuts often allow pressing ? to see the available shortcuts. Examples include Gmail[6] and JIRA.[7]
  • The Template:Keypress 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 Template:Keypress 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.[8] The corresponding key in Mac OS X is Template:Keypress.

See also[]

References[]

  1. (2009) Principles of computer system design: an introduction, Morgan Kaufmann.
  2. 2.0 2.1 2.2 Raymond, Eric S. (2004). The art of Unix programming, Addison-Wesley Professional.
  3. Petroutsos, Evangelos (2010). Mastering Microsoft Visual Basic 2010, 133, John Wiley and Sons.
  4. Bloch, Joshua (2006), How to design a good API and why it matters, Association for Computing Machinery, pp. 506–507, http://portal.acm.org/citation.cfm?id=1176622 
  5. Forms in HTML. Mozilla Developers Network. Mozilla. URL accessed on 27 July 2013.
  6. Keyboard shortcuts. Google. URL accessed on 27 July 2013.
  7. Using Keyboard Shortcuts. Atlassian. URL accessed on 27 July 2013.
  8. Microsoft: Don't press F1 key in Windows XP - Computerworld

External links[]

This page uses Creative Commons Licensed content from Wikipedia (view authors).