Cognitive dimensions
From Wikipedia, the free encyclopedia
Cognitive dimensions are design principles for notations and programming language design, described by researcher Thomas R.G. Green. The dimensions can be used to evaluate the usability of an existing notation, or as heuristics to guide the design of a new one. They provide a common vocabulary for discussing many factors in notation or programming language design.
[edit] List of the cognitive dimensions
[edit] Abstraction gradient
What are the minimum and maximum levels of abstraction exposed by the notation? Can details be encapsulated?
[edit] Closeness of mapping
How closely does the notation correspond to the problem world?
[edit] Consistency
After part of the notation has been learned, how much of the rest can be successfully guessed?
[edit] Diffuseness / terseness
How many symbols or how much space does the notation require to produce a certain result or express a meaning?
[edit] Error-proneness
Does the notation induce mistakes in the user?
[edit] Hard mental operations
How much hard mental processing lies at the notational level, rather than at the semantic level? Are there places where the user needs to resort to fingers or pencilled annotation to keep track of what’s happening?
[edit] Hidden dependencies
Are dependencies between entities in the notation visible or hidden? Is every dependency indicated in both directions? Does a change in one area of the notation lead to unexpected side-effects?
[edit] Juxtaposability
Can different parts of the notation be compared side-by-side at the same time?
[edit] Premature commitment
Are there strong constraints on the order with which tasks must be accomplished? Are there decisions that must be made before all the necessary information is available? Can those decisions be reversed or corrected later?
[edit] Progressive evaluation
How easy is it to evaluate and obtain feedback on an incomplete solution?
[edit] Role-expressiveness
How obvious is the role of each component of the notation in the solution as a whole?
[edit] Secondary notation and escape from formalism
Can the notation carry extra information by means not related to syntax, such as layout, colour, or other cues?
[edit] Viscosity
Are there in the notation any inherent barriers to change? How much effort is required to make a change to a program expressed in the notation?
This dimension can be further classified into the following types [1]:
- 'Knock-On viscosity': a change in the code violates internal constraints in the program, whose resolution may violate further internal constraints.
- 'Repetition viscosity': a single action within the user’s conceptual model requires many, repetitive device actions.
- 'Scope viscosity': a change in the size of the input data set requires changes to the program structure itself.
[edit] Visibility
How readily can required parts of the notation be identified, accessed and made visible?
[edit] Design Manoeuvres
A design manoeuvre is a change in the notation design to alter its position within a particular dimension. This usually results in a trade-off between dimensions. Increasing the usability of the notation in one dimension typically reduces its usability in another dimension. This reflects an assumption in the framework that there is no perfect interface and that trade-offs are a fundamental part of usability design.
An example of a design manoeuvre is reducing the viscosity of a notation by adding abstraction mechanisms. Stylesheets are an example of a notation where this trade-off is made.
[edit] References
T. R. G. Green and M. Petre. Usability analysis of visual programming environments: A `cognitive dimensions' framework. Journal of Visual Languages and Computing, 7:131--174, 1996.
[edit] See also
- Cognitive Walkthrough, another method for evaluating the usability of an interface.
