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