Cognitive Dimensions Alan Blackwell Tutorial for Diagrams 2008 of Notations and other Information...
-
date post
21-Dec-2015 -
Category
Documents
-
view
215 -
download
1
Transcript of Cognitive Dimensions Alan Blackwell Tutorial for Diagrams 2008 of Notations and other Information...
Cognitive DimensionsCognitive Dimensions
Alan Blackwell
Tutorial for Diagrams 2008
of Notations and other Information Devices
What are Cognitive Dimensions? 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
Aims of the tutorialAims 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
Your needsYour 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?
Part 1Part 1
Overview of CDs;
Activities;
Structured Information Devices
What are CDs for? 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
Four types of construction activity 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”)
Three types of interpretation activityThree 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)
Dimensions and ActivitiesDimensions and Activities
D1 D2 D3 D4
A1
D5 D6 D7 D8
A2
A3
A4
…
…
ProfilesProfiles
D1 D2 D3 D4
A1
D5 D6 D7 D8
A2
A3
A4
…
…
Why ‘Cognitive Dimensions’?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)
Defining information devicesDefining information devices
Structured information devices involve:– a notation– an environment– a medium
To explain these, we use an example dimension: Viscosity– simplified preview definition:
“a viscous system is hard to modify”
Information devices: structureInformation 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.
DefinitionsDefinitions
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)
Some refinementsSome 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.
SummarySummary
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
Part 2: The DimensionsPart 2: The Dimensions
Dimensions covered today: 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
Not covered in detail today: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
ViscosityViscosity
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 ...
Viscosity featuresViscosity 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
Viscosity examplesViscosity 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!
Combined domino/repetition Combined domino/repetition
Common in graphic structures, genealogical trees, hypertexts …– e.g. tree showing part of JavaScript hierarchy
window
mimeTypesplugins
locationframesdocument navigator
Workarounds & trade-offs 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
Hidden DependenciesHidden 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 else’s -
how do you know when they move it?
Local dependency:– e.g. which spreadsheet cells use the value in a
given cell?
Hidden Dependency featuresHidden 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.
Hidden Dependency examplesHidden Dependency examples
GOTO statements don’t 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)
2
0.84
*
*
+
0.29
units
pricetax
total
Workarounds & trade-offsWorkarounds & 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
Premature Commitment / Enforced LookaheadPremature Commitment / Enforced Lookahead
Constraints on the order of doing things force the user to make a decision before the proper information is available.
Premature commitment featuresPremature 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 designer’s view of “natural sequence” is at variance with user’s needs
Results in 2nd and 3rd attempts at task
Premature commitment examplesPremature commitment examples
Telephone menu systems
Four-function calculator– ( 1.2 + 3.4 - 5.6) / ( ( 8.7 - 6.5 ) + ( 4.3 ) )
More types and examplesMore 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)
Workarounds & trade-offsWorkarounds & 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
AbstractionsAbstractions
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
Abstraction featuresAbstraction 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.
Abstraction implicationsAbstraction 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.
Abstraction examplesAbstraction examples
Persistent abstractions: – Style sheets, macros,
telephone memories
Definitions and exemplars– Powerpoint templates,
CAD libraries
Transient abstractions:– Search and replace,
selection aggregates
Workarounds & trade-offsWorkarounds & 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
Secondary NotationSecondary 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
Secondary Notation featuresSecondary 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
Secondary Notation examplesSecondary Notation examples
Redundant recoding– Telephone
number layout
– Front panel of a car radio
– Functional grouping
0114 225 5335or
0 11 42 25 53 35?
Secondary Notation examplesSecondary Notation examples
Escape from formalism– Usage of calendars and diaries.
scarregular event is not happening
importantdifferent handwriting
Workarounds & trade-offsWorkarounds & 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
Visibility & JuxtaposabilityVisibility & 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
Visibility & Juxtaposability featuresVisibility & Juxtaposability features
Structure or indexing information is often invisible because designers assumed it wouldn’t 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?).
Visibility & Juxtaposability examplesVisibility & 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:
Workarounds & trade-offsWorkarounds & 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
Part 3: The FrameworkPart 3: The Framework
Cognitive relevance
Tradeoffs & design manoeuvres
Application techniques
Cognitive relevance Cognitive relevance
Desirable profiles:
transcription incrementation modification exploration
viscosity acceptable acceptable harmful harmful
hiddendependencies
acceptable acceptable harmful acceptable forsmall tasks
prematurecommitment
harmful harmful harmful harmful
abstractionbarrier
harmful harmful harmful harmful
abstractionhunger
useful useful (?) useful harmful
secondarynotation
useful (?) – v. useful v. harmful
visibility /juxtaposability
not vital not vital important important
Notable trade-offs Notable trade-offs
There are many complex trade-offs; here is a subset:
secondary notation
premature commitment
viscosity
abstraction usage
visibility
hidden dependencies
juxtaposabilitylearnability
Some design manoeuvresSome design manoeuvres
Potential design approaches to:– reduce viscosity– improve comprehensibility– make premature commitment less expensive– remove need for lookahead– improve visibility
Design manoeuvres (1)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
Design manoeuvres (2)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)
Design manoeuvres (3)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
Design manoeuvres (4)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
Design manoeuvres (5)Design manoeuvres (5)
Aim: to improve visibility
Manoeuvre– add abstractions (so that the notation becomes
less diffuse)
At this cost– see above re abstractions
Application techniquesApplication techniques
Formative discussion vocabulary
Designer-led evaluation
User-led evaluation
Persona profiles
Formative discussion vocabularyFormative 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
Designer-led evaluationDesigner-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
User-led evaluationUser-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
Cognitive Dimensions questionnaireCognitive Dimensions questionnaire
Profiles and personas with CD GraphProfiles and personas with CD Graph
Part 4: Recent DevelopmentsPart 4: Recent Developments
More dimensions
Theoretical approaches
Other ‘dimensions’ frameworks (social, physical)
Remaining dimensionsRemaining dimensions
Closeness of Mapping
Consistency
Diffuseness
Error-proneness
Hard Mental Operations
Progressive Evaluation
Provisionality
Role-expressiveness
Closeness of MappingCloseness 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.
ConsistencyConsistency
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).
DiffusenessDiffuseness
Verbosity of language– COBOL is a verbose language:
“MULTIPLY A BY B GIVING C”– Forth is a terse language:
the 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
Error-PronenessError-Proneness
The notation invites mistakes
i. Poor discriminability: • Fortran identifiers I & O confused with 1 & 0.
ii. Inadequate syntax-checking: • Prolog has no declarations; mistypings cause
problems detectable only at run-time.
iii. Bad dialogue design: • inconsistencies invite errors - e.g. always using
ENTER as a default … except in one case.
Hard Mental OperationsHard 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
Progressive EvaluationProgressive 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.
ProvisionalityProvisionality
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.
Role-ExpressivenessRole-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?
Theoretical developmentsTheoretical 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)
Other ‘dimensions’ approachesOther ‘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!
More dimensions!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.
More dimensions!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
More dimensions (from Clarke)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?
Further readingFurther reading
www.cl.cam.ac.uk/~afb21/CognitiveDimensions/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.
Illustration materialIllustration material
Extended examples:
On-line diary system
Visual programming languages
A Diary System 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
NUD month view NUD month view
NUD day view NUD day view
NUD list view NUD list view
Cognitive Dimensions of main device Cognitive Dimensions of main device
Viscosity
Hidden dependencies
Premature commitment
Abstraction barrier / hunger
Secondary notation
Visibility & Juxtaposability
Viscosity (1)Viscosity (1)
Extending and moving events in month view is just drag and drop
Viscosity (2)Viscosity (2)
But domino viscosity when inserting: – an event can’t be inserted between existing events – all other events must be manually readjusted– which leads to …
Viscosity (3)Viscosity (3)
Repetition viscosity– each event has to be opened and have its time
retyped
Hidden dependenciesHidden dependencies
Events are generally independent– But changing a repeating event to a type with no
start time silently changes all others as well.
Premature commitmentPremature commitment
When creating an event, must define type and classify set of types.
Not too serious, because type can be changed reasonably easily.
Abstraction barrier / hungerAbstraction 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
Secondary notationSecondary 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
Visibility & JuxtaposabilityVisibility & Juxtaposability
Juxtaposability:– duplicate windows (not obvious to new users)
Events visible in day and month views
Sets are visible in list view:
Abstraction management sub-device (1)Abstraction management sub-device (1)
Repetitions are relatively simple
Defining sets is more interesting
Abstraction management sub-device (2)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
Abstraction management sub-device (3)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
NUD: ConclusionsNUD: Conclusions
Incrementation: Good
Transcription: Good
Modification of existing schedule: Less good
Two Visual Programming LanguagesTwo Visual Programming Languages
The candidates:– LabVIEW (National Instruments)– Prograph (Pictorius)
NB: whatever criticisms we make, we think they are good products
The rocket program: BASICThe rocket program: BASIC
Mass = 10000Fuel = 50Force = 400000Gravity = 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
WENDSTOP
The rocket program: LabVIEWThe rocket program: LabVIEW
The rocket program: PrographThe rocket program: Prograph
ViscosityViscosity
Modification experiment (Petre & Green)– time required to make equivalent modifications:
508.3
193.6
63.3
0
100
200
300
400
500
600
LabView Prograph Basic
Hidden dependenciesHidden dependencies
Visual languages make connections explicit
But with the trade-off that they need more screen space
x = 1... (possibly many pages of code here...)y = x + 3
BASIC: LabVIEW:
Premature commitment (1)Premature commitment (1)
Commitment to layout is a common problem e.g. x = (-b + sqr(b2 - 4ac) / 2a)
Start with minus b …
Premature commitment (2)Premature commitment (2)
… I’ll need b-squared too …
Premature commitment (3)Premature commitment (3)
… turn that into b-squared minus 4ac …
Premature commitment (4)Premature commitment (4)
… oops, that’s going to be 4ac minus b-squared … try moving the 4ac chunk down and reconnecting to the ‘minus’ box …
Premature commitment (5)Premature commitment (5)
… OK, now I need plus or minus that …
that’s root-b-squared-minus-4ac but I still haven’t used b … or the rest of the formula!
Other types of commitmentOther types of commitment
… to choice of construct
… to connections:
Abstraction barrier / hungerAbstraction 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)
Secondary notationSecondary notation
Little support for commenting– can only attach comment to a single item
Spatial layout can’t easily be used for grouping
All the visual variables (degrees of freedom) are taken up by the formal syntax
Visibility & JuxtaposabilityVisibility & Juxtaposability
Visibility of data flow in LabVIEW is excellent, many small windows in Prograph obscure flow.
Control branches in LabVIEW can’t be juxtaposed:
LabVIEW / Prograph: ConclusionsLabVIEW / Prograph: Conclusions
Hidden dependencies: Remarkably few
Viscosity: Extraordinarily high
Secondary notation: Very poor
Part 4:Part 4:
Practice Exercises
Approach to the ExercisesApproach 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!)
Simple exampleSimple example
Evaluate a proposed design:
Handheld Shopping Assistant: ShopAss
Enter new shop:
Select shop:
Freddy’s Fruit
Victor’s Veg
Mike’s Meat
Tony’s Toiletries
Notations and mediaNotations 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
Freddy’s Fruit
Sub-deviceSub-device
Defining a new shop
Database is initially empty.
Shops are indexed by map location to minimise walking time.
Name:
Define shop …
Map reference:
Sample task: buy for a recipeSample task: buy for a recipe
I’ve looked up my recipe for gammon steak …– 1 big piece of ham– 1 small can of
pineapple– aerosol mashed
potato
First activity: transcription
Enter new shop:
Select shop:
Freddy’s Fruit
Victor’s Veg
Mike’s Meat
Tony’s Toiletries
Role-expressivenessRole-expressiveness
Where can I buy pineapple?
The notation doesn’t relate to my task – could use pictures of
fruit and veg?– could define
shopping categories (but abstraction tradeoff)
Enter new shop:
Select shop:
Freddy’s Fruit
Victor’s Veg
Mike’s Meat
Tony’s Toiletries
Hidden dependencyHidden dependency
What if I can’t get any pineapple?
The notation has failed to capture important information about the structure of my task.
Mike’s Meat
BIG PIECE OF HAMBIG PIECE OF HAM
AbstractionAbstraction
Database is initially empty.– It’s not possible to
create even a basic shopping list without defining a shop.
Abstraction barrier:– define a shop first– (like Smalltalk) Enter new shop:
Select shop:
More dimensionsMore dimensions
Visibility and juxtaposability:– screen size limit
Premature commitment: – choose shop first?
Viscosity: – get pineapple from a
nearer shop
Victor’s Veg
CAN OF PINEAPPLECAN OF PINEAPPLE
POTATO AEROSOLPOTATO AEROSOL
BEAN COUNTERSBEAN COUNTERS
VISCOUS SOUPVISCOUS SOUP
BALL BEARINGSBALL BEARINGS
Play it AgainPlay 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?
Form Filling and Menus 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 Dave’s restaurant - choose each
course in turn, with no going back.– Cheerful Charley’s - 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!
Number GamesNumber 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?
Tiling in StyleTiling 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)
Your Own ExampleYour Own Example
Identify sub-devices
Assess dimensions
Recognise trade-offs
Apply design manoeuvres