Interaction Models of Humans and
Computers
CS2352: Lecture 7
Robert Stevens
http://www.cs.man.ac.uk/~stevensr
http://img.cs.man.ac.uk/stevens
1
Introduction
•
•
•
•
•
•
How do humans use computers?
What is going on between human and computer?
Models of interaction
Models of interaction and system design
Why are such models useful?
Translating between human requirements and system
capabilities
http://img.cs.man.ac.uk/stevens
2
Basic System Needs
• A tool for performing, simplifying or supporting a task
• User must communicate this task in a language the computer
understands
• The computer mustcommunicate the change in state to the user
in a human understandab05le language
• The model information processor
http://img.cs.man.ac.uk/stevens
3
Spectrum of Interaction
Batch Process
Command Line
GUI
http://img.cs.man.ac.uk/stevens
Virtual Reality
4
What Does a Model Tell Us?
–
–
–
–
–
Model helps us understand the nature of HCI
Understanding of where problems may arise
The fundamental nature of that problem
A framework for comparing interaction styles
Choosing appropriate interaction styles
http://img.cs.man.ac.uk/stevens
5
Definition of Terms
– Domain: Graphic design, Document preparation, biological
sequence analysis, computer aided design
– Domain concepts: Highlight important features – in Graphic Design:
Geometric shape, drawing surface and drawing utensil
– Task: A sequence of operations performed upon concepts in the
domain
– Goal: Desired output from a task – drawing a particular geometric
shape with specified attributes
– Intention: A specific action required to meet a goal
• Goal
• Core Language
• Task Language
http://img.cs.man.ac.uk/stevens
6
System and User Languages
•
•
•
•
User and system distinct entities
Each described by a language
These languages can describe concepts of that domain
System language is the core language: Describes computational
attributes of the system state relevant to the domain
• User’s language is the task language: Describes cognitive,
psychological attributes of the domain relevant to the user
• Cf Model Information Processor
http://img.cs.man.ac.uk/stevens
7
Problem Space
•
•
•
•
Domain boundded by problem space
Task analysis can define problem space
Also find domain concepts, tasks, goals and intentions
CF UML diagrams
http://img.cs.man.ac.uk/stevens
8
Execution and Evaluation
Evaluation
User
System
Execution
http://img.cs.man.ac.uk/stevens
9
Execution & Evaluation Cycle
1. establishing the goal
2. forming the intention
3. specifying the action sequence
4. executing the action
5. perceiving the system state
6. interpreting the system state
7. evaluating the system state with respect to the goals and
intentions.
http://img.cs.man.ac.uk/stevens
10
Supporting Execution & Evaluation
• Design to allow the user to effectively & efficiently execute and
evaluate
• Languages in which to articulate plans : Unix command
language; WIMPS
• Languages to execute plans: Event models; message passing,
programming languages
• Design for execution evaluation: Has that button been pressed;
what was the result of pressing the button
• Observing the state of the system: Typeface, font, page size –
“what you see is what you get”
http://img.cs.man.ac.uk/stevens
11
Formulating Tasks
User formulates goal in terms of the domain concepts
Expressed in a task language
Liable to be imprecise
Translated to firm intention within a task and its operations that
will reach the goal
After execution, the user will obserbe the system state to see if
the goal has been reached
If not, reformulation takes place and the cycle repeated
http://img.cs.man.ac.uk/stevens
12
Gulfs of Execution and Evaluation
• User and system express goals and tasks in different languages
• If user’s and system’s model of world, domain concepts, goals,
tasks, etc. don’t match, then there is a gulf
• Gulf of evaluation & gulf of execution
• If actions allowed by system match to those the user expects to
fulfil his/her goal, then no gulf
http://img.cs.man.ac.uk/stevens
13
Interaction Framework
• Extension of Norman’s model
• Norman’s model only deals with the user
• The system has a model of the task and a mechanism for
displaying that model for evaluation
• Any interaction model should include the system
• Input & output explicit components and form the interface
• Each has own, though possibly overlapping languages
• Buttons in GUI form part of an input and output language
http://img.cs.man.ac.uk/stevens
14
Interaction Framework Diagram
presentation
Output
System
User
task
Core
performance
observation
Input
http://img.cs.man.ac.uk/stevens
articulation
15
Translations
•
1.
2.
3.
four main translations involved in the interaction:
Articulation: task language translated to input language
Performance: Input language translated to core language
presentation – core language translated to output language
after system state change and
4. Observation
• Input and output languages form the user interface and can
adopt many styles
• Translation from the articulation of the user’s plan to its
performance on the system dictates ease of interaction
http://img.cs.man.ac.uk/stevens
16
Ease of Translation
•
•
•
•
•
Concepts of application domain need to be clear in the user interface
Help form good mental model
User needs to map easily from task language to input language
Ease of articulation – Gulf of execution
VR eases articulation by making the everyday part of input language
http://img.cs.man.ac.uk/stevens
17
The Gas Hob
http://img.cs.man.ac.uk/stevens
18
Translating Input
•
•
•
•
Input language translated to the system’s core language
Can the input reach all the states of the system necessary?
Video remote controls and power buttons
Remote control’s input language cannot reach off state of
system
• Match task analysis or activity diagrams to use cases and
class/collaboration diagrams
• Small cost ot user, larger cost in implementation
http://img.cs.man.ac.uk/stevens
19
Ease of Evaluation
• Performance of task transforms state
• Translate state from core to output language
• Must preserve state of system attributes in terms of domain
concepts as presented by output language
• Output language often limited in expressivity
• Video simply limited in size – difficult to see context in
documents etc.
• Results of file copy in command system
http://img.cs.man.ac.uk/stevens
20
Judging a System
•
•
•
•
•
•
Assess overall usability of system
Really evaluate in terms of current tasks, bundles of tasks
Only by performing a domain task can a system be judged
Not all systems good at all tasks
Choose system that does most tasks well most of the time
Word poor for text processing via regular expressions – use
Emacs or VI
http://img.cs.man.ac.uk/stevens
21
Frameworks and HCI
• Framework used to co-ordinate HCI issues
• Ergonomics: Physical aspects of input and output – the user
side
• Dialogue Design: Task articulation and performance – the
system side
• Rendering State: Presenting system state for evaluation – user
and system sides
http://img.cs.man.ac.uk/stevens
22
HCI & Interaction Framework
Screen
Design
Output
System
Ergonomics
User
Input
Dialog
http://img.cs.man.ac.uk/stevens
23
Summary
•
•
•
•
•
•
•
A holistic view of human and computer interactions
Users have goals
These are articulated upon an input device
Executed upon the system
The system state is rendered upon an output device
The user evaluated the effects of his/her actions
Translating across these divides determines usability
http://img.cs.man.ac.uk/stevens
24
Descargar

Evaluation