1 interaction models of humans and computers cs2352: lecture 7 robert stevens stevensr

1http://img.cs.man.ac.uk/stevens

Interaction Models of Humans and ComputersCS2352: Lecture 7

Robert Stevens

http://www.cs.man.ac.uk/~stevensr


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


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


Spectrum of Interaction

Batch Process Command Line GUI Virtual Reality


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


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


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


Problem Space

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


Execution and Evaluation

System User

Evaluation

Execution


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.


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”


Formulating TasksUser 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


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


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


Interaction Framework Diagram

System User

Output

Input

presentation

performance

observation

articulation

taskCore


Translations

• four main translations involved in the interaction:

1. Articulation: task language translated to input language

2. Performance: Input language translated to core language

3. 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


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


The Gas Hob


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


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


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


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


HCI & Interaction Framework

System User

Output

Input

Screen Design

Dialog

Ergonomics


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

1 interaction models of humans and computers cs2352: lecture 7 robert stevens stevensr

Documents

domain system language

system design

task user

system state relevant

system capabilities

basic system

domain users language

user languages user