Characteristics of Good HumanComputer Dialogues

1
Characteristics of Good Human-Computer Dialogues

• Howell Istance

2
Overview

• Types of dialogues
• Message passing in dialogues
• Initiative in dialogues
• Characteristics of Good Dialogues
• Consistency
• Support
• Feedback
• Minimal input
• Flexibility

3
Types of Dialogues

• Message passing model
• Dialogue is viewed as an exchange of messages of
  different types between the human and the
  computer, rather like a human-human dialogue.
• Object-oriented model
• Dialogue allows the user to manipulate objects
  represented in the computer, and the computer
  responds by showing the current state of the
  objects.
• interface objects - windows, buttons etc.
• application objects - paragraph, appointment,
  customer order etc.

4
Message passing in dialogues
control
S Y S T E M
Input
data
prompt
data
status
Output
error
help
5
Message passing in dialogues

• Input control user directs way in which
  dialogue will proceed
• data data supplied by user
• Output prompt request for user input
• data data from application following user
  request
• status acknowledgment that something has
  happened
• error processing cannot continue
• help additional information to user

6
Messages in human-human dialogue

• (long period of phone ringing....)
• British Rail enquiries.
• Can I help you?
• Yes, I want to check an arrival time please.
• For which train sir?
• The 14.05 from Leicester to London.
• On which day?
• Saturday.
• There is no 14.05 on Saturdays.
• Oh. When are the trains on Saturday?
• Theres the 14.30, the 15.15 and the 16.00.
• How about the 14.30?
• That gets in at 15.50.

7
Messages in human-human dialogue
(status) (prompt) (input control) (prompt) (input
data) (prompt) (input data) (error) (input
control) (help) (input data) (output data)

• (long period of phone ringing....)
• British Rail enquiries.
• Can I help you?
• Yes, I want to check an arrival time please.
• For which train sir?
• The 14.05 from Leicester to London.
• On which day?
• Saturday.
• There is no 14.05 on Saturdays.
• Oh. When are the trains on Saturday?
• Theres the 14.30, the 15.15 and the 16.00.
• How about the 14.30?
• That gets in at 15.50.

8
Initiative and dialogue styles

• Computer initiates dialogue
• Question and answer (interview analogy)
• Menu (menu analogy)
• Hypertext or embedded icons (can be seen as a
  type of menu)
• Form fill (paper form analogy)
• User initiates dialogue
• Command (parade ground analogy)
• Mixed mode dialogues
• Very common situation
• Uses several of the above styles
• e.g. form-fill dialogues with scrollable menus to
  provide input

9
Characteristics of good dialogues

• Consistency
• Appropriate User Support
• navigation information
• instructions
• error messages
• provision of help
• Adequate feedback from system
• Minimal user input
• Flexibility
• Good visual appearance
• Close match to tasks of user

10
Characteristics of good dialogues

• Consistency
• Appropriate User Support
• navigation information
• instructions
• error messages
• provision of help
• Adequate feedback from system
• Minimal user input
• Flexibility
• Good visual appearance
• Close match to tasks of user

General
11
Characteristics of good dialogues

• Consistency
• Appropriate User Support
• navigation information
• instructions
• provision of help
• error messages
• Adequate feedback from system
• Minimal user input
• Flexibility
• Good visual appearance
• Close match to tasks of user

General
Application specific
12
Consistency

• what is about car design which lets people
  transfer driving skills between different makes
  of car?
• keeping key design features consistent (type of
  steering control, arrangement of pedals,
  operation of gears)
• still permits individual styling of cars
• consistency doesn't mean all cars look the same
• list 4 features associated with the 'drivability'
  of graphical interfaces

13
Consistency

• Commands
• usage of command names
• standard key bindings
• e.g. ESC always cancels previous command
• F1 always displays help screen
• syntax
• Format for data entry
• Layout
• consistent use of screen areas so the user knows
  where to look for instructions, error messages
  and status information.
• Information coding
• colour
• highlighting

14
(No Transcript)
15
(No Transcript)
16
Screen from Currency Trading Information System

• 23.34 34.43 23.56 56.76 12.23 12.73
• 45.76 38.22 63.78 56.66 14.53 11.53
• 46.77 32.78 62.88 56.66 15.76 11.87
• 44.32 33.60 62.86 55.31 15.21 12.31
• 23.34 34.43 23.56 56.76 12.23 12.73
• 45.76 38.22 63.78 56.66 14.53 11.53
• 46.77 32.78 62.88 56.66 15.76 11.87
• 44.32 33.60 62.86 55.31 15.21 12.31
• 23.34 34.43 23.56 56.76 12.23 12.73
• 45.76 38.28 63.78 56.66 14.53 11.53
• 46.77 32.78 62.88 56.66 15.76 11.87

17
Another Screen from Same Currency Trading
Information System

• 23.34 34.43 23.56 56.76 12.23 12.73
• 45.76 38.22 63.78 56.66 14.53 11.53
• 46.77 32.78 62.88 56.66 15.76 11.87
• 44.32 33.60 62.86 55.31 15.21 12.31
• 23.34 34.43 23.56 56.76 12.23 12.73
• 45.76 38.22 63.78 56.66 14.53 11.53
• 46.77 32.78 62.88 56.66 15.76 11.87
• 44.32 33.60 62.86 55.31 15.21 12.31
• 23.34 34.43 23.56 56.76 12.23 12.73
• 45.76 38.22 63.78 56.66 14.53 11.53
• 46.77 32.78 62.88 56.66 15.76 11.87

18
Consistency

• Inconsistency is reduced by
• definition of and adherence to agreed style and
  standards
• use of software structures which encourage global
  definition of interface characteristics

19
Appropriate user support

• HELP messages
• important to recognise different types of help
• should be available when required and
  context-specific
• can the user get help about what responses are
  possible at a given point in a dialogue.
• ERROR messages
• should explain what is wrong and what corrective
  action is required
• should use jargon familiar to the user
• often this support is poorly designed in terms of
  what information is given to the user.

20
Feedback from the system

• Every action the user makes should produce a
  perceptible response.
• Response time for feedback should be appropriate
  to the type of user action
• e.g. response to keystroke - instantaneous res
  ponse to command input - may take longer.
• Current object should be highlighted
• window
• icon or graphic object.
• Provide system busy feedback if time will
  exceed a few seconds or is unpredictable.

21
Feedback from the system

• Provide indication of how many transactions
  remain, for example as a bar chart or as a
  percentage.
• The intention is to reduce user uncertainty that
  the system has
• received the last input,
• is currently doing something about it,
• or is waiting for the next input.

22
Minimal user input

• Balance between number of keystrokes or mouse
  movements/clicks and memory load.
• Reducing keying errors increases speed of data
  entry.
• Allow selection from a list rather than typing in
  a value (recognise rather than recall).
• Edit a command that has produced an error rather
  than retyping the command.
• Do not request input of information which can be
  derived automatically or which has been entered
  previously.
• Use default values.

23
Flexibility

• Measure of how well a dialogue can cater for
  different levels of user skill.
• Provide alternative means of achieving the same
  goal which match different models of how the
  interface works.
• e.g. word selection cursor to start of word and
  double click, click and drag, click and
  shift-click.
• e.g. word deletion word highlighted and Control
  X key, select Cut menu option, backspace.

24
Flexibility

• Adapt to the skill level of the user by
• providing acceleratorsallow user to answer
  ahead,provide key bindings for menu options
• providing macro facility
• accepting abbreviations for command words
• accepting synonyms (alternative names)
• allowing user to choose level of instructions or
  help.

25
Heuristics (after Shneiderman)

• strive for consistency
• enable frequent users to use shortcuts
• offer informative feedback
• design dialogues to yield closure
• offer simple error handling
• permit easy reversal of actions
• support internal locus of control
• reduce short term memory load

26
Heuristics (after Neilsen)

• use simple and natural dialogue
• speak the users language
• minimize user memory load
• be consistent
• provide feedback
• provide clearly marked exits
• provide shortcuts
• provide good error messages
• prevent errors

27
Windows Interface Guidelines

• set of general principles for interface design
  in Microsoft's software development documentation

• forgiveness
• feedback
• aesthetics
• simplicity

• directness
• user in control
• consistency

28
Directness (after Microsoft)

• allow users to directly manipulate software
  representations of information.
• users should see how the actions they take affect
  the objects on the screen.
• Visibility of information and choices also reduce
  the user's mental workload.
• Users can recognize a command easier than they
  can recall its syntax.

29
User in control (after Microsoft)

• user initiates actions, not the computer or
  software
• use techniques to automate tasks, but implement
  them in a way that allows the user to chose or
  control the automation.
• users must be able to personalize aspects of the
  interface, such as color, fonts, or other options

30
Consistency (after Microsoft)

• allows users to transfer existing knowledge to
  new tasks and focus more on tasks because they
  need not spend time trying to remember the
  differences in interaction.
• makes the interface familiar and predictable. by
  providing a sense of stability
• important through all aspects of the interface,
  names of commands, visual presentation of
  information, and operational behavior.

31
Forgiveness (after Microsoft)

• Users like to explore an interface and often
  learn by trial and error.
• An effective interface allows for interactive
  discovery.
• It provides only appropriate sets of choices and
  warns users about potential situations where they
  may damage the system or data, or better, makes
  actions reversible or recoverable.

32
Feedback (after Microsoft)

• Always provide feedback for a user's actions.
• Visual, and sometimes audio, cues should be
  presented with every user interaction to confirm
  that the software is responding to the user's
  input and to communicate details that distinguish
  the nature of the action.

33
Aesthetics (after Microsoft)

• visual design is an important part of a
  software's interface.
• important to remember that every visual element
  that appears on the screen potentially competes
  for the user's attention.
• Provide a pleasant environment that clearly
  contributes to the user's understanding of the
  information presented.

34
Simplicity (after Microsoft)

• An interface should be simple (not simplistic),
  easy to learn, and easy to use.
• It must also provide access to all functionality
  provided by an application.
• Maximizing functionality and maintaining
  simplicity work against each other in the
  interface.
• An effective design balances these objectives.

35
Summary

• Human-computer dialogues can be viewed as an
  exchange of messages or the user changing the
  state of application objects.
• Dialogues can be designed to assist the user
  through
• Consistency
• Support
• Feedback
• Minimal input
• Flexibility
• Several similar lists of good design principles