请输入您要查询的百科知识:

 

词条 Principle of least astonishment
释义

  1. Formulation

  2. Examples

  3. See also

  4. References

  5. External links

The principle of least astonishment (POLA; and variations of "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]

More generally, the principle means that a component of a system should behave in a way that most users will expect it to behave; the behavior should not astonish or surprise users.{{Citation needed|date=September 2016}}

Formulation

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

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 to keyboard shortcuts.[5] In more abstract settings like an API, the expectation that function or method names intuitively match their behavior is another example.[6] 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.[7]

Examples

A website could have an input field that focuses automatically after the page loads,[8] such as a search field (e.g. Google Custom Search), or the username field of a login form. Sites offering keyboard shortcuts often allow pressing {{Key press|?}} to see the available shortcuts. Examples include Gmail[9] and Jira.[10]

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. Malware may exploit user familiarity with regular shortcuts.[11]

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 defaults to base 8 for strings beginning with "0", causing developer confusion and software bugs.[12]

See also

  • DWIM (do what I mean)
  • Convention over configuration
  • Human interface guidelines
  • Look and feel
  • Occam's razor
  • WYSIWYG
  • List of software development philosophies

References

1. ^{{cite web |url=http://www.faqs.org/docs/artu/ch11s01.html |title=Applying the Rule of Least Surprise |work=The Art of Unix Programming |first=Eric Steven |last=Raymond |authorlink=Eric S. Raymond |page=20 |publisher=faqs.org |year=2003 |isbn=978-0-13-142901-7 |accessdate=2014-01-23}}
2. ^{{cite web|url=http://www.canonical.org/~kragen/tao-of-programming.html#book4|first=Geoffrey |last=James|authorlink=The Tao of Programming|isbn=0-931137-07-1|title=Law of Least Astonishment|work=The Tao of Programming|at=4.1|year=1987|accessdate=2014-02-05}}
3. ^{{cite web |url=http://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 |accessdate=2014-01-23}}
4. ^{{cite book|last1=Saltzer|first1=J. H.|last2=Kaashoek|first2=Frans|authorlink2 = 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}}
5. ^{{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}}
6. ^{{cite book |chapterurl=http://portal.acm.org/citation.cfm?id=1176622 |chapter=How to design a good API and why it matters |last=Bloch|first=Joshua |authorlink=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 }}
7. ^{{cite journal|url=http://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|format=PDF|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|authorlink=Mike Cowlishaw|accessdate=2014-01-23}}
8. ^{{cite web | url=https://developer.mozilla.org/en-US/docs/Web/HTML/Forms_in_HTML#The_autofocus_attribute | title=Forms in HTML | publisher=Mozilla | work=Mozilla Developers Network | accessdate=2013-07-27}}
9. ^{{cite web | url=https://support.google.com/mail/answer/6594 | title=Keyboard shortcuts for Gmail | author=Vivian | publisher=Google | date=2013-06-21 | accessdate=2013-07-27}}
10. ^{{cite web | url=https://confluence.atlassian.com/display/JIRA/Using+Keyboard+Shortcuts#UsingKeyboardShortcuts-AccessingtheKeyboardShortcutsDialogBox | title=Using Keyboard Shortcuts | publisher=Atlassian | accessdate=2013-07-27}}
11. ^{{cite news |url=http://www.computerworld.com/s/article/9164038/Microsoft_Don_t_press_F1_key_in_Windows_XP |title=Microsoft: Don't press F1 key in Windows XP |newspaper=Computerworld |first=G. |last=Keizer |date=1 March 2010}}
12. ^{{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}}

External links

  • Principle of Least Astonishment at Portland Pattern Repository

4 : Heuristics|Ergonomics|Human–computer interaction|Programming principles

随便看

 

开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。

 

Copyright © 2023 OENC.NET All Rights Reserved
京ICP备2021023879号 更新时间:2024/9/22 23:38:02