1. Software Engineering: Analysis and Design - CSE3308
CSE3308/CSC3080/DMS/2000/14
Monash University - School of Computer Science and Software Engineering
Software Engineering: Analysis and Design - CSE3308
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?
Worse
Better
System Models
User Model
reflects user’s
vision
Implementation
Model reflects
technology

8. Models and User Interfaces
Mental models are generally simpler than reality
Mental models don’t 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 user’s 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 user’s 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, shouldn’t 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 user’s 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 Menu’s 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 doesn’t 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 don’t 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 user’s intentions and expectations

26. The Seven Stages of Action
Goals
Evaluation of
interpretations
Intention to act
Sequence of actions
Interpreting the
perception
EXECUTION
EVALUATION
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 of 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
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
Don’t 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 don’t 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 user’s 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, don’t fight the user’s response
Allow recovery from errors
Don’t 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 4 8 5 7 6