CSC/ECE 517 Fall 2007/wiki2 9 A3: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 25: Line 25:
* [http://daniel.gredler.net/2007/05/ HtmlUnit]
* [http://daniel.gredler.net/2007/05/ HtmlUnit]
* [http://www.gigascale.org/pubs/949.html Verification Through the Principle of Least Astonishment]
* [http://www.gigascale.org/pubs/949.html Verification Through the Principle of Least Astonishment]
<br>In addition to function naming, the principle applies to user interface design. Menu items and other controls should have an effect that is obvious based upon their text labels and placement relative to other controls.
* [http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3258158706 How to design Good APIs]


There are many web pages that explains the
<br>In addition to function naming, the principle applies to user interface design. Menu items and other controls should have an effect that is obvious based upon their text labels and placement relative to other controls.


== Principle of Least Astonishment in fields other than programming ==
== Principle of Least Astonishment in fields other than programming ==

Revision as of 04:01, 22 October 2007

What is '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 design:

int calculate_salary(int days, int perday)
{
  printf("The customer has worked for %d days and his salary per day is %d dollars", a, b);
}

Better design:

int calculte_salary(int days, int perday)
{
  return days * perday;
}

As can be seen in the example above, in the first example the name of the method and its functionality doenot match. Whereas a better way of coding is the second one in which the functionality and the method name are related.

Good examples can be found at the following websites:


In addition to function naming, the principle applies to user interface design. Menu items and other controls should have an effect that is obvious based upon their text labels and placement relative to other controls.

Principle of Least Astonishment in fields other than programming

Principle of Least Astonishment is a very common principle that is used in every day life.

Riding in Traffic

The principle of least astonishment can be translated as "ride predictably" i.e. riding in such a way that minimizes surprise. A complete article on it can be found at Riding in Traffic

See Also

References

[1] http://www.faqs.org/docs/artu/ch11s01.html
[2] http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment
[3] http://www.cs.arizona.edu/projects/sumatra/hallofshame
[4] http://www.ibm.com/developerworks/library/us-cranky10.html?dwzone=usability