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

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
==Principle of Least Astonishment==
==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.
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.


Line 5: Line 5:
The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised: [2]  
The name of a function should reflect what it does. Otherwise, a user of the function will be unpleasantly surprised: [2]  


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


====Better:====  
====Better design:====  
  int multiply(int a, int b)
  int calculte_salary(int days, int perday)
  {
  {
   return a * b;
   return days * perday;
  }
  }


====Or:====  
As can be seen in the example above, in the first example the name of the functions and their functions 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.
int add(int a, int b)
 
{
There are many web pages that explains the
  return a + b;
 
}
 
== Principle of Least Astonishment in fields other than programming ==
 
== See Also ==


== 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<br>
[3] http://www.cs.arizona.edu/projects/sumatra/hallofshame <br>

Revision as of 04:40, 21 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 functions and their functions 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.

There are many web pages that explains the


Principle of Least Astonishment in fields other than programming

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