Designing Usable Systems

1
Designing Usable Systems

• This course should enable you to design and
  implement better user interfaces
• We will look at case studies in
• Web browsing
• Cellular Telephones
• VCRs
• Programming Languages

2
Why are you here?

• Because I needed the credits

3
Why am I here?

• Because Im paid to be here

4
What do we know?

• HTML
• Tcl
• Java
• Graph Theory
• State Transition Diagrams / Finite State Automata
• State Charts (Harel)

5
Course Assessment

• Two parts
• Evaluation of usability
• Due soonish
• Analysis of a gadget
• Presentation
• Analysis
• Simulation

6
Reading list

• No set text
• Handouts
• P.O.E.T - Don Norman
• State charts - best book is Ian Horrocks
• My book

7
Course in a nutshell

• Here are some assumptions I am working on, and
  will give you an idea where I am coming from
• Gadgets and software are badly designed and
  everyone accepts this as normal (Dilbert)
• HCI does little to help programmers engineer
  usable systems
• Most HCI is post disaster finger wagging and
  relies on there being an artefact to evaluate
• This is a slight rant, but I am happy to discuss
  any point with you.

8
Usability - does it exist?

• Before we can look at usability, we have to look
  at how it is currently perceived
• To do this, we need to analyse how users know
  that a product is usable
• This is not as easy as it sounds. A good place to
  start looking is by analysing the tasks products
  are designed to solve.

9
Task types - external

• For some products, it is easy to see how well
  they fulfil their role
• chair, car, hi-fi, television
• This type of product is designed to fulfil some
  need that exists in the physical world.
• This type of task we shall call external and is
  not interesting to our discussion.

10
Task types - internal

• The other type of task is an internal task.
• Here a device is built to solve a problem which
  exists only because the device exists!
• With these internal tasks, the problem is defined
  in terms of the device created to solve the
  problem this makes assessing task performance
  incredibly difficult.

11
Visibility - Physical and DM

• Another problem in assessing usability is the
  lack of visibility in electronic devices
• Physical devices have visible qualities which we
  can assess
• Software can be visible (Direct Manipulation) but
  also invisible (DOS)
• Electronics have physical attributes which are
  not worth investigating

12
Direct Manipulation (Ben Shneiderman)

• From studies on video games, decided that
• Users should see objects
• Objects should be controlled directly
• State is always visible
• This led to interfaces such as the Star, Lisa and
  Macintosh

13
Visibility - gadget

• Direct manipulation has helped with software, but
  most computers are sold in embedded systems
• Cellular handsets etc. have limited interfaces
• This was OK when processors were under powered,
  not acceptable now

14
Masochism

• Before we go on to look at usable systems, it is
  worth mentioning that some people like unusable
  systems
• Computer games rely on having obscure interfaces
• The World Wide Web it is fun to just surf around
  hoping to bump into something interesting

15
Introducing usability to products

• I hope I have convinced you in the first lecturer
  that devices are not as usable as they might be
• One possible explanation for this is that the
  technology is not mature enough yet to allow
  usability it to develop

16
Mature technology

• Let us switch briefly to an more mature
  technology as a case study cars
• Originally sold on the fact they worked
• Later came technologies (Balanced Power)
• Ultimately came safety and usability
• Ralph Nader changed perception of this

17
Electronic maturity

• So is the electronic industry in a mature state?
• To answer this we need to look at Christensens
  ideas (MIT professor looking at disruptive
  technology

He assumes that technology develops over time and
eventually reaches some level where it is
sufficient for a task This is true for external
tasks
18
Internal task maturity

• This time, the graph looks a little different
• The curve never meets the task line, as the line
  changes to keep ahead of the curve
• What is going on?

19
Capitalism

• Companies exist to make money for their share
  holders. This means that they need to keep
  selling products to the same consumers
• Unlike cars (or other physical products),
  software (and electronics) does not ware out
• Therefore, companies must make you want to buy
  new products - the technology curve cannot be
  allowed to cross the task line.

20
Task stepping

• There are many ways to produce a stepped task
  curve. Here are three
• Forwards compatibility
• Having software versions which are incompatible
• Processor exploitation
• Here is a quote from a Microsoft executive
• if we hadnt brought your processor to its
  knees, why else would you get a new one.
• Snobbery
• Word processing - font-itis, clipart-itis
  etc.

21
Usability exploitation

• Companies can also exploit usability to step the
  task line using marketing and drama
• Drama
• Exploits the fact that products can be made to
  look easy to use at purchase time
• Sales people use demo buttons or careful
  walkthroughs
• This is backed by marketing
• Microsoft head of marketing perception is
  reality
• Techno-centric focus (Super-Intelligent control)

22
Complicity

• Most users are happy to be exploited in this way
  for many reasons
• Dont want to admit they have made a bad decision
• Enjoy the kudos that comes from knowing a system
  and helping others
• Early adopters buy for fashion purposes
• Moreover, users do not know that there are better
  ways of doing things
• as the technology is hard to understand, users
  assume un-usability is essential

23
Increasing usability awareness

• Before we start to look at how programmers
  improve usability, it is worth considering how
  usability awareness can be raised
• Commercial
• new user groups and applications, esp. cellular
  phones
• little need whilst still selling
• Academic
• little impact in three decades
• Consumer groups
• need to develop usability standards (I have done
  a lot of work here)

24
Building better systems

• There has been much work in HCI on principles for
  interface design
• We shall look at a few of these and see how they
  can be applied to common systems
• Remember these are principles for programmers -
  there is much more to HCI especially in
  prototyping, evaluation and user centred design

25
Affordance (Don Norman)

• Affordances of an object are those properties of
  the object which give users clues as to how the
  device is used
• Good examples include push buttons and levers
• Bad examples
• Pet hate is Web site design where links are not
  underlined and give no indication of how they
  should be used.

Button Graphic Traditional Rollover No
affordance
Gary
Gary
Gary
Gary
Gary
26
Affordance examples (UCT)
27
Mapping (Don Norman)

• Mapping is concerned with ensuring that there is
  a natural correlation between objects and the
  interface controlling them

This crops up with oven controls, light switches
and, our old friend, the car radio Beware of
cultural mappings as opposed to real mappings
28
Constraints (Don Norman)

• Constraining a design so that it can only be used
  the correct way
• Lego
• 3.5 disks
• Greyed menu options

29
Visualising (Don Norman / Ben Shneiderman)

• Features should be made visible - we talked about
  this earlier
• Bad (usually impoverished interface)
• Command lines
• Cellular phone menus
• Good
• Direct Manipulation
• Menu systems

30
Memory (Don Norman many others)

• Essentially memory comes in two flavours
• Short term
• Long term
• Short term memory is like RAM and can hold 72
  items at a time. This impacts issues like menu
  design
• Long term is like hard disk. Too complicated to
  go into here
• Also linked to cognitive models

31
Knowledge Chunking (Don Norman etc.)

• To improve on memory, we tend to chunk actions
• Chunking works by grouping actions into a lump
• Seek for meaningful relationships. Here is my UK
  cellphone number written two ways
• 0976 609766
• 09766 09766
• To help, we need to differentiate knowledge in
  head and knowledge in world
• Display based action
• Recognition vs. recall

32
Conceptual Models and task analysis (Don Norman
etc.)

• Task analysis techniques like GOMS, which you
  have covered already, help programmers think
  about the user goals and task closure
• ATM machines fail on the closure test
• Conceptual models require the programmer to
  think about how the user is conceptualising a
  problem and build an accurate representation
• When the user model and the computer model do not
  match, we have cognitive dissonance

33
Reverse Turing test (Harold Thimbleby)

• Humans should be treated at least as well as
  computers
• Explains why direct manipulation better than
  guided dialog (as per VCR timer recording)
• Sounds obvious, but this has huge impact on
  interface design
• We will look at this point a lot more in the case
  studies

34
Role Integrity (Harold Thimbleby)

• Interfaces should not mislead users about what
  the computer is capable of
• This usually applies to hidden limits such as
• Midi sequencers coping with only eight tracks
• Generally limits should be zero, one or infinity
• If the interface is capable of specifying a task,
  the computer should be able to complete it

35
Simpler is not always better (Harold Thimbleby)

• Einsteins Everything should be made as simple
  as possible, but not simpler
• Fewer buttons often seen as simpler, but not
  always the case
• Overloading buttons with modes
• Typewriters are easy to use
• My Navi-key Nokia is not

Complex looking buttons can be hid under a lid
36
Principle of least astonishment (Harold
Thimbleby)

• Consistency is obviously a key goal in interface
  design.
• This has been stated as
• The principle of least astonishment
• Consistency applies to functionality and form
• The car radio displays both types of
  inconsistency
• Button layout on face / button layout on remote
  control
• Functionality of RDS modes

37
Modes (Harold Thimbleby etc.)

• Modes allows different behaviours from the same
  interface features
• Not necessarily bad, but linked to poor feedback,
  can be awful
• Buttons 7-12 on the radio
• For users who are not aware that the mode has
  changed, this makes the device appear
  non-deterministic
• Polyas principle of Non-sufficient reason - if
  there is no reason to believe things are
  different, they arent

38
Equal opportunity (Harold Thimbleby Andy Monk)

• Equal opportunity states that there should be no
  difference between input and output values (or
  known / unknown) - one can be substituted for the
  other.
• Good examples include
• Spreadsheets - cells are neither input or output
  exclusively
• Camera aperture / shutter speed
• Zloof Query by Example

39
Principle of least effort (Harold Thimbleby)

• Zipfs principle of least effort can be rewritten
  as
• Make frequent things easy, unlikely things
  harder
• Similar to the simplicity idea, this manifests in
  the following ways
• Morse code E is only one dot, apostrophe is 6
  dots and dashes
• Menus organised to common things at top
• Dangerous operations could be heavily nested or
  require many clicks or presses

40
Feedback (Harold Thimbleby Isaac Newton)

• Newton taught us that every action in nature is
  met with a reaction - this is not always the case
  in interfaces
• Every user action needs the interface to react so
  that the user knows the action is complete
• this can be tricky in multi-tasking systems
• Especially important for displaying modal
  information

41
Fitts Law

• The time taken to acquire a target is a function
  of the distance to and size of the target
• For a target of size S, a distance D from the
  pointer, time is
• ablog2(D/S 1) (a and b depend on device
  characteristics)
• This has big implications for items such as menu
  design

42
Bruce Tog Tognazzini

• Somewhat of a character, Tog is well known as an
  outspoken proponent of good interface design
• Almost unique in HCI community he worked for a
  real company (Apple) and was responsible for
  designing real products (System 7 among them)
• He is not a whinge-bag

43
Togs ideas

• Anticipation / Autonomy
• Do not try to guess what your users want
• Give them some room to explore (more than an
  ATM, less than UNIX)
• Colour Blindness
• Never use as a primary queue
• Consistency
• Inconsistency just as important
• Defaults
• Never called Default easy to over-ride

44
Tog continued

• User efficiency
• Do not confuse machine with user efficiency
• Latency reduction
• Use threads!
• Use metaphors
• but not too much (what the heck is an analogy?)
• Protect your users

45
Genuine Usability

• We are going to look at some results from a
  usability test on mobile phones conducted by
  US-West
• Before we look at the results, what do you think
  of handset usability and how practice, age and
  instruction might affect it?
• Interesting study as purchasers are not the end
  user

46
Usability experiment

• US-West carried out a series of tests with a
  diversity of subjects
• They had to complete 28 tasks on 3 different
  handsets. Times were measured and compared
• Subjects were also interviewed about phone
  preferences

47
Task results

• Similar usability
• Plenty of room for improvement
• Varied success
• basic features good
• advanced / vertical services were awful
• Practice doesnt help much
• Very poor feedback
• possibly a problem of handset and network feature
  confusion
• Age makes a big difference

48
Consequences

• Reduced network usage
• Speed dials 16 success
• Save from call log 25 success
• many dont try
• Reduced usage of vertical services
• Vulnerability to competition

49
Manuals Instruction

• Can help with success
• Need to be tailored for age / gender etc.
• Fonts hard to read for elderly
• Poorly optimised dialog
• Call forwarding is on Vs.
• Your feature has been activated Vs
• stutter dialtone
• Instructions are age related
• Nintendo effect cross over point

50
Second experiment

• A second experiment was conducted to check
  physical attribute preference
• Before looking at the next page, what do you
  think are the attributes people look for
• size
• colour
• battery life
• Are attributes the same for different groups of
  people.

51
Results

• Long battery life is important
• for men
• for experienced users
• Smaller and lighter are good, unless
• you are an experienced user
• you are a kid
• Too small is bad
• Bigger displays important
• especially to elderly

52
Conclusions

• Manufacturers must resist Swiss Army phones
• creeping featurisim
• features as rewards like Nintendo
• Touch screens seem way forward
• Usability must improve to reduce calls to support
  line but increase calls to vertical services
• Network suppliers are not happy with usability
• Handset manufacturers are more likely to listen
  to service providers than individual customers

53
Using Design Rules

• Attempt to provide designers with information
  about impact of their designs
• Always a trade-off - the more general the rule,
  the more chance it conflicts with another rule
• We can make a vague distinction between

Guidelines vague, need to know theoretical
underpinning Standards can be very specific, e.g
3-button mice used
Guidelines
Generality
Standards
Authority
54
Standards

• Usually set by international committee
• Hardware standards more specific than software
• Hardware less likely to change
• Strength lies in forcing a large community to
  follow standard
• Currently not much for promoting usability tend
  towards de facto standards

55
Guidelines

• Style guides published by Apple, Sun etc.
• Tend to be generalisations - the more general,
  the earlier they should be in the design process
• Can range from
• Users must initiate all dialog (Apple)
• to
• Use white space between long groups of menu
  controls (Open Look)

56
Summary

• Standards
• High authority
• Little overlap
• Limited application
• Minimal interpretation

• Guidelines
• Lower Authority
• Conflicts / overlap / trade-
• off
• Less focused
• Interpretation required -
• HCI background

57
Web Guides

• For the coursework, you will need to find a style
  guide for the site design
• As there are so many styles of site, make sure
  you find one which suits the site you are
  interested in
• I will give you a list of style guides, but here
  are some good design rules from Jakob Nielsen
  (Web guru)
• http//www.useit.com

58
To 10 points of bad design

• Breaking the back button
• Opening browser windows
• Non-standard use of widgets
• Lack of biography
• No archives
• Moving URLs
• Smart headlines
• Buzzwording
• Slow sites
• Any advertising, or similar graphic

59
Writing for the Web

• Simplicity and informality
• Credibility
• Outbound links for credibility
• Low humour
• Speed
• Scanable text (bullet points)
• Concise (half word count of other media)
• Summaries / Inverted pyramid
• Graphics and text integrated
• Check Strunk and White