Hanli Wang ( m · 2018. 2. 27. · Hanli Wang (˝¢m) Email: [email protected] Department of Computer Science and Technology, Tongji University. Design Rules Table of Contents

Design Rules

Design Rules

Hanli Wang (�¢m)

Email: [email protected]

Department of Computer Science and Technology,Tongji University

Design Rules

Table of ContentsChapter overview

Design rule types

Principles to support usabilityLearnabilityFlexibilityRobustness

Standards

Guidelines

Golden rules and heuristicsShneiderman’s eight golden rulesNorman’s seven principlesOther design heuristics

HCI patterns

Summary

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usability

I goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usability

I offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelines

I provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristics

I summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patterns

I capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Chapter overview

Chapter overview

I Designing for maximum usabilityI goal of interactive systems design

I Principles of usabilityI offers a general understanding

I Standards and guidelinesI provides direction for design

I ‘golden rules’ or heuristicsI summarize essential characteristics of good design

I Design patternsI capture and reuse design knowledge

Design Rules

Design rule types

Types of design rules

I Design rules:

I a designer can follow in order to increase the usability of theeventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions:

rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority:

whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality:

whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules:

principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelines

I Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles:

abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authority

I Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards:

specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authority

I Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines:

more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules

I Design rules:I a designer can follow in order to increase the usability of the

eventual software product

I Classify design rules along two dimensions: rule’s authorityand generality

I By authority: whether or not the rule must be followed indesign or whether it is only suggested

I By generality: whether the rule can be applied to manysituations or focussed on a more limited application situation

I Rules also vary in level of abstraction, with some abstractiveand others being quite specific

I Type of design rules: principles, standards, guidelinesI Principles: abstract, high generality, low authorityI Standards: specific, limited applications, high authorityI Guidelines: more general application, lower authority

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other

=⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Design rule types

Types of design rules (Cont’d)

I Often a set of design rules conflictwith each other =⇒ impossible toadhere to all of them

I The theory underlying rules helpunderstand the trade-off

I More general a rule is, greater thelikelihood that it conflicts with othersand greater need for the designer tounderstand the theory behind it

I Design rules restrict the space ofdesign options, preventing a designerfrom pursuing unstable options

I desired if adopted in early stages ofdesign cycle

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performanceI Flexibility - the multiplicity of ways in which the user and

system exchange informationI Robustness - the level of support provided to the user in

determining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:

I Learnability - the ease with which new users can begineffective interaction and achieve maximal performance

I Flexibility - the multiplicity of ways in which the user andsystem exchange information

I Robustness - the level of support provided to the user indetermining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability

- the ease with which new users can begineffective interaction and achieve maximal performance

I Flexibility - the multiplicity of ways in which the user andsystem exchange information

I Robustness - the level of support provided to the user indetermining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performance

I Flexibility - the multiplicity of ways in which the user andsystem exchange information

I Robustness - the level of support provided to the user indetermining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performanceI Flexibility

- the multiplicity of ways in which the user andsystem exchange information

I Robustness - the level of support provided to the user indetermining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performanceI Flexibility - the multiplicity of ways in which the user and

system exchange information

I Robustness - the level of support provided to the user indetermining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performanceI Flexibility - the multiplicity of ways in which the user and

system exchange informationI Robustness

- the level of support provided to the user indetermining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performanceI Flexibility - the multiplicity of ways in which the user and

system exchange informationI Robustness - the level of support provided to the user in

determining successful achievement and assessment of goals

Design Rules

Principles to support usability

Principle categories

I Principles: most abstract design rules, high generality, lowauthority

I Three main categories of principles:I Learnability - the ease with which new users can begin

effective interaction and achieve maximal performanceI Flexibility - the multiplicity of ways in which the user and

system exchange informationI Robustness - the level of support provided to the user in

determining successful achievement and assessment of goals

Design Rules

Principles to support usability

Learnability

LearnabilityLearnability concerns the features of the interactive system thatallow novice users to understand how to use it initially and thenhow to attain a maximal level of performance.

Design Rules

Principles to support usability

Learnability

LearnabilityLearnability concerns the features of the interactive system thatallow novice users to understand how to use it initially and thenhow to attain a maximal level of performance.

Design Rules

Principles to support usability

Learnability

LearnabilityLearnability concerns the features of the interactive system thatallow novice users to understand how to use it initially and thenhow to attain a maximal level of performance.

Design Rules

Principles to support usability

Learnability

Predictability

I Definition:

support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility

- refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recall

I without it, the user have to remember when he can performthe operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability

I Definition: support for the user to determine the effect offuture action based on past interaction history

I Related principles: operation visibility - refers to how the useris shown the availability of operations that can be performednext

I if an operation can be performed, then there may be someperceivable indication of this to the user

I supporting the superiority in humans of recognition over recallI without it, the user have to remember when he can perform

the operation and when he cannot

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package.

You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit.

You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing

by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject

and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it.

Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is?

Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects,

especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap?

Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screen

indicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object

that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group?

Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this example

depends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage

is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine

what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Predictability example

Imagine you have created a complex picture using a mouse-drivengraphical drawing package. You leave the picture for a few daysand then go back to change it around a bit. You are allowed toselect certain objects for editing by positioning the mouse over theobject and clicking a mouse button to highlight it. Can you tellwhat the set of selectable objects is? Can you determine whicharea of the screen belongs to which of these objects, especially ifsome objects overlap? Does the visual image on the screenindicate what objects form a compound object that can only beselected as a group? Predictability of selection in this exampledepends on how much of the history of the creation of the visualimage is necessary in order for you to determine what happenswhen you click on the mouse button.

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition:

support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by userI honesty relates to the ability of UI to provide an observable

and informative account of changeI in the best of circumstances, this notification can come

immediately, requiring no further interaction initiated by userI at the very least, the notification should appear eventually,

after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by userI honesty relates to the ability of UI to provide an observable

and informative account of changeI in the best of circumstances, this notification can come

immediately, requiring no further interaction initiated by userI at the very least, the notification should appear eventually,

after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honesty

I when an operation changes internal state, it is important thatthe change is seen by user

I honesty relates to the ability of UI to provide an observableand informative account of change

I in the best of circumstances, this notification can comeimmediately, requiring no further interaction initiated by user

I at the very least, the notification should appear eventually,after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by user

I honesty relates to the ability of UI to provide an observableand informative account of change

I in the best of circumstances, this notification can comeimmediately, requiring no further interaction initiated by user

I at the very least, the notification should appear eventually,after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by userI honesty relates to the ability of UI to provide an observable

and informative account of change

I in the best of circumstances, this notification can comeimmediately, requiring no further interaction initiated by user

I at the very least, the notification should appear eventually,after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by userI honesty relates to the ability of UI to provide an observable

and informative account of changeI in the best of circumstances, this notification can come

immediately, requiring no further interaction initiated by user

I at the very least, the notification should appear eventually,after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by userI honesty relates to the ability of UI to provide an observable

and informative account of changeI in the best of circumstances, this notification can come

immediately, requiring no further interaction initiated by userI at the very least, the notification should appear eventually,

after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability

I Definition: support for the user to assess the effect of pastoperations on the current state

I Related principles: immediate/eventual honestyI when an operation changes internal state, it is important that

the change is seen by userI honesty relates to the ability of UI to provide an observable

and informative account of changeI in the best of circumstances, this notification can come

immediately, requiring no further interaction initiated by userI at the very least, the notification should appear eventually,

after explicit user directives to make the change observable

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality

can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system.

You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system

you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system,

you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory

and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory

in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved

(in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact,

you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory

to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied).

In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface,

a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file

is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory

where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible

(assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents).

In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case,

the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation.

The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples

A good example of the distinction between immediacy and eventuality can be seen in

the comparison between command language interfaces and visual desktop interfaces

for a file management system. You have moved a file from one directory to another.

The principle of honesty implies that after moving the file to its new location in the

file system you are then able to determine its new whereabouts. In a command

language system, you would typically have to remember the destination directory and

then ask to see the contents of that directory in order to verify that the file has been

moved (in fact, you would also have to check that the file is no longer in its original

directory to determine that it has been moved and not copied). In a visual desktop

interface, a visual representation (or icon) of the file is dragged from its original

directory and placed in its destination directory where it remains visible (assuming the

destination folder is selected to reveal its contents). In this case, the user need not

expend any more effort to assess the result of the move operation. The visual desktop

is immediately honest.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system,

it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change.

In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder.

New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users)

would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly

and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ).

They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition.

Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later,

they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around.

The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation

was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation.

Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

The problem with eventual honesty is that the user must know to look for the change.

In a situation in which the user is learning a new interactive system, it is likely that he

will not know to look for change. In earlier versions of the Apple Macintosh Finder,

performing the operation to create a new folder in another folder did not necessarily

result in that new folder’s icon being visible in the original folder. New users (and even

some experienced users) would often think that they had not issued the new folder

operations correctly and would ask for another new folder (and another, and another,

· · · ). They would not know to search through the entire open folder for the latest

addition. Then several minutes (hours, days) later, they would notice that there were

a number of empty and untitled folders lying around. The eventual (accidental)

discovery of the change brought about by the new folder operation was then difficult

to associate to that operation. Fortunately, this problem was addressed in Version 7 of

the Finder.

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty,

let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor.

Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document

(e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error).

In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading,

you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’.

The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution

without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou.

Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Synthesizability examples (Cont’d)

As another example of the benefit of immediate over eventual honesty, let us examinea typical global search and replace function in a word processor. Imagine you havenoticed in the past a tendency to repeat words in a document (e.g., you type ‘the the’without noticing the error). In an attempt to automate your proofreading, you decideto replace globally all occurrences of ‘the the’ with ‘the’. The typical global searchand replace function performs this substitution without revealing the changes made toyou. Suddenly, a careless typing error is transformed into unacceptable grammar asthe sentence

‘We will prove the theorem holds as a corollary of the following lemma.’

is transformed to

‘We will prove theorem holds as a corollary of the following lemma.’

Design Rules

Principles to support usability

Learnability

Familiarity

I Definition:

the extent to which a user’s knowledge andexperience in other real-world or computer-based domains canbe applied when interacting with a new system

I Related principles: guessability, affordanceI Guessability: how the system is first perceived and whether the

user can determine how to initiate any interactionI Affordances: intrinsic properties of any visual object that

suggest to us how they can be manipulated (the appearance ofthe object stimulates a familiarity with its behavior)

Design Rules

Principles to support usability

Learnability

Familiarity

I Definition: the extent to which a user’s knowledge andexperience in other real-world or computer-based domains canbe applied when interacting with a new system

I Related principles: guessability, affordanceI Guessability: how the system is first perceived and whether the

user can determine how to initiate any interactionI Affordances: intrinsic properties of any visual object that

suggest to us how they can be manipulated (the appearance ofthe object stimulates a familiarity with its behavior)

Design Rules

Principles to support usability

Learnability

Familiarity

I Definition: the extent to which a user’s knowledge andexperience in other real-world or computer-based domains canbe applied when interacting with a new system

I Related principles: guessability, affordance

I Guessability: how the system is first perceived and whether theuser can determine how to initiate any interaction

I Affordances: intrinsic properties of any visual object thatsuggest to us how they can be manipulated (the appearance ofthe object stimulates a familiarity with its behavior)

Design Rules

Principles to support usability

Learnability

Familiarity

I Definition: the extent to which a user’s knowledge andexperience in other real-world or computer-based domains canbe applied when interacting with a new system

I Related principles: guessability, affordanceI Guessability: how the system is first perceived and whether the

user can determine how to initiate any interaction

I Affordances: intrinsic properties of any visual object thatsuggest to us how they can be manipulated (the appearance ofthe object stimulates a familiarity with its behavior)

Design Rules

Principles to support usability

Learnability

Familiarity

I Definition: the extent to which a user’s knowledge andexperience in other real-world or computer-based domains canbe applied when interacting with a new system

I Related principles: guessability, affordanceI Guessability: how the system is first perceived and whether the

user can determine how to initiate any interactionI Affordances: intrinsic properties of any visual object that

suggest to us how they can be manipulated (the appearance ofthe object stimulates a familiarity with its behavior)

Design Rules

Principles to support usability

Learnability

Familiarity

I Definition: the extent to which a user’s knowledge andexperience in other real-world or computer-based domains canbe applied when interacting with a new system

I Related principles: guessability, affordanceI Guessability: how the system is first perceived and whether the

user can determine how to initiate any interactionI Affordances: intrinsic properties of any visual object that

suggest to us how they can be manipulated (the appearance ofthe object stimulates a familiarity with its behavior)

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced

the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter

was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those

who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter.

Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system.

In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case,

we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived

and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction.

An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor,

such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above,

is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Guessability example

When word processors were originally introduced the analogy between the word

processor and a typewriter was intended to make the new technology more

immediately accessible to those who had little experience with the former but a lot of

experience with the latter. Familiarity has to do with a user’s first impression of the

system. In this case, we are interested in how the system is first perceived and

whether the user can determine how to initiate any interaction. An advantage of a

metaphor, such as the typewriter metaphor for word processing described above, is

precisely captured by familiarity.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest

how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed. In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse). Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed. In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse). Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed.

In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse). Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed. In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse). Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed. In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse).

Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed. In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse). Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Affordances example

The shape of a door handle can suggest how it should be manipulated to open a door,

and a key on a keyboard suggests to us that it can be pushed. In the design of a

graphical user interface, it is implied that a soft button used in a form’s interface

suggests it should be pushed (though it does not suggest how it is to be pushed via

the mouse). Effective use of the affordances that exist for interface objects can

enhance the familiarity of the interactive system.

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition:

support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g.,

in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse,

we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle.

A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications

can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems

thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Generalizability

I Definition: support for the user to extend knowledge ofspecific interaction within and across applications to othersimilar situations

I Applied to situations in which the user wants to applyknowledge that helps achieve one particular goal to anothersituation where the goal is in some way similar

I Occur within a single application or across a variety ofapplications

I E.g., in a graphical drawing package that draws a circle as aconstrained form of ellipse, we would want the user togeneralize that a square can be drawn as a constrainedrectangle. A good example of generalizability across a varietyof applications can be seen in multi-windowing systems thatattempt to provide cut/paste/copy operations to allapplications in the same way.

I Generalizability within an application can be maximized byany conscientious designer

Design Rules

Principles to support usability

Learnability

Consistency

I Definition:

likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Learnability

Consistency

I Definition: likeness in input/output behavior arising fromsimilar situations or similar task objectives

I Probably the most widely mentioned principle in UI design

I Consistency must be applied relative to something, e.g., incommand naming, or consistency in command/argumentinvocation

I Many other principles can be ‘reduced’ to qualified instancesof consistency

I Familiarity as consistency with respect to past real-worldexperience

I Generalizability as consistency with respect to experience withthe same system or set of applications on the same platform

Design Rules

Principles to support usability

Flexibility

FlexibilityFlexibility refers to the multiplicity of ways in which the end-userand the system exchange information.

Design Rules

Principles to support usability

Flexibility

FlexibilityFlexibility refers to the multiplicity of ways in which the end-userand the system exchange information.

Design Rules

Principles to support usability

Flexibility

FlexibilityFlexibility refers to the multiplicity of ways in which the end-userand the system exchange information.

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types:

system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptive

I System pre-emptive: the system initiates all dialog, the usersimply responds to requests for information

I User pre-emptive: the user may be entirely free to initiate anyaction towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive:

the system initiates all dialog, the usersimply responds to requests for information

I User pre-emptive: the user may be entirely free to initiate anyaction towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for information

I User pre-emptive: the user may be entirely free to initiate anyaction towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive:

the user may be entirely free to initiate anyaction towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g.,

in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor

it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text

that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.

For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons,

it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Dialog initiative

I When considering the interaction between user and system asa dialog between partners, it is important to consider whichpartner has the initiative in the conversation.

I Two types: system pre-emptive or user pre-emptiveI System pre-emptive: the system initiates all dialog, the user

simply responds to requests for informationI User pre-emptive: the user may be entirely free to initiate any

action towards the system

I In general, we want to maximize the user’s ability to pre-emptthe system and minimize the system’s ability to pre-empt theuser

I Although a system pre-emptive dialog is not desirable ingeneral, some situations may require it

I e.g., in a cooperative editor it would be impolite for you toerase a paragraph of text that your partner is currently editing.For safety reasons, it may be necessary to prohibit the userfrom the ‘freedom’ to do potentially serious damage

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a time

I Concurrent multi-threading allows simultaneouscommunication of information pertaining to separate tasks

I Interleaved multi-threading permits a temporal overlapbetween separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasks

I Interleaved multi-threading permits a temporal overlapbetween separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threading

I Separate modalities (or channels of communication) arecombined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression,

e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,

e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,

e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading,

e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Multi-threadingI Ability of the system to support user interaction pertaining to

more than one task at a timeI Concurrent multi-threading allows simultaneous

communication of information pertaining to separate tasksI Interleaved multi-threading permits a temporal overlap

between separate tasks, but stipulates that at any giveninstant the dialog is restricted to a single task

I Multi-modality of a dialog is related to multi-threadingI Separate modalities (or channels of communication) are

combined to form a single input or output expression, e.g., toopen a window the user can choose between a double click onan icon, a keyboard shortcut, etc.

I A single expression can be formed by a mixing of channels,e.g., error warnings which usually contain a textual messageaccompanied by an audible beep

I A windowing system naturally supports a multi-threadeddialog interleaved amongst a number of overlapping tasks,e.g., text editing in one window, file management in another,a telephone directory in another and electronic mail in yetanother

I A multi-modal dialog can allow for concurrentmulti-threading, e.g., you are editing a program when a beepindicates that a new electronic mail message has arrived

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example.

Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary,

you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spelling

by reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper

and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them.

This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation,

as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings.

It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable,

however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,

as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly,

nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words.

In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user.

The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident,

e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft,

there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed

that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all.

Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.

However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency,

it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

Task migratabilityI The ability to pass control for the execution of a given task so

that it becomes either internalized by the user or the systemor shared between them

I A task that is internal to one can become internal to the otheror shared between the two partners

I E.g., Take spell-checking a paper as an example. Equippedwith a dictionary, you are perfectly able to check your spellingby reading through the entire paper and correcting mistakesas you spot them. This mundane task is perfectly suited toautomation, as the computer can check words against its ownlist of acceptable spellings. It is not desirable, however, toleave this task completely to the discretion of the computer,as most computerized dictionaries do not handle proper namescorrectly, nor can they distinguish between correct andunintentional duplications of words. In those cases, the task ishanded over to the user. The spell-check is best performed insuch a cooperative way.

I In safety-critical applications, task migratability can decreasethe likelihood of an accident, e.g., on the flight deck of anaircraft, there are so many control tasks that must beperformed that a pilot would be overwhelmed if he had toperform them all. Therefore, mundane control of the aircraft’sposition within its flight envelope is greatly automated.However, in the event of an emergency, it must be possible totransfer flying controls easily and seamlessly from the systemto the pilot.

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each other

I e.g, considering the form of an input expression to determinethe margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering,

e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object

can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important

or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends;

even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is output

I output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as input

I e.g., in spreadsheet programs, the user fills in some cells andthe system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g.,

in spreadsheet programs, the user fills in some cells andthe system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs,

the user fills in some cells andthe system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells

andthe system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells.

Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells,

the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

SubstitutivityI Allowing equivalent values of input and output to be

arbitrarily substituted for each otherI e.g, considering the form of an input expression to determine

the margin for a letter, you may want to enter the value ineither inches or centimeters

I Input substitutivity contributes towards flexibility by allowingthe user to choose whichever form best suits the needs of themoment

I Substitutivity also relates to output, or the system’s renderingof state information

I Representation multiplicity illustrates flexibility for staterendering, e.g., the temperature of a physical object can bepresented as a digital thermometer if the actual numericalvalue is important or as a graph if it is only important tonotice trends; even be desirable to make these representationssimultaneously

I Equal opportunity blurs the distinction between input andoutput at the interface

I user has the choice of what is input and what is outputI output can be reused as inputI e.g., in spreadsheet programs, the user fills in some cells and

the system automatically determines the values attributed tosome other cells. Conversely, if the user enters values for thoseother cells, the system would compute the values for the firstones

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the system

I Two types of modifications:I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptability

I system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Flexibility

CustomizabilityI Modifiability of the user interface by the user or the systemI Two types of modifications:

I user-initiated modifications: adaptabilityI system-initiated modification: adaptivity

I Adaptability refers to the user’s ability to adjust the form ofinput and output

I customization could be very limited, with the user only allowedto adjust the position of soft buttons on the screen or redefinecommand names

I user’s power can be increased by allowing the definition ofmacros to speed up the articulation or with programminglanguage capabilities

I Adaptivity is automatic customization of the user interface bythe system

I decisions for adaptation can be based on user expertise orobserved repetition of certain task sequences

I The distinction between adaptivity and adaptability is that theuser plays an explicit role in adaptability, whereas his role inan adaptive interface is more implicit

Design Rules

Principles to support usability

Robustness

RobustnessA user is engaged with a computer in order to achieve some set ofgoals. The robustness of that interaction covers features thatsupport the successful achievement and assessment of the goals.

Design Rules

Principles to support usability

Robustness

RobustnessA user is engaged with a computer in order to achieve some set ofgoals. The robustness of that interaction covers features thatsupport the successful achievement and assessment of the goals.

Design Rules

Principles to support usability

Robustness

RobustnessA user is engaged with a computer in order to achieve some set ofgoals. The robustness of that interaction covers features thatsupport the successful achievement and assessment of the goals.

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representation

I Observability can be discussed through five other principles:browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recall

I e.g., a suggested response to a question can be recognized ascorrect instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled

item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanism

I Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

ObservabilityI Ability of the user to evaluate the internal state of the system

from its perceivable representationI Observability can be discussed through five other principles:

browsability, defaults, reachability, persistence and operationvisibility

I Browsability allows the user to explore the current internalstate of the system via the limited view provided at theinterface

I The availability of defaults can assist the user by passive recallI e.g., a suggested response to a question can be recognized as

correct instead of recalled item reducing the number ofphysical actions

I a kind of error prevention mechanismI Static and dynamic defaults

I Reachability refers to the possibility of navigation through theobservable system states

I whether the user can navigate from any given state to anyother state

I affecting the recoverability of the system

I Persistence deals with the duration of the effect of acommunication act and the ability of the user to make use ofthat effect

I The effect of vocal communication does not persist except inthe memory of the receiver

I Visual communication can remain as an object which the usercan subsequently manipulate long after the act of presentation

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognized

I Two recovery directions: forward or backwardI Forward error recovery involves the acceptance of the current

state and negotiation from that state towards the desired stateI Backward error recovery is an attempt to undo the effects of

previous interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the user

I When performed by the system, recoverability is connected tothe notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doable

I e.g., if it is difficult to recover files which have been deleted inan operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

RecoverabilityI Ability of the user to take corrective action once an error has

been recognizedI Two recovery directions: forward or backward

I Forward error recovery involves the acceptance of the currentstate and negotiation from that state towards the desired state

I Backward error recovery is an attempt to undo the effects ofprevious interaction in order to return to a prior state beforeproceeding

I Recovery can be initiated by the system or by the userI When performed by the system, recoverability is connected to

the notions of fault tolerance, safety, reliability anddependability

I When initiated by the user, it is important that it determinesthe intent of the user’s recovery actions; that is, whether hedesires forward (negotiation) or backward (using undo/redoactions) corrective action

I Linked to reachability because we want to avoid blocking theuser from getting to a desired state from some otherundesired state

I Commensurate effort states that if it is difficult to undo agiven effect on the state, then it should have been difficult todo in the first place

I easily undone actions should be easily doableI e.g., if it is difficult to recover files which have been deleted in

an operating system, then it should be difficult to remove them

Design Rules

Principles to support usability

Robustness

Responsiveness

I How the user perceives the rate of communication with thesystem

I Response time is generally defined as the duration of timeneeded by the system to express state changes to the user

I In general, short durations and instantaneous response timesare desirable

I Instantaneous means that the user perceives system reactionsas immediate

I Response time stability covers the invariance of the durationfor identical or similar computational resources

Design Rules

Principles to support usability

Robustness

Responsiveness

I How the user perceives the rate of communication with thesystem

I Response time is generally defined as the duration of timeneeded by the system to express state changes to the user

I In general, short durations and instantaneous response timesare desirable

I Instantaneous means that the user perceives system reactionsas immediate

I Response time stability covers the invariance of the durationfor identical or similar computational resources

Design Rules

Principles to support usability

Robustness

Responsiveness

I How the user perceives the rate of communication with thesystem

I Response time is generally defined as the duration of timeneeded by the system to express state changes to the user

I In general, short durations and instantaneous response timesare desirable

I Instantaneous means that the user perceives system reactionsas immediate

I Response time stability covers the invariance of the durationfor identical or similar computational resources

Design Rules

Principles to support usability

Robustness

Responsiveness

I How the user perceives the rate of communication with thesystem

I Response time is generally defined as the duration of timeneeded by the system to express state changes to the user

I In general, short durations and instantaneous response timesare desirable

I Instantaneous means that the user perceives system reactionsas immediate

I Response time stability covers the invariance of the durationfor identical or similar computational resources

Design Rules

Principles to support usability

Robustness

Responsiveness

I How the user perceives the rate of communication with thesystem

I Response time is generally defined as the duration of timeneeded by the system to express state changes to the user

I In general, short durations and instantaneous response timesare desirable

I Instantaneous means that the user perceives system reactionsas immediate

I Response time stability covers the invariance of the durationfor identical or similar computational resources

Design Rules

Principles to support usability

Robustness

Responsiveness

I How the user perceives the rate of communication with thesystem

I Response time is generally defined as the duration of timeneeded by the system to express state changes to the user

I In general, short durations and instantaneous response timesare desirable

I Instantaneous means that the user perceives system reactionsas immediate

I Response time stability covers the invariance of the durationfor identical or similar computational resources

Design Rules

Principles to support usability

Robustness

Task conformance

I The degree to which the system services support all of thetasks the user wishes to perform and in the way that the userunderstands them

I Task completeness addresses the coverage issue

I Task adequacy addresses the user’s understanding of the tasks

Design Rules

Principles to support usability

Robustness

Task conformance

I The degree to which the system services support all of thetasks the user wishes to perform and in the way that the userunderstands them

I Task completeness addresses the coverage issue

I Task adequacy addresses the user’s understanding of the tasks

Design Rules

Principles to support usability

Robustness

Task conformance

I The degree to which the system services support all of thetasks the user wishes to perform and in the way that the userunderstands them

I Task completeness addresses the coverage issue

I Task adequacy addresses the user’s understanding of the tasks

Design Rules

Principles to support usability

Robustness

Task conformance

I The degree to which the system services support all of thetasks the user wishes to perform and in the way that the userunderstands them

I Task completeness addresses the coverage issue

I Task adequacy addresses the user’s understanding of the tasks

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theory

I Standards for hardware are based on an understanding ofphysiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I Change

I Hardware is more difficult and expensive to change thansoftware

I Requirements changes for hardware do not occur as frequentlyas for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

software

I Requirements changes for hardware do not occur as frequentlyas for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

StandardsI Standards for interactive system design are usually set by

national or international bodies to ensure compliance with aset of design rules by a large community

I Standards can apply specifically to either the hardware or thesoftware used to build the interactive system

I Different characteristics between hardware and software,which affect the utility of design standards applied to them:

I Underlying theoryI Standards for hardware are based on an understanding of

physiology or ergonomics/human factors, the results of whichare relatively well known, fixed and readily adaptable to designof the hardware

I Software standards are based on theories from psychology orcognitive science, which are less well formed, still evolving andnot very easy to interpret in the language of software design

I Standards for hardware can directly relate to a hardwarespecification and still reflect the underlying theory, whereassoftware standards would have to be more vaguely worded

I ChangeI Hardware is more difficult and expensive to change than

softwareI Requirements changes for hardware do not occur as frequently

as for software

I The strength of a standard lies in its ability to force largecommunities to abide

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is given

I Usability: the effectiveness, efficiency and satisfaction withwhich specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability:

the effectiveness, efficiency and satisfaction withwhich specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness:

the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency:

the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction:

the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Standards

ISO standard 9241

I ISO standard 9241, pertaining to usability specification,applies equally to both hardware and software design.

I The following definition of usability is givenI Usability: the effectiveness, efficiency and satisfaction with

which specified users achieve specified goals in particularenvironments

I Effectiveness: the accuracy and completeness with whichspecified users can achieve specified goals in particularenvironments

I Efficiency: the resources expended in relation to the accuracyand completeness of goals achieved

I Satisfaction: the comfort and acceptability of the work systemto its users and other people affected by its use

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelines

I the incompleteness of theories underlying the design ofinteractive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples;

the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Guidelines

GuidelinesI Majority of design rules for interactive systems are suggestive

and more general guidelinesI the incompleteness of theories underlying the design of

interactive software makes it difficult to produce authoritativeand specific standards

I The more abstract the guideline, the more it resembles theprinciples; the more specific the guideline, the more suited it isto detailed design

I Several books and technical reports contain huge catalogs ofguidelines

I In moving from abstract guidelines to more specific andautomated ones, it is necessary to introduce assumptionsabout the computer platform on which the interactive systemis designed

I Guidelines are often referred to as style guides to reflect thatthey are not hard and fast rules, but suggested conventionsfor programming in an environment

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristics

I Nielsen’s ten heuristics (introduced later with evaluationtechniques)

I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)

I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rules

I Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Golden rules and heuristics

I ‘Golden rules’ or heuristics offer a simpler way to design ascompared with principles, standards and guidelines

I ‘Broad-brush’ design rules may not be always be applicable toevery situation

I Provide a useful checklist or summary to good design

I Better design can be produced by following even these simplerules than using nothing

I Many sets of heuristicsI Nielsen’s ten heuristics (introduced later with evaluation

techniques)I Shneiderman’s eight golden rulesI Norman’s seven principles

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Shneiderman’s eight golden rules

Shneiderman’s eight golden rulesShneiderman’s eight golden rules provide a summary of the keyprinciples of interface design. They can be used not only for designbut also for evaluation.

1. Strive for consistency in action sequences, layout, terminology,command use and so on.

2. Enable frequent users to use shortcuts, such as abbreviations,special key sequences and macros, to perform regular, familiaractions more quickly.

3. Offer informative feedback for every user action, at a levelappropriate to the magnitude of the action.

4. Design dialogs to yield closure so that the user knows whenthey have completed a task.

5. Offer error prevention and simple error handling so that,ideally, users are prevented from making mistakes and, if theydo, they are offered clear and informative instructions toenable them to recover.

6. Permit easy reversal of actions in order to relieve anxiety andencourage exploration, since the user knows that he canalways return to the previous state.

7. Support internal locus of control so that the user is in controlof the system, which responds to his actions.

8. Reduce short-term memory load by keeping displays simple,consolidating multiple page displays and providing time forlearning action sequences.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.

I A number of ways to simplify the structure of tasksI provide mental aids to help user keep track of stages in a more

complex taskI use technology to provide user with more information about

the task and better feedbackI automate the task or part of it, as long as this does not

detract from user’s experienceI change the nature of the task so that it becomes something

more simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles1. Use both knowledge in the world and knowledge in the head.

I People work better when the knowledge they need to do a taskis available externally - either explicitly or through theconstraints imposed by the environment.

I But experts also need to be able to internalize regular tasks toincrease their efficiency.

I So systems should provide the necessary knowledge within theenvironment and their operation should be transparent tosupport the user in building an appropriate mental model ofwhat is going on.

2. Simplify the structure of tasks.I A number of ways to simplify the structure of tasks

I provide mental aids to help user keep track of stages in a morecomplex task

I use technology to provide user with more information aboutthe task and better feedback

I automate the task or part of it, as long as this does notdetract from user’s experience

I change the nature of the task so that it becomes somethingmore simple

I It is important not to take control away from the user

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.

I The interface should make clear what the system can do andhow this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.

I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.

I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.

I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.

I Controls, sliders and dials should reflect the task - so a smallmovement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.

I Constraints are things in the world that make it impossible todo anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.

I Anticipate the errors the user could make and design recoveryinto the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.

I If there are no natural mappings then arbitrary mappingsshould be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Norman’s seven principles

Norman’s seven principles (Cont’d)3. Make things visible: bridge the gulfs of execution and

evaluation.I The interface should make clear what the system can do and

how this is achieved, and should enable the user to see clearlythe effect of their actions on the system.

4. Get the mappings right.I User intentions should map clearly onto system controls.I User actions should map clearly onto system events.I It should be clear what does what and by how much.I Controls, sliders and dials should reflect the task - so a small

movement has a small effect and a large movement a largeeffect.

5. Exploit the power of constraints, both natural and artificial.I Constraints are things in the world that make it impossible to

do anything but the correct action in the correct way.

6. Design for error.I Anticipate the errors the user could make and design recovery

into the system.

7. When all else fails, standardize.I If there are no natural mappings then arbitrary mappings

should be standardized so that users only have to learn themonce.

Design Rules

Golden rules and heuristics

Other design heuristics

Heuristics for interface design

I Coursera online course videos by Prof. Scott Klemmer aboutsome design heuristics for interface design:

I Design heuristics part 1

I Design heuristics part 2

Design Rules

Golden rules and heuristics

Other design heuristics

Heuristics for interface design

I Coursera online course videos by Prof. Scott Klemmer aboutsome design heuristics for interface design:

I Design heuristics part 1

I Design heuristics part 2

Design Rules

Golden rules and heuristics

Other design heuristics

Heuristics for interface design

I Coursera online course videos by Prof. Scott Klemmer aboutsome design heuristics for interface design:

I Design heuristics part 1

I Design heuristics part 2

Design Rules

Golden rules and heuristics

Other design heuristics

Heuristics for interface design

I Coursera online course videos by Prof. Scott Klemmer aboutsome design heuristics for interface design:

I Design heuristics part 1

I Design heuristics part 2

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns:

an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design

-the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

HCI patterns

I One way for design is to learn from examples that have provento be successful in the past: to reuse the knowledge of whatmade a system successful

I Patterns: an approach to capturing and reusing thisknowledge of abstracting the essential details of successfuldesign so that these can be applied again and again in newsituations

I A pattern is an invariant solution to a recurrent problem withina specific context

I Patterns capture only the invariant properties of good design -the common elements that hold between all instances of thesolution

I The specific implementation of the pattern will depend on thecircumstance and the designer’s creativity

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

HCI patterns

Characteristics of patterns

I capture design practice not theory

I capture the essential common properties of good examples ofdesign

I represent design knowledge at varying levels: social,organizational, conceptual, detailed

I embody values and can express what is humane in interfacedesign

I are intuitive and readable and can therefore be used forcommunication between all stakeholders

I a pattern language should be generative and assist in thedevelopment of complete design

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

process

I Abstract principles, standards and guidelines, golden rules andheuristics, and patterns

I The most abstract design rules are principles, which representgeneric knowledge about good design practice

I Standards and guidelines are more specificI Standards have the highest authority, being set by national or

international bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patterns

I The most abstract design rules are principles, which representgeneric knowledge about good design practice

I Standards and guidelines are more specificI Standards have the highest authority, being set by national or

international bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practice

I Standards and guidelines are more specificI Standards have the highest authority, being set by national or

international bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practiceI Standards and guidelines are more specific

I Standards have the highest authority, being set by national orinternational bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practiceI Standards and guidelines are more specific

I Standards have the highest authority, being set by national orinternational bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practiceI Standards and guidelines are more specific

I Standards have the highest authority, being set by national orinternational bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practiceI Standards and guidelines are more specific

I Standards have the highest authority, being set by national orinternational bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practiceI Standards and guidelines are more specific

I Standards have the highest authority, being set by national orinternational bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process

Design Rules

Summary

SummaryI Design rules can be used to provide direction for the design

processI Abstract principles, standards and guidelines, golden rules and

heuristics, and patternsI The most abstract design rules are principles, which represent

generic knowledge about good design practiceI Standards and guidelines are more specific

I Standards have the highest authority, being set by national orinternational bodies to ensure compliance by a largecommunity

I Guidelines are less authoritative but offer specific contextualadvice, which can inform detailed design

I Heuristics and ‘golden rules’ are succinct collections of designprinciples and advice that are easily assimilated by anydesigner

I Patterns capture design practice and attempt to provide agenerative structure to support design process