CMC/CC A Task Analysis Master IK, CIW, MMI L.M. Bosveld-de Smet Hoorcollege 4; ma. 25 sept. 2006;

Goals of system engineering Adequate functionality  What tasks and subtasks must be carried out?  Task analysis is central! Reliability Standardization Schedule and budgetary planning  Attention to human factors  Rigorous testing

Process of design in HCI Requirements  what is wanted? Analysis  Task models – means to capture how people carry out tasks Design  Modeling and describing interaction  Theories, design principles (basic heuristics), guidelines Iteration and prototyping Implementation and deployment

Task Analysis Process of analyzing the way people perform their jobs Essential part of Requirements Analysis Essential part of HCI Design Failure may result in serious usability problems

Task Analysis: different approaches Task decomposition  Looks at the way a task is split into subtasks, and the order in which these are performed Knowledge-based techniques  Look at what users need to know about the objects and actions involved in a task, and how that knowledge is organized Entity-relation-based analysis  Object-based approach, where emphasis is on identifying actors and objects, the relationships between them and the actions they perform

Task Decomposition: HTA example 0.In order to clean a house 1. get the vacuum cleaner out 2. fix the appropriate attachment 3. clean the rooms 3.1. clean the hall 3.2. clean the living rooms 3.3. clean the bedrooms 4. empty the dust bag 5. put the vacuum cleaner and attachments away Plan 0: do in that order; when the dust bag gets full do 4. Plan 3: do 3.1 every day; do 3.2 once a week; when visitors are due do 3.3

HTA: making a cup of tea 0. make a cup of tea 1. Boil water 2. Empty pot 3. Put tea leaves In pot 4. Pour in boiling water 5. Wait 4 or 5 minutes 6. Pour tea 1.1. Fill kettle 1.2. Put kettle on hob 1.3. Wait for kettle to boil 1.4. Turn off gas Plan 0 Do1; at the same time, if the pot is full do2; Then do 3-4; After 4 or 5 minutes do 6 Plan 1 Do When kettle boils do 1.4

HTA for making lots of cups of tea 0. make cups of tea 1. Boil water 2. Empty pot 3. Make pot 3.3. Pour in boiling water 4. Wait 4 or 5 minutes 5. Pour tea 1.1. Fill kettle 1.2. Put kettle on hob 1.4. Wait for kettle to boil 1.5. Turn off gas Plan 0 Do1; at the same time, if the pot is full do2; Then do 3-4; After 4 or 5 minutes do 5 Plan 1 Do When kettle boils do Turn on and light gas 3.2. Put tea leaves in pot 3.1. Warm pot Ask guest about sugar Add sugar to taste 5.1. Put milk in cup 5.2. Fill cup with tea 5.3. Do sugar Plan Plan if wanted 5.3.2

HTA for making lots of cups of tea Plan 5 (pour tea) for each guest 5.3 empty cups ? NO YES

Types of plan Fixed sequence Optional tasks Waiting for events Cycles Time sharing Discretionary Mixtures

Knowledge-based analysis Listing of all objects and actions involved in task Building taxonomies One technique:  task analysis for knowledge description (TAKD) Task descriptive hierarchy (TDH)

Knowledge-based analysis: example Kitchen item OR preparation mixing bowl, plate, chopping board cooking frying pan, casserole, saucepan dining plate, soup bowl, casserole, glass

Knowledge-based analysis: example TAKD Kitchen item AND /_ shape XOR / |_ dished / | mixing bowl, casserole, sauce pan, soup bowl, glass / |_ flat / plate, chopping board, frying pan /_ function OR {_ preparation { mixing bowl, plate, chopping board {_ cooking { frying pan, casserole, sauce pan {_ dining XOR |_ for food | plate, soup bowl, casserole |_ for drink glass

Knowledge-based analysis: example TDH for actions Kitchen job OR |__ preparation | beating, mixing |__ cooking | frying, boiling, baking |__ dining pouring, eating, drinking

Sources for task analysis Documentation Domain expert opinion Direct observation

Task analysis related to interface design Never complete Should not be the sole arbiter of interface style and structure

Designing User Interfaces “Designing user interfaces is a complex and highly creative process that blends intuition, experience, and careful consideration of numerous technical issues” Ben Shneiderman (1998, 3rd ed.)

User Interface Locus of interaction Cushioning buffer Visible aspect of the invisible system

Design Effective Interfaces Basic questions: Who is the user? What is the task? What is the environment in which the system will operate?

Designer Guidance I Measurable human factors  time to learn  speed of performance  rate of errors  retention over time  subjective satisfaction Often forced tradeoffs

Designer Guidance II High-level theories and models Middle-level principles Specific and practical guidelines

High-level theories I Four-level approach of Foley & van Dam (1990): conceptual-semantic-syntactic-lexical GOMS and the keystroke-level model Card, Moran& Newell (1980,1983); Kieras & Polson (1985); Kieras (1988); Elkerton & Palmiter (1991)

High-level theories II Stages-of-actions models: Norman (1988)’s 7 stages of action  forming goal  forming intention  specifying action  executing action  perceiving system state  interpreting system state  evaluating outcome

High-level theories III Consistency/Completenes through action grammars: Reisner (1981); Payne & Green (1986)  task[Direction, Unit] -> symbol[Direction] + letter[Unit]  symbol[Direction=forward] -> “CTRL”  symbol[Direction=backward] -> “ESC”  letter[Unit=word] -> “W”  letter[Unit=character] -> “C”

High-level theories IV Widget-level theories: Object-Action Interface Model of Shneiderman (1980, 1981, 1983)  Hierarchies of task objects and actions  Hierarchies of interface objects and actions  Metaphoric representation conveys interface objects and actions  Tuning of interface objects and actions to fit the task  Direct manipulation approach to design  Minimizing burdens of syntax

OAI model

Understand the user Physical abilities and physical workplaces Cognitive and perceptual abilities Personality differences Cultural and international diversity Users with disabilities Elderly users

The Notion of Task in HCI Draper, 1993 Problematic notion: a task is not the same thing to all people in all circumstances (e.g. preparing a business letter) Plea in favour of prototyping cycle for task analysis: task analysis -> design product -> build prototype -> evaluate

Testing of accomplishments of design goals Pilot studies Expert reviews Usability tests Acceptance tests

Summary Task analysis “Know thy user” Recording task objects and actions Construction of suitable interface objects and actions Extensive testing Iterative refinement