You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

GR1 - User & Task Analysis

User Demographics

Our scheduler is being evaluated in the context of three different user demographics:

House errand runner ("The one with the car")

The first demographic runs errands for her/himself and others living in an apartment.  It is normal for only one person to have a car, when living in undergraduate or graduate student housing.  This person does personal errands, but is occasionally asked to do other people's errands as well.  Since this demographic is typically made up of students, errands are time sensitive.  


User Interviews

User 1: Physics graduate student "Martha"

Statistics:

  • Age/Gender: 24/Female
  • Education: Two B.A.s at U.C. Berkeley, currently pursuing Ph.D. at Purdue U
  • Culture: Chinese/American
  • Language: English
  • Physical limitations: none
  • Computer experience: interacting with a terminal and using a smartphone, basic Windows experience
  • Motivation: Plan errands and optimize daily routine
  • Domain experience: has been scheduling errands her entire life
  • Application experience: uses a task list and google calendar on her phone
  • Work environment: graduate student office, experimental physics lab
  • Communication patterns: sends texts, emails and uses video skype.  Uses phone if these other mechanisms fail.

Description:

Martha is a 24 year old physics graduate student, pursuing a Ph.D. in the Midwest.  Like most graduate students, Martha spends most of her time in the lab, but completes her errands when she has enough of them built up.  We followed Martha around on a day of errands as she got ready to throw a weekend party at her apartment.

Martha uses a personal whiteboard to manage her TODO list.  When she decides to do errands, she copies the whiteboard to a post-it note and then goes down the post-it note in order.  Most of the time, Martha's roommate Rachael asks her to do some common area tasks, like buy paper towels, liquor, and such.  When this happens, Rachael will give Martha another TODO list, and Martha will use both of them for the errand run.

Lessons learned from Martha:

  • Tasks are important, venue isn't necessarily important.  Moreover, sometimes where not to go is more important than where to do.  Martha had to buy a picture frame.  Martha didn't really care where we got the frame from, as long as it wasn't Walmart (we eventually went to Target).
  • It would be very useful to have a smartphone say things like "start getting ready to leave now" and "you have 10 more minutes before you have to leave the supermarket"---especially if planning errands is done for you.
  • Efficient grocery shopping is perhaps a more important problem than planning out a place-to-place schedule.  Most people fill a TODO list with groceries and look for the groceries in that order once they get to the store.  This usually wastes an hour for a large grocery run.  If users input their grocery list as a set of tasks, it seems that it would be very useful to sort the items by type.
  • Specifying "do this errand first" and "do this errand last" is a very important constraint.  In the wintertime, Martha always stops at the Starbucks first so that the coffee keeps her warm.  In the summertime, she always does this step last as a reward for finishing her errands.  She usually incorporates lunch into her errands, and likes to get get lunch last so that she can eat it at home once she is done.

User 2: Stay-at-home-mom 

things taken into account:

User 3: The Novice Traveler, "Kevin"

  • Age/Gender: 22/Male
  • Education: Just graduated from a 4 year university
  • Culture: American
  • Language: English
  • Computer experience: uses a smartphone, basic Windows experience
  • Motivation: Planning a vacation
  • Domain experience: No previous experience in planning trips

Description:

Kevin is a 22 year old college graduate who is planning a trip with his friends to Europe over the summer.  Neither he nor his friends have ever been to Europe before.  In planning for this trip, Kevin researched online and created a list of all the attractions he is interested in visiting.  Next, he plotted them on a map and clustered them into groups that could be visited on the same day. If there was an attraction that was too far out of the way and was not worth sacrificing other attractions for, it was eliminated.   Depending on what times the attractions were open for on different days, Kevin chose the best day to visit each cluster of locations.  Using the hours of operation, Kevin also decided the order in which to visit the attraction.

Lessons learned:

  • Users might be unfamiliar with the city
  • Users might be unfamiliar with the local language and culture
  • Some schedules might need to span more than one day
  • Not all desired locations needed to be visited.  It is perfectly acceptable to omit some attractions, as long as they are not the main attraction.

Task Analysis

  1. Input destinations
    • Goal: Allow the user to input destinations to visit
    • Preconditions:
      • Determined locations to visit
      • Pre-loaded constraint information about destination like hours of operations, lunch break, expected time for visit
    • Subtasks:
      • Auto-complete/correct destination names
  2. Add/edit constraints for destinations
    • Goal: Modify constraints for destinations such as:
      • best time to visit
      • appointment times
      • known duration of visit
      • "visit this destination first" and other similar constraints
    • Preconditions:
      • Know what time appointments are scheduled for
      • Have an estimate of the amount of time that needs to be spent at each destination
    • Subtasks:
      • Add “global constraints” such as:
        • Between what times these destinations need to be visited
        • Partial orderings of destinations ("I want to visit the post office right after I buy stamps at the paper store")
        • What type of transportation (car, public transit, walking) is preferred
  3. Auto-generate schedule
    • Goal: Using the destinations and constraints inputted by the user, create a schedule to visit all the destinations that meets all the constraints
    • Preconditions:
      • All those listed under the "Input destinations" task
    • Subtasks:
      • Display the generated schedule both overlayed on a map on and a timeline
      • Display the optimal path between locations on a map
      • Show the user the delta between the auto-generated schedule and any partial schedule that the user had previously worked out, so that the user can choose to accept or decline some or all of the changes
  4. View and Adjust schedule
    • Goal: Change and tweak any part of the schedule including the 
      • Order of destinations
      • Duration of visit
      • Path to take between destinations
      • New constraints for one or more destinations
    • Preconditions:
      • At least one destination must already be in the system, inputted by either the user or through a generated schedule.
      • Once a schedule has been auto-generated, the user should will still be able to make changes to it
    • Subtasks:
      • Edit destinations and paths from place to place
  5. Incremental schedule rollback & history
    • Goal: Allow the user to undo changes made to a schedule, or revert changes made through generating a schedule
    • Preconditions:
      • At least one action must be taken towards creating or refining a schedule
    • Subtasks:
      • Create a language to describe changes made to a schedule, so that all schedule revisions are labeled in a readable way (such as "Moved groceries to the first stop")
  • No labels