Cognitive Dimensions

1
Cognitive Dimensions
of Notations and other Information Devices

• Alan Blackwell
• Tutorial for Diagrams 2008

2
What are Cognitive Dimensions?

• A broad-brush theoretical approach
• Providing a practical usability tool for everyday
  analysts and designers
• Stressing simple, cognitively relevant system
  properties
• Including trade-offs and design manoeuvres

3
Aims of the tutorial

• Concise, illustrated, introduction to CDs
• Providing practical advice
• a vocabulary for system analysis and research
• a checklist for designers
• a repertoire of design manoeuvres
• an awareness of potential trade-offs
• and research opportunities
• other applications of the dimensions approach
• alternative characterisation of diagram use

4
Your needs

• What are the needs of this audience?
• Analysis versus design?
• What is the balance of
• First heard of CDs at this meeting?
• Have heard others speak of CDs?
• Have read papers by Green et al?
• Have conducted CDs analyses?
• Other?

5
Part 1

• Overview of CDs
• Activities
• Structured Information Devices

6
What are CDs for?

• Both summative and formative evaluation
• Discussion tools, not deep analysis - CDs are
  not a checklist of ideal features.
• All real design is about trade-offs
• What is better a Lamborghini or a tractor?
• Do they have design principles in common?
• No superlativism

7
Four types of construction activity

• Incrementation
• add a new formula to a spreadsheet
• Transcription
• convert an equation to a spreadsheet formula
• Modification
• change spreadsheet for a different problem
• Exploratory design
• programming on the fly (hacking)

8
Three types of interpretation activity

• Search
• find a value specified in a spreadsheet
• Exploratory understanding (sensemaking)
• analyse a business plan presented in a
  spreadsheet
• Comparison
• (recently noted, as yet unpublished)

9
Dimensions and Activities
D1
D2
D3
D4
D5
D6
D7
D8

A1
A2
A3
A4

10
Profiles
D1
D2
D3
D4
D5
D6
D7
D8

A1
A2
A3
A4

11
Why Cognitive Dimensions?

• Why Cognitive?
• Aspects that make learning and doing hard for
  mental reasons
• Do not focus on non-cognitive factors
• social context, aesthetics, emotion etc.
• Why Dimensions?
• idealisations (like velocity, potential energy)
• conceptually independent (like mass time)

12
Defining information devices

• Structured information devices involve
• a notation
• an environment
• a medium
• To explain these, we use an example dimension
  Viscosity
• simplified preview definitiona viscous system
  is hard to modify

13
Information devices structure

• Environment
• text in a word processor is easy to modify, on
  pencil and paper is hard to modify
• Notations
• inserting text in a novel is easier than in a
  document with numbered paragraphs X-refs
• Media
• any part of a text on paper can be accessed, but
  harder on a dictaphone.

14
Definitions

• Notation
• perceived marks or symbols
• Environment
• operations or tools for manipulating marks
• Medium
• what the notation is imposed on (e.g. paper,
  sound, the dialling memory of a telephone)

15
Some refinements

• Layers
• In a programming language layer 1 is the
  language, layer 2 is the editing operations.
• Each layer has its own dimensions
• Sub-devices
• Part of the system that has a different notation,
  environment and medium (e.g. VCR user writes
  instructions on Post-It note)
• System representational elements such as windows,
  menus and dialogs should not be confused with the
  notation of an application.

16
Summary

• CDs are usability profile discussion tools
• Interaction is viewed as building and modifying
  an information structure
• Usability depends on the structure of the
  notation and the tools in the environment
• Different activities have different profiles
• There are trade-offs between dimensions

17
Part 2 The Dimensions
18
Dimensions covered today

• Abstraction
• types and availability of abstraction mechanisms
• Hidden dependencies
• important links between entities are not visible
• Premature commitment
• constraints on the order of doing things
• Secondary notation
• extra information in means other than formal
  syntax
• Viscosity
• resistance to change
• Visibility
• ability to view components easily

19
Not covered in detail today

• Closeness of mapping
• closeness of representation to domain
• Consistency
• similar semantics expressed in similar forms
• Diffuseness
• verbosity of language
• Error-proneness
• notation invites mistakes
• Hard mental operations
• high demand on cognitive resources

• Progressive evaluation
• work-to-date checkable any time
• Provisionality
• degree of commitment to actions or marks
• Role-expressiveness
• component purpose is readily inferred
• And more
• several new dimensions still under discussion

20
Viscosity

• Resistance to change the cost of making small
  changes.
• Repetition viscosity
• e.g. manually changing US spelling to UK spelling
  throughout a long document
• Domino (was Knock-On) viscosity
• e.g. inserting a figure in a document means
  updating all later figure numbers, their
  cross-references, the list of figures, the index
  ...

21
Viscosity features

• Viscosity becomes a problem when you need to
  change your plan it is a function of the work
  required to change a plan element.
• It is a property of the system as a whole
• May be different for different operations
• Often happens when designers assume system use
  will only involve incrementation

22
Viscosity examples

• Repetition viscosity example
• When the user has one document in mind, but it is
  stored as a collection of files, which must be
  edited separately to change style in all.
• Domino viscosity example
• In structures with high inter-dependency, such as
  timetables.
• Combinations of the two are the worst!

23
Combined domino/repetition

• Common in graphic structures, genealogical trees,
  hypertexts
• e.g. tree showing part of JavaScript hierarchy

window
location
frames
document
navigator
mimeTypes
plugins
24
Workarounds trade-offs

• Separate exploratory transcription stages
• e.g. pencil sketch before ink
• Introduce a new abstraction
• e.g. AutoNumber facility
• Change the notation
• e.g. quick dial codes for telephone

25
Hidden Dependencies

• A relationship between components such that one
  is dependent on the other, but the dependency is
  not fully visible.
• The one-way pointer
• e.g. your Web page points to someone elses - how
  do you know when they move it?
• Local dependency
• e.g. which spreadsheet cells use the value in a
  given cell?

26
Hidden Dependency features

• Hidden dependencies slow up information finding.
• Tolerable in exploratory design, but not in
  modification
• May be responsible for high frequency of errors
  in spreadsheets.

27
Hidden Dependency examples

• GOTO statements dont have a corresponding
  COME-FROM.
• Block structure brings symmetry
• Data-flow makes dependencies explicit
• Contents lists are one-way
• Fossil deposits (e.g. dot files, DLLs)

28
Workarounds trade-offs

• Require explicit cueing
• e.g. import and export declarations
• Highlight different information
• e.g. data-flow language
• Provide tools
• e.g. spreadsheets which highlight all cells that
  use a particular value

29
Premature Commitment / Enforced Lookahead

• Constraints on the order of doing things force
  the user to make a decision before the proper
  information is available.

30
Premature commitment features

• Only occur if three conditions hold
• target notation contains internal dependencies
• access to both source and target is
  order-constrained
• the constrained order is inappropriate
• Happens when designers view of natural
  sequence is at variance with users needs
• Results in 2nd and 3rd attempts at task

31
Premature commitment examples

• Telephone menu systems
• Four-function calculator
• ( 1.2 3.4 - 5.6) / ( ( 8.7 - 6.5 ) ( 4.3 ) )

32
More types and examples

• Defining database schemas before the data
• Filing systems (library shelving by Dewey)
• Surreptitious order constraints
• Provisional relationships in E-R diagram
• Effect of medium
• Exacerbated when marks are transient (e.g. in
  an auditory medium)

33
Workarounds trade-offs

• Decoupling
• e.g. the signwriter paints the sign elsewhere
• Ameliorating
• premature commitment is not so bad if viscosity
  is low bad guesses can be corrected
• Deconstraining
• e.g. GUI interfaces often remove constraints on
  order of actions

34
Abstractions

• An abstraction is a class of entities or grouping
  of elements to be treated as one entity (thereby
  lowering viscosity).
• Abstraction barrier
• minimum number of new abstractions that must be
  mastered before using the system (e.g. Z)
• Abstraction hunger
• require user to create abstractions

35
Abstraction features

• Abstraction-tolerant systems
• permit but do not require user abstractions
  (e.g. word processor styles)
• Abstraction-hating systems
• do not allow definition of new abstractions(e.g.
  spreadsheets)
• Abstraction changes the notation.

36
Abstraction implications

• Abstractions are hard to create and use
• Abstractions must be maintained
• useful for modification and transcription
• increasingly used for personalisation
• Involve the introduction of an abstraction
  manager sub-device
• including its own viscosity, hidden dependencies,
  juxtaposability etc.

37
Abstraction examples

• Persistent abstractions
• Style sheets, macros, telephone memories
• Definitions and exemplars
• Powerpoint templates, CAD libraries
• Transient abstractions
• Search and replace, selection aggregates

38
Workarounds trade-offs

• Incremental abstractions
• low abstraction barrier, tolerates new additions,
  provides alternatives (but may confuse)
• Overcoming abstraction-repulsion
• abstractions decrease viscosity, but increase
  problems for occasional / end-users
• Programming by example?
• can introduce abstract hidden dependencies

39
Secondary Notation

• Extra information carried by other means than the
  official syntax.
• Redundant recoding
• e.g. indentation in programs, grouping contol
  knobs by function
• Escape from formalism
• e.g. annotation on diagrams

40
Secondary Notation features

• Redundant recoding ? easier comprehension?
  easier construction.
• Escape from formalism? more information
• Is secondary notation ever bad?
• what about the brevity bigots?
• Designers often forget that users need
  information beyond the official syntax.
• and even try to block the escapes people use

41
Secondary Notation examples

• Redundant recoding
• Telephone number layout
• Front panel of a car radio
• Functional grouping

0114 225 5335 or0 11 42 25 53 35?
42
Secondary Notation examples

• Escape from formalism
• Usage of calendars and diaries.

scar
regular event is not happening
different handwriting
important
43
Workarounds trade-offs

• Decoupling (if insufficient secondary notation)
• e.g. print out hard copy, attack it with a pencil
• Enriched resources
• e.g. CogMap spreadsheet enhancement
• But extensive secondary notation introduces added
  viscosity (it gets out of date).
• e.g. program comments

44
Visibility Juxtaposability

• Ability to view components easily to place any
  two components side by side.
• Visibility
• e.g. searching a telephone directory for the name
  of a subscriber who has a specified telephone
  number
• Juxtaposability
• e.g. trying to compare statistical graphs on
  different pages of a book

45
Visibility Juxtaposability features

• Structure or indexing information is often
  invisible because designers assumed it wouldnt
  be needed.
• Often caused by presenting information in
  windows, then restricting the number of windows.
• Becomes far worse with small devices
  (cell-phones, PDAs, wearable computers?).

46
Visibility Juxtaposability examples

• Small windows onto invisible control trees
• e.g. car radios, fax machines, cameras.
• Shared use displays
• e.g. clock-radio time or alarm or radio station
• Form based systems

47
Workarounds trade-offs

• Working memory
• refreshed by revisiting items being compared
• External memory
• e.g. make a hard copy of one component (a new
  environment that allows side-by-side viewing)
• Adding a browser
• e.g. class browser, alternative views
• Visibility trades off against clutter, abstraction

48
Part 3 The Framework

• Cognitive relevance
• Tradeoffs design manoeuvres
• Application techniques

49
Cognitive relevance

• Desirable profiles

50
Notable trade-offs

• There are many complex trade-offs here is a
  subset

secondary notation
hidden dependencies
viscosity
premature commitment
abstraction usage
learnability
juxtaposability
visibility
51
Some design manoeuvres

• Potential design approaches to
• reduce viscosity
• improve comprehensibility
• make premature commitment less expensive
• remove need for lookahead
• improve visibility

52
Design manoeuvres (1)

• Aim to reduce viscosity
• Manoeuvre
• add abstractions (so one power command can
  change many instances)
• At this cost
• increased lookahead (to get right abstractions)
• raises the abstraction barrier
• may increase dependencies among abstractions

53
Design manoeuvres (2)

• Aim to improve comprehensibility
• Manoeuvre
• allow secondary notation - let users choose
  placing, white space, font colour allow
  commenting
• At this cost
• increases viscosity (because layout, colour etc
  not usually well catered for by environments)

54
Design manoeuvres (3)

• Aim to make premature commitment less expensive
• Manoeuvre
• reduce viscosity (so that users can easily
  correct their first guess)
• At this cost
• see above, re viscosity

55
Design manoeuvres (4)

• Aim to remove need for lookahead
• Manoeuvre
• remove internal dependencies in the notation
• allow users to choose an easier decision order
• At this cost
• may make notation diffuse, or increase errors
• allowing free order needs a cleverer system

56
Design manoeuvres (5)

• Aim to improve visibility
• Manoeuvre
• add abstractions (so that the notation becomes
  less diffuse)
• At this cost
• see above re abstractions

57
Application techniques

• Formative discussion vocabulary
• Designer-led evaluation
• User-led evaluation
• Persona profiles

58
Formative discussion vocabulary

• Original intention in formulating Cognitive
  Dimensions framework was to
• raise the level of discourse
• combat superlativism
• lexicalise (provide a discussion vocabulary)
• Explicitly presenting these contributions
• assumes relatively sophisticated understanding of
  design process
• risks confound between design of the notation and
  design using the notation
• designers of notations do not always recognise
  their activity as design

59
Designer-led evaluation

• Evaluation methodology presented for use by
  professional designers
• Identify medium and notation layers
• Watch out for sub-devices
• Define important activity profiles
• Review dimensions
• Apply manoeuvers (allowing for trade-offs)
• Either individual critic or team

60
User-led evaluation

• The Cognitive Dimensions questionnaire
• explains framework in generic terms
• encourages users to reflect on experience
• stops designers avoiding tricky problems
• guards against misinterpretations
• The users do the work!
• broader range of experience applied
• Relies on users who are
• expert
• reflective
• intelligent

61
Cognitive Dimensions questionnaire
62
Profiles and personas with CD Graph
63
Part 4 Recent Developments

• More dimensions
• Theoretical approaches
• Other dimensions frameworks (social, physical)

64
Remaining dimensions

• Closeness of Mapping
• Consistency
• Diffuseness
• Error-proneness
• Hard Mental Operations
• Progressive Evaluation
• Provisionality
• Role-expressiveness

65
Closeness of Mapping

• Closeness of representation to domain
• A close mapping
• the visual programming language LabVIEW, used by
  electronics engineers, looks like a circuit
  diagram
• A distant mapping
• in the first version of Microsoft Word, the only
  way to count the characters in a file was to save
  the file to disc - then it told you how long the
  file was.

66
Consistency

• Similar semantics are expressed in similar
  syntactic forms.
• e.g. menu-driven domestic information artefacts,
  such as in-car audio
• in a consistent version, same keys move up/down,
  step to next item, select current item, return to
  menu
• but often slight differences from item to item
• N.B. consistency usually affects learnability
  rather than usability (but see error-proneness).

67
Diffuseness

• Verbosity of language
• COBOL is a verbose languageMULTIPLY A BY B
  GIVING C
• Forth is a terse languagethe command to print a
  newline is .(a single full stop).
• Effect of over-verbosity probably slight
• does affect working memory
• Terseness is an awkward trade-off
• makes it easier to make mistakes

68
Error-Proneness

• The notation invites mistakes
• Poor discriminability
• Fortran identifiers I O confused with 1 0.
• Inadequate syntax-checking
• Prolog has no declarations mistypings cause
  problems detectable only at run-time.
• Bad dialogue design
• inconsistencies invite errors - e.g. always using
  ENTER as a default except in one case.

69
Hard Mental Operations

• High demand on cognitive resources
• e.g. threading a maze
• every branch choice brings more to remember
• physical mazes have memoryless algorithms
• but abstract isomorphs are hard
• following circuit diagrams
• auditing spreadsheets
• finding files in big directory structures

70
Progressive Evaluation

• Work-to-date can be checked at any time
• e.g. customisable domestic devices, such as
  telephones with memories
• display rarely says what you have stored
• rarely says how far you have got in the process,
  so if you lose concentration you don't know where
  you were
• novices need frequent checks on work-to-date
• even experienced users, when working under stress
  of frequent interruptions.

71
Provisionality

• Degree of commitment to actions or marks
• e.g. use of pencils for design
• architects, typographers etc. use pencils to make
  faint blurry marks something more or less like
  this goes more or less here (although this is
  also related to ambiguity see later)
• can also make precise, hard marks when you want
• Reduces premature commitment.

72
Role-Expressiveness

• The purpose of a component (or an action or a
  symbol) is readily inferred
• e.g. superstition when novices use advanced
  systems
• I always do it that way and it seems to work
• But why?

73
Theoretical developments

• Metrication
• 18 metrical benchmarks (Yang et. al.)
• e.g. hiddenness-of-dependencies
• (Nde sources of dependency explicitly depicted) /
  (Ndt total sources of dependency in system)
• Formalisation
• ERMIA (Green Benyon)
• Entity-Relationship Models of Information
  Artefacts
• Goal-based system modelling (Roast Siddiqi)
• Cognitive theory of notation use
• Abstraction / attention investment (Blackwell)
• OSM / CASSM misfits (Blandford)

74
Other dimensions approaches

• Tangible correlates of CDs (Edge)
• TUIs as 3D manipulable solid diagrams
• Permanence, Bulkiness, Shakiness, Rigidity etc.
• See JVLC 17(4), 2006
• CDs for collaboration (Bresciani)
• Visual Impact, Clarity, Perceived Finishedness,
  Directed Focus, Facilitated Insight,
  Modifiability, Group Interaction Support
• See DCRR-007, February 2008
• CDs as interaction pattern language (Fincher)
• Work in progress (see PPIG 2002)
• Always more dimensions!

75
More dimensions!

• Creative ambiguity
• user sees something different when looking again
• Specificity
• elements have limited interpretations
• Detail in context
• see how local elements relate to each other
• Indexing
• The notation includes elements to help the user
  find specific parts.

76
More dimensions!

• Synopsie (ex-grokkiness)
• understanding the whole when you stand back and
  look
• Free rides
• following notational rules ? new information
• Useful awkwardness
• force the user to reflect on the task
• Unevenness
• easy actions push ideas in a certain direction

77
More dimensions (from Clarke)

• Penetrability
• How does an API facilitate exploration, analysis,
  and understanding of its components?
• Learning Style
• What are the learning requirements posed by an
  API to a targeted developer (incremental,
  step-wise, top down )?
• Work-Step Unit
• How much of a programming task can/must be
  completed in a single task step?
• API Elaboration
• To what extent can/must an API be adapted to meet
  the needs of a targeted developer?

78
Further reading
79
www.cl.cam.ac.uk/afb21/CognitiveDimensions/

• Green, T. R. G. (1989). Cognitive dimensions of
  notations. In People and Computers V, Cambridge
  University Press.
• Green Petre, M. (1996). Usability analysis of
  visual programming environments a 'cognitive
  dimensions' framework. Journal of Visual
  Languages and Computing, 7, 131-174.
• Blackwell and Green (2003). Notational systems -
  the Cognitive Dimensions of Notations framework.
  In J.M. Carroll (Ed.) HCI Models, Theories and
  Frameworks Toward a multidisciplinary science.
  Morgan Kaufmann.
• Blackwell (Ed.) (2006). Ten Years of Cognitive
  Dimensions. Special Issue of Journal of Visual
  Languages and Computing, August 2006 Vol 17 No 4.

80
Illustration material

• Extended examples
• On-line diary system
• Visual programming languages

81
A Diary System

• Now Up-to-Date (NUD)
• Manages the following types of data
• events
• having attributes name, type, priority etc.
• categories of event
• sets of visible categories
• views
• by time unit, or by lists of events

82
NUD month view
83
NUD day view
84
NUD list view
85
Cognitive Dimensions of main device

• Viscosity
• Hidden dependencies
• Premature commitment
• Abstraction barrier / hunger
• Secondary notation
• Visibility Juxtaposability

86
Viscosity (1)

• Extending and moving events in month view is just
  drag and drop

87
Viscosity (2)

• But domino viscosity when inserting
• an event cant be inserted between existing
  events
• all other events must be manually readjusted
• which leads to

88
Viscosity (3)

• Repetition viscosity
• each event has to be opened and have its time
  retyped

89
Hidden dependencies

• Events are generally independent
• But changing a repeating event to a type with no
  start time silently changes all others as well.

90
Premature commitment

• When creating an event, must define type and
  classify set of types.
• Not too serious, because type can be changed
  reasonably easily.

91
Abstraction barrier / hunger

• The abstractions to be maintained are
• categories (each event has only one)
• sets (may contain any number of categories)
• repetitions of events
• Categories and sets are defined and handled via a
  sub-device - analysed later

92
Secondary notation

• Variations in colour, font and style
• Sets can define appearance of events in each
  category
• Individual events can over-ride defaults
• Difficult to show non-events
• cancellations
• provisional events

93
Visibility Juxtaposability

• Juxtaposability
• duplicate windows (not obvious to new users)
• Events visible in day and month views
• Sets are visible in list view

94
Abstraction management sub-device (1)

• Repetitions are relatively simple
• Defining sets is more interesting

95
Abstraction management sub-device (2)

• Viscosity
• low categories readily created removed
• Hidden dependencies
• few dependencies
• Premature commitment
• you need to categorise your life in advance

96
Abstraction management sub-device (3)

• Abstraction barrier/hunger
• must have at least one category and one set
• perhaps should express constraint that every
  event must belong to at least one of each
• Secondary notation
• none available
• Visibility/juxtaposability
• sets easily visible but only one at a time

97
NUD Conclusions

• Incrementation
• Good
• Transcription
• Good
• Modification of existing schedule
• Less good

98
Two Visual Programming Languages

• The candidates
• LabVIEW (National Instruments)
• Prograph (Pictorius)
• NB whatever criticisms we make, we think they
  are good products

99
The rocket program BASIC
Mass 10000 Fuel 50 Force 400000 Gravity
32 WHILE Vdist 0 IF Tim 11 THEN Angle
.3941 IF Tim 100 THEN Force 0 ELSE
Mass Mass - Fuel Vaccel Force
COS(Angle) / Mass - Gravity Vveloc Vveloc
Vaccel Vdist Vdist Vveloc
Haccel Force SIN(Angle) / Mass Hveloc
Hveloc Haccel Hdist Hdist Hveloc
PRINT Tim, Vdist, Hdist Tim Tim
1 WEND STOP
100
The rocket program LabVIEW
101
The rocket program Prograph
102
Viscosity

• Modification experiment (Petre Green)
• time required to make equivalent modifications

103
Hidden dependencies

• Visual languages make connections explicit
• But with the trade-off that they need more screen
  space

BASIC
LabVIEW
x 1 ... (possibly many pages of
code here...) y x 3
104
Premature commitment (1)

• Commitment to layout is a common problem e.g. x
  (-b sqr(b2 - 4ac) / 2a)
• Start with minus b

105
Premature commitment (2)

• Ill need b-squared too

106
Premature commitment (3)

• turn that into b-squared minus 4ac

107
Premature commitment (4)

• oops, thats going to be 4ac minus b-squared
  try moving the 4ac chunk down and reconnecting to
  the minus box

108
Premature commitment (5)

• OK, now I need plus or minus that
• thats root-b-squared-minus-4ac but I still
  havent used b or the rest of the formula!

109
Other types of commitment

• to choice of construct
• to connections

110
Abstraction barrier / hunger

• Depends on choice of primitives
• probably more than spreadsheet, less than C
• LabVIEW is abstraction-tolerant
• can create virtual instruments
• Prograph is abstraction-hungry
• O-O systems often need new abstractions
• No layout abstraction (e.g. grouping)

111
Secondary notation

• Little support for commenting
• can only attach comment to a single item
• Spatial layout cant easily be used for grouping
• All the visual variables (degrees of freedom) are
  taken up by the formal syntax

112
Visibility Juxtaposability

• Visibility of data flow in LabVIEW is excellent,
  many small windows in Prograph obscure flow.
• Control branches in LabVIEW cant be juxtaposed

113
LabVIEW / Prograph Conclusions

• Hidden dependencies
• Remarkably few
• Viscosity
• Extraordinarily high
• Secondary notation
• Very poor

114
Part 4

• Practice Exercises

115
Approach to the Exercises

• Analyse simulated devices to see how slight
  changes in the design affect usability.
• Analyse them from the point of view of Cognitive
  Dimensions
• don't try to suggest technical fixes for the
  problems
• don't look for problems outside the range of
  Cognitive Dimensions (unless you want to!)

116
Simple example

• Evaluate a proposed design
• Handheld Shopping Assistant ShopAss

ShopAss!
Select shop
Freddys Fruit
Victors Veg
Mikes Meat
Tonys Toiletries
Enter new shop
117
Notations and media

• Medium
• The PDA screen
• Notation 1
• The list of shops
• Notation 2
• Shopping lists
• Notation 3
• Sub-device for defining a new shop

ShopAss!
Freddys Fruit
118
Sub-device

• Defining a new shop
• Database is initially empty.
• Shops are indexed by map location to minimise
  walking time.

ShopAss!
Define shop
Name
Map reference
119
Sample task buy for a recipe

• Ive looked up my recipe for gammon steak
• 1 big piece of ham
• 1 small can of pineapple
• aerosol mashed potato
• First activity transcription

ShopAss!
Select shop
Freddys Fruit
Victors Veg
Mikes Meat
Tonys Toiletries
Enter new shop
120
Role-expressiveness

• Where can I buy pineapple?
• The notation doesnt relate to my task
• could use pictures of fruit and veg?
• could define shopping categories (but abstraction
  tradeoff)

ShopAss!
Select shop
Freddys Fruit
Victors Veg
Mikes Meat
Tonys Toiletries
Enter new shop
121
Hidden dependency

• What if I cant get any pineapple?
• The notation has failed to capture important
  information about the structure of my task.

ShopAss!
Mikes Meat
BIG PIECE OF HAM
122
Abstraction

• Database is initially empty.
• Its not possible to create even a basic shopping
  list without defining a shop.
• Abstraction barrier
• define a shop first
• (like Smalltalk)

ShopAss!
Select shop
Enter new shop
123
More dimensions

• Visibility and juxtaposability
• screen size limit
• Premature commitment
• choose shop first?
• Viscosity
• get pineapple from a nearer shop

ShopAss!
Victors Veg
CAN OF PINEAPPLE
POTATO AEROSOL
BEAN COUNTERS
VISCOUS SOUP
BALL BEARINGS
124
Play it Again

• Central heating controller for domestic use must
  be simple, with small number of LCD displays.
• The Alhambra is a fairly faithful copy of the
  controller in Thomas house.
• The Balmoral is an invention.
• On which dimensions do they differ?

125
Form Filling and Menus

• It's frustrating to fill out a form by phone
  equally frustrating to answer questions to a
  rigid-minded computer program.
• Disobliging Daves restaurant - choose each
  course in turn, with no going back.
• Cheerful Charleys - they leave you a piece of
  paper - just mark the dishes you want.
• Try to choose a dinner that avoids having the
  same ingredient twice in two courses!

126
Number Games

• How smart is this telephone handset?
• The Egbert is based on a popular
  commercially-available telephone.
• It has a simple memory feature that allows
  numbers to be stored and recalled.
• How does it rate on the dimensions?

127
Tiling in Style

• An editor for use when designing tile floors.
• Scenario A used by a Tile Consultant, working to
  a sketch or verbal informal supplied by the
  customer.
• Scenario B the customer is a direct end-user of
  the tile editor, exploring possibilities without
  any preliminary sketch.
• Compare two editor modes Greenwich and
  Harrogate (one at a time)

128
Your Own Example

• Identify sub-devices
• Assess dimensions
• Recognise trade-offs
• Apply design manoeuvres