Homework

1
Homework

• Read the rest of Inmates
• Part V Getting Back Into the Drivers Seat
• Desperately Seeking Usability
• A Managed Process
• Power and Pleasure
• Observations homework is now due every other week
• Need more detailed analysis of the interaction
  and goals
• Consider capturing conventional use cases and
  extracting essential use cases

2
Task Analysis

• From Larry L. Constantine and Lucy A.D. Lockwood,
  Software for Use A Practical Guide to the Models
  and Methods of Usage-Centered Design,
  Addison-Wesley, Reading, MA, 1999.

3
Task Modeling

• So, what do you do?
• So, how do you do what you do?
• Can you describe the process?
• Could you deliver concrete, detailed
  instructions?
• Are you telling me the official story, the
  documented procedure, or are you telling me the
  actual story
• Do you even recognize the actual story?
• Example
• The software engineering process tells you what
  you do
• Is that what you really do?

4
Task Analysis
Dialog

• Learning about what users really need from
  software to support their work (as distinct from
  what they want or what they merely think they
  need) requires a dialog between
  analysts/designers and users.
• The joint understanding is embodied in task
  models that represent the structure of user needs
• The architecture of use

5
Activity Diagrams

• Detailed, concrete
• Resembles computer programs (programmers love
  them!)
• People are not programs
• Flowcharts, Activity Diagrams, etc. are a poor
  way to model human tasks

6
Task Decomposition

• Functional decomposition can produce elegant
  models that have little to do with how work is
  actually accomplished or how users think about it
• Conceptual, categorical
• Appealing to academics and researchers

7
Start the Day

• Enter the kitchen and turn on NPR on the FM
  radio. Prepare coffee if needed (get filter,
  measure coffee and water) and turn on
  coffee-maker. Bring in the paper from the
  driveway. Get out bowl and spoon, then fill bowl
  with oatmeal and raisins from the cupboard. Add
  water and stir, put in microwave (at high, 2
  minutes). Read the paper until coffee is ready.
  Grab a mug from the shelf and pour coffee. Get
  milk from the fridge and add to coffee. Fetch
  cereal from microwave, and add milk. Take stuff
  to table, and enjoy coffee and cereal while
  reading.

8
Scenarios

• Scenarios as a way to represent work
• Narrative descriptions of an activity or
  activities
• Story, vignette, episode
• Bound in time and taking place within a given
  context
• Appealing to artistic or literary-minded
• Continuous narrative or sequence of images
  (storyboard)
• Scenarios for user interface design
• Narrate the interaction between a user or type of
  user and a system
• Emphasis on realism and rich detail can obscure
  broad issues and general organization
• Often combine plausible combinations of
  individual tasks or activities, making it more
  difficult to isolate and understand the basic
  kernels of interaction

9
Use Cases

• A use case is a case of use, or one kind of use
  to which a system can be put
• Supplied functionality
• External, black box view
• A narrative description
• Interaction between a user in some user role
  and a system
• A use of a system that is complete and meaningful
  to the user

10
User Action ModelSystem Response Model
User Action
System Response
Get Cash use case
11
Problems with Conventional Use-Case Modeling

• Conventional use-case modeling
• Too many built-in, premature assumptions (often
  hidden or implicit) about the form of the user
  interface to be designed
• Lean too closely to implementation and do not
  stick closely enough to the problems faced by
  users
• Get cash use case
• Assumed bank card with magnetic stripe
• Assumed visual display
• Assumed keypad
• Contained steps that are not part of the user
  agenda
• Some aspects of the user interface have already
  been determined without having been designed
• The implicit design decisions and the constraints
  and limitations they place on the ultimate form
  of the user interface may or may not be the best
  for supporting the task

12
Essential Use Case

• An essential use case is a structured narrative,
  expressed in the language of the application
  domain and of users, comprising a simplified,
  generalized, abstract, technology-free and
  implementation-independent description of one
  task or interaction that is complete, meaningful,
  and well-defined from the point of view of users
  in some role or roles in relation to a system and
  that embodies the purpose or intentions
  underlying the interaction

13
Essential Use Case

• Based on the purpose or intentions of a user,
  rather than on the concrete steps or mechanisms
  by which that purpose or intention might be
  carried out
• Goal-focused
• Three essential parts
• Statement of overall user purpose or intention
• User intention model System responsibility
  model
• Note not User Action System Response
• Name

14
Use Case Notation
gettingCash
gettingCash
User Intention
System Responsibility
15
Levels of Abstraction or Generalization

• Scenarios are a concrete and detailed description
  of a particular sequence of events that is
  specific, even though it may be intended to
  represent a more general kind of interaction
• Hard to separate the specific from the general
• Conventional use cases are a reduction or
  abstraction from a collection of related
  scenarios
• Scenarios are instances of use cases
• Again, concrete forms of expression mix implicit
  design decisions into the requirements
• Need a still more abstract model to get as close
  as possible to the users perspective,
  concentrating on their needs and intentions
• Essential use cases
• In analysis, move from scenarios, to conventional
  use cases, to essential use cases
• Get at the essence of interaction

16
Use Case Map Specialization
Specializes
Specializes
Note dont design and implement the user
interface with inheritance!
17
Use Case Map Extension
Basis case

• One use case extends another use case if it
  represents inserted or alternative patterns of
  interaction within the course of the use case
  being extended
• Separating out extensions as distinct use cases
  maintains the simplicity and clarity of the basis
  cases and encourages a single, common realization
  of each extension in the implemented user
  interface

18
Extension
EXTENDS changingImages insertingImage
openingImageFile
browsingImages
User Intention
System Responsibility
19
Composition

• Composition includes or uses
• The included use cases are stand-alone
• The composing use case refers to the subcases on
  which it depends
• Composition is different from specialization and
  extension because of visibility which use cases
  know about other use cases
• Composition require parts
• Extension optional parts
• Specialization strict subtyping

20
Affinity

• Affinity use cases resemble each other
• Apparent but unspecified relatedness
• Useful early in the analysis process

21
Focal Use Cases

• Focal use cases are the focus of attention around
  which the user interface or some portion of the
  user interface will be organized
• Main, central, important, or representative uses
  of the system
• Usually support focal user roles
• Importance
• To the user
• To the provider
• Risky