cmc/cc a task analysis
Post on 25-Feb-2016
17 Views
Preview:
DESCRIPTION
TRANSCRIPT
CMC/CC A
Task Analysis
Master IK, CIW, MMIL.M. Bosveld-de SmetHoorcollege 4; ma. 25 sept. 2006; 16.00-18.00
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 house1. get the vacuum cleaner out2. fix the appropriate attachment3. clean the rooms
3.1. clean the hall3.2. clean the living rooms3.3. clean the bedrooms
4. empty the dust bag5. put the vacuum cleaner and attachments away
Plan 0: do 1-2-3-5 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 1.1-1.2-1.3
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 1.1-1.2-1.3-1.4
When kettle boils do 1.5
1.3. Turn on and
light gas
3.2. Put tea leaves
in pot
3.1. Warm pot
5.3.1. Ask guest
about sugar
5.3.2. Add sugar to
taste
5.1. Put milk in
cup
5.2.Fill cup with
tea
5.3. Do sugarPlan 3
3.1-3.2-3.3
Plan 5.3
5.3.1
if wanted 5.3.2
HTA for making lots of cups of tea
Plan 5 (pour tea)
5.1 5.2for 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 ORpreparation
mixing bowl, plate, chopping board
cookingfrying pan, casserole, saucepan
diningplate, soup bowl, casserole, glass
Knowledge-based analysis: exampleTAKD
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: exampleTDH 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 tointerface 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 HCIDraper, 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
top related