CSC/ECE 517 Fall 2007/wiki2 9 A3: Difference between revisions
No edit summary |
|||
| Line 2: | Line 2: | ||
The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. It is a general principle in the design of all kinds of interfaces, not just software: “Do the least surprising thing”. It's a consequence of the fact that human beings can only pay attention to one thing at one time. Surprises in the interface focus that single locus of attention on the interface, rather than on the task where it belongs. The principle of least astonishment should not be interpreted as a call for mechanical conservatism in design. Novelty raises the cost of a user's first few interactions with an interface, but poor design will make the interface needlessly painful forever. As in other sorts of design, rules are not a substitute for good taste and engineering judgment. | The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. It is a general principle in the design of all kinds of interfaces, not just software: “Do the least surprising thing”. It's a consequence of the fact that human beings can only pay attention to one thing at one time. Surprises in the interface focus that single locus of attention on the interface, rather than on the task where it belongs. The principle of least astonishment should not be interpreted as a call for mechanical conservatism in design. Novelty raises the cost of a user's first few interactions with an interface, but poor design will make the interface needlessly painful forever. As in other sorts of design, rules are not a substitute for good taste and engineering judgment. | ||
===Example | ===Example=== | ||
The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised: | The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised: [2] | ||
====Bad:==== | ====Bad:==== | ||
| Line 22: | Line 22: | ||
return a + b; | return a + b; | ||
} | } | ||
== References == | == References == | ||
[1] http://www.faqs.org/docs/artu/ch11s01.html <br> | [1] http://www.faqs.org/docs/artu/ch11s01.html <br> | ||
[2] http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment | [2] http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment | ||
Revision as of 04:17, 21 October 2007
Principle of Least Astonishment
The Principle of Least Astonishment states that the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues. It is a general principle in the design of all kinds of interfaces, not just software: “Do the least surprising thing”. It's a consequence of the fact that human beings can only pay attention to one thing at one time. Surprises in the interface focus that single locus of attention on the interface, rather than on the task where it belongs. The principle of least astonishment should not be interpreted as a call for mechanical conservatism in design. Novelty raises the cost of a user's first few interactions with an interface, but poor design will make the interface needlessly painful forever. As in other sorts of design, rules are not a substitute for good taste and engineering judgment.
Example
The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised: [2]
Bad:
int multiply(int a, int b)
{
return a + b;
}
Better:
int multiply(int a, int b)
{
return a * b;
}
Or:
int add(int a, int b)
{
return a + b;
}
References
[1] http://www.faqs.org/docs/artu/ch11s01.html
[2] http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment