CMC/CC A Task Analysis Master IK, CIW, MMI L.M. Bosveld-de Smet
Download
Report
Transcript CMC/CC A Task Analysis Master IK, CIW, MMI L.M. Bosveld-de Smet
CMC/CC A
Task Analysis
Master IK, CIW, MMI
L.M. Bosveld-de Smet
Hoorcollege 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
Analysis
Task models – means to capture how people carry out
tasks
Design
what is wanted?
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
Knowledge-based techniques
Looks at the way a task is split into subtasks, and the order
in which these are performed
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 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
Plan 0
Do1; at the same time, if the pot is full do2;
0.
make a cup
of tea
Then do 3-4;
After 4 or 5 minutes do 6
1.
Boil water
2.
Empty pot
3.
Put tea leaves
In pot
4.
Pour in boiling
water
1.1.
Fill kettle
1.2.
Put kettle on
hob
1.3.
Wait for kettle
to boil
1.4.
Turn off gas
Plan 1
Do 1.1-1.2-1.3
When kettle boils do 1.4
5.
Wait 4 or 5
minutes
6.
Pour tea
HTA for making lots of cups of tea
Plan 0
Do1; at the same time, if the pot is full do2;
Plan 1
0.
make cups
of tea
Do 1.1-1.2-1.3-1.4
When kettle boils do 1.5
1.
Boil water
2.
Empty pot
3.
Make pot
Then do 3-4;
After 4 or 5 minutes do 5
4.
Wait 4 or 5
minutes
5.1.
Put milk in
cup
Plan 3
5.
Pour tea
5.2.
Fill cup with
tea
5.3.
Do sugar
3.1-3.2-3.3
3.1.
Warm pot
1.1.
Fill kettle
1.2.
Put kettle on
hob
3.2.
Put tea leaves
in pot
1.3.
Turn on and
light gas
3.3.
Pour in boiling
water
1.4.
Wait for kettle
to boil
5.3.1.
Ask guest
about sugar
5.3.2.
Add sugar to
taste
Plan 5.3
1.5.
Turn off gas
5.3.1
if wanted 5.3.2
HTA for making lots of cups of tea
Plan 5 (pour tea)
5.1
5.2
empty
cups ?
YES
NO
for each
guest 5.3
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