Interaction Models of Humans and Computers

1
Interaction Models of Humans and Computers

• CS2352 Lecture 7
• Robert Stevens
• http//www.cs.man.ac.uk/stevensr

2
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

3
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

4
Spectrum of Interaction
Command Line
GUI
Batch Process
Virtual Reality
5
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

6
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

7
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
• Users language is the task language Describes
  cognitive, psychological attributes of the domain
  relevant to the user
• Cf Model Information Processor

8
Problem Space

• Domain boundded by problem space
• Task analysis can define problem space
• Also find domain concepts, tasks, goals and
  intentions
• CF UML diagrams

9
Execution and Evaluation
Evaluation
System
User
Execution
10
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.

11
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

12
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

13
Gulfs of Execution and Evaluation

• User and system express goals and tasks in
  different languages
• If users and systems model of world, domain
  concepts, goals, tasks, etc. dont 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

14
Interaction Framework

• Extension of Normans model
• Normans 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

15
Interaction Framework Diagram
task
Core
16
Translations

• 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
• Observation
• Input and output languages form the user
  interface and can adopt many styles
• Translation from the articulation of the users
  plan to its performance on the system dictates
  ease of interaction

17
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

18
The Gas Hob
19
Translating Input

• Input language translated to the systems core
  language
• Can the input reach all the states of the system
  necessary?
• Video remote controls and power buttons
• Remote controls 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

20
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

21
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

22
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

23
HCI Interaction Framework
Screen Design
Output
Ergonomics
System
User
Input
Dialog
24
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