Software Engineering: Analysis and Design - CSE3308

1
Software Engineering Analysis and Design -
CSE3308
CSE3308/DMS/2002/17
Monash University - School of Computer Science
and Software Engineering

• Conceptual Issues in Human-Computer Interaction

2
Lecture Outline

• CLINTs and WIMPs
• What is Human-Computer Interaction?
• Models and HCI
• An example of the role of models
• The need for design
• Principles for design
• POET - a design method

3
CLINTs and WIMPs

• CLINT - Command Line INTerfacer
• WIMPs - Windows, Icons, Mice, Pointing
• Over the last 4 decades, have migrated from
  CLINTs to WIMPs
• The vast majority of computer users will run
  screaming from a command line interface
• The GUI is now king of our screens, but is
  unlikely to stay enthroned forever
• Voice-based systems
• Virtual Reality-based systems

4
What is Human-Computer Interaction?

• The ways and means by which humans use computers
• The interaction between humans and their
  computers occurs through what is known as the
  user interface
• The User Interface is the System
• If the User Interface is poor, then the system is
  poor
• The User Interface is a necessary but not
  sufficient part of building a good system

5
Models

• People build mental models of how the world works
• People form these models through experience,
  training and instruction
• These mental models are often wrong in principle,
  but correct in effect
• In software development, we have three mental
  models which we are concerned with
• The Implementation Model
• The System Model
• The User Model

6
The interaction between the three models
Implementation Model
User Model
Designer
User
System
System Model
7
Which model should the System Model match?
Better
Worse
System Models
User Model reflects users vision
Implementation Model reflects technology
8
Models and User Interfaces

• Mental models are generally simpler than reality
• Mental models dont have to be true or accurate,
  so long as they are effective
• Example - many users see the screen as the centre
  of the computer where the work is done
• Software which has a system model similar to the
  users mental model reduces the complexity of an
  interface
• Most software conforms to the implementation model

9
The Baffling Case of the File System

• The current file systems used in all systems are
  based on the implementation model, not the user
  model
• The current file system is an endless source of
  user problems and frustration
• Very few people even question whether it can be
  done a different way!
• Users view files in the same way as they view
  documents in the real world, but this is not
  correct

10
The real world analogy to using a file

• Compare with using a book from a shelf

1. Make a photocopy of the book on the shelf 2.
Scribble any changes you want to make on the
photocopy 3. Burn the original book on the
shelf 4. Place the scribbled-on photocopy where
the original was
11
The current filing system

• Differentiates between the copy on the hard disk
  and the copy in RAM
• Use of Hard Disks is purely a technical issue
  driven by cost, has nothing to do with the usage
  of the filing system
• The ability to lose all your changes and revert
  to the old version prior to saving is a
  side-effect and a dangerous side-effect
• The existence of two versions of the same
  document simultaneously is greatly confusing

12
A solution in tune with the users mental model

• What are the goals of a file system for the user?
• Saving changes to the document
• Create a copy of the existing document
• Naming and renaming the document
• Placing and repositioning the document
• Specifying the stored format of the document
• Creating a milestone copy of the document
• Reversing some changes
• Abandoning all changes

13
Addressing the requirements

• Saving changes to the document
• With modern technology, we can save often
  automatically
• Save when the user stops rather than when
  actually typing
• Manual save facility for the paranoid
• Creating a copy of the document
• Add a command Make Snapshot Copy
• Give copy standard name like Copy of Alpha and
  put it in the same directory
• Should just happen, no dialog box
• Naming and renaming the document
• Name in the title bar should be editable

14
Addressing the requirements (2)

• Placing and repositioning the document
• All documents placed in file system in default
  location
• Explicit command on the menu to move to a
  different location, if necessary
• Specifying the stored format of the document
• Currently tied in with the file system
• Not actually part of the file system, but is
  actually a property of the document
• Very rare occurrence, shouldnt be tied to saving
  the document

15
Addressing the requirements (3)

• Making a Milestone copy of the document
• creates a version of the document to be stored
  separately in the file system
• similar technology is already used in revision
  control systems
• Simple to revert back to a milestone when we need
  to
• Abandoning all changes
• a facility on the menu to abandon all changes
  since the document was opened with appropriate
  warnings
• facility should also be undoable for a week or
  two
• Reversing some changes
• use a multi-level undo

16
The New Menu

• Menu now reflects the users mental model instead
  of the implementation model
• there is one document and the user owns it and
  can control its behaviour easily and in detail
• No need for the user to worry about copies in RAM
  and disk

17
The New Menus Appearance
Document
New Open... Close Rename/Reposition Make
Snapshot Copy
Make Milestone Revert to Milestone...
Document Properties...
Abandon Changes
Close
18
The Need for Design

• As can be seen by the File Menu example, there is
  still room for considerable improvement in user
  interfaces
• By applying good design principles to the tasks
  that users perform we can produce far better user
  interfaces
• The result is more work for developers, but more
  productive and better-selling software for users

19
Five fallacies

• The design is satisfactory for me - therefore it
  will be satisfactory for everybody
• This design is satisfactory for the average
  person - it will therefore be satisfactory for
  everybody else
• The variability of human beings is so great than
  it cannot be catered for in any design - but
  since people are wonderfully adaptable it doesnt
  matter anyway
• Good interfaces are expensive and since products
  are usually purchased on appearance and styling,
  we can ignore interface design
• Good interfaces are an excellent idea, I always
  design things with this in mind, but I do it
  intuitively and rely on my common sense, so I
  dont need to test it

20
Design Principles

• Affordances
• Being aware of the mental models in the system
• Making things visible
• The principle of mapping
• The principle of feedback

21
Affordances

• The perceived and actual properties of the thing,
  primarily those fundamental properties that
  determine just how the thing could possibly be
  used
• Examples
• The handle on a door
• A 3-D pushbutton on a toolbar
• Affordances are far more compelling than written
  instructions

22
Making things visible

• The functions in a system should be visible
• Example - the Telephone
• standard telephone has 15 function buttons
• most functions use the and button
• the button has no relationship to the function
• How many people can set up a three-way call or
  remember how to turn off call waiting?
• Counter example - the Car
• Many more buttons, but each button generally has
  one purpose and is labelled
• people have far less problems in a strange car as
  opposed to their own telephone
• Visibility acts as a reminder of what can be done
  and how it is done

23
The principle of mapping

• Mapping is the relationship between two things
• for example, the steering wheel of a car, when it
  is turned right, the car turns right, when turned
  left, the car turns left
• By using natural mappings, the designer can make
  actions easily learned and always remembered
• e.g. spatial analogies to move an object up,
  move the control up
• e.g. other physical analogies a louder sound
  means more, a quieter sound means less

24
The principle of feedback

• Sending information back to the user on what
  action has actually been performed and what
  result has been accomplished
• Feedback needs to be timely
• Example - Keyboards can easily be made to be
  silent, but a good keyboard will have a nice
  satisfying click!

25
How people do things

• An approximate model - Seven Stages of Action
• Three basic areas
• Goals - what does the user want, i.e. their
  expectations of and intentions for the device?
• Execution - how does the user achieve the goals
  with the device
• Evaluation - how does the user know whether their
  goals have been met?
• Gulf of Execution
• the distance between the intentions of the user
  and the allowable actions
• Gulf of Evaluation
• the amount of effort the user must exert to
  interpret the physical state of the device and
  how well it satisfied the users intentions and
  expectations

26
The Seven Stages of Action
Goals
Evaluation of interpretations
Intention to act
Interpreting the perception
Sequence of actions
EVALUATION
EXECUTION
Execution of the action sequence
Perceiving the state of the world
The World
27
Using the seven stages to assess a design
How easily can one
Determine the function of the device?
Tell what actions are possible? Determine
mapping from intention to physical
movement? Perform the Action?
Tell if the system is in the desired
state? Determine mapping from system state to
interpretation? Tell what state the system is in?
28
POET - a design method

• The Psychology of Everyday Things - Donald Norman
  - Apple Fellow
• (new edition of book retitled The Design of
  Everyday Things)
• Address the goals of the user
• Use both knowledge in the head and knowledge in
  the world
• Simplify the structure of tasks
• Make things visible, bridge the gulfs of
  Execution and Evaluation
• Get the mappings right
• Exploit the power of constraints, both natural
  and artificial
• Design for error
• When all else fails, standardise

29
POET - A design method (2)

• Address the goals of the user
• Dont allow the implementation model to rule the
  way things are done
• Use knowledge in the head and knowledge in the
  world
• People learn better and feel more comfortable
  when the knowledge needed to do the job is
  available externally
• But knowledge in the world must have a natural,
  easily interpreted relationship between that
  knowledge and the information it is intended to
  convey about possible actions and outcomes
• Knowledge in the head improves performance, so
  the design should not impede experienced users
  with that knowledge
• Knowledge in the head is only available within a
  context

30
POET - a design method (3)

• Simplify the structure of the tasks 4 ways
• Keep the task much the same but provide mental
  aids
• e.g. providing a drop-down list box of postcodes
• Use technology to make things visible and reduce
  memory load
• the automatic spelling check function in Word 97
• Remove some parts of the task with automation
• e.g. filling in the suburb field based on the
  postcode
• Change the nature of the task
• e.g have a web page and let the user fill in the
  details
• Simplify, but dont take control away from the
  user

31
POET - a design method (4)

• Make things visible
• Bridge the Gulf of Execution by
• letting people know what is possible
• letting people know how actions are performed
• Bridge the Gulf of Evaluation by
• showing people the effects of their actions
• Actions should match intentions and expectations
• The system state should be readily perceivable
  and interpretable
• The system state should match the users
  intentions and expectations

32
POET - a design method (5)

• Get the mappings right
• between intentions and possible actions
• between actions and their possible effects on the
  system
• between actual system state and what the user can
  perceive
• between the perceived system state and the needs,
  intentions and expectations of the system
• Exploit the power of constraints
• use constraints so that the user feels there is
  only one choice
• the right one
• reduce the possible number of actions at any stage

33
POET - a design method (6)

• Design for error
• Assume any error can be made and plan for it
• Support, dont fight the users response
• Allow recovery from errors
• Dont straitjacket the user
• what you think is an error may be normal
  behaviour in the system
• When all else fails, standardise
• If there must be arbitrary mappings, standardise
  the layout
• Standards are hard to agree upon
• Users must be trained in standards

34
The Backwards Clock
12
1
11
2
10
3
9
8
4
5
7
6
35
References

• Norman, Donald A, The Design of Everyday Things,
  Currency/DoubleDay, 1990(previously published as
  The Psychology of Everyday Things, Basic Books,
  1998)