1http://img.cs.man.ac.uk/stevens Interaction Models of Humans and Computers CS2352: Lecture 7 Robert Stevens

2http://img.cs.man.ac.uk/stevens 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

3http://img.cs.man.ac.uk/stevens 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

4http://img.cs.man.ac.uk/stevens Spectrum of Interaction Batch Process Command Line GUI Virtual Reality

5http://img.cs.man.ac.uk/stevens 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

6http://img.cs.man.ac.uk/stevens 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

7http://img.cs.man.ac.uk/stevens 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

8http://img.cs.man.ac.uk/stevens Problem Space Domain boundded by problem space Task analysis can define problem space Also find domain concepts, tasks, goals and intentions CF UML diagrams

9http://img.cs.man.ac.uk/stevens Execution and Evaluation System User Evaluation Execution

10http://img.cs.man.ac.uk/stevens 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.

11http://img.cs.man.ac.uk/stevens 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”

12http://img.cs.man.ac.uk/stevens 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

13http://img.cs.man.ac.uk/stevens 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

14http://img.cs.man.ac.uk/stevens 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

15http://img.cs.man.ac.uk/stevens Interaction Framework Diagram SystemUser Output Input presentation performance observation articulation task Core

16http://img.cs.man.ac.uk/stevens 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

17http://img.cs.man.ac.uk/stevens 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

18http://img.cs.man.ac.uk/stevens The Gas Hob

19http://img.cs.man.ac.uk/stevens 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

20http://img.cs.man.ac.uk/stevens 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

21http://img.cs.man.ac.uk/stevens 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

22http://img.cs.man.ac.uk/stevens 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

23http://img.cs.man.ac.uk/stevens HCI & Interaction Framework SystemUser Output Input Screen Design Dialog Ergonomics

24http://img.cs.man.ac.uk/stevens 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