GR2 - Designs

Scenario

Kevin has just graduated from MIT and wants to plan a trip to Florence.  He has never been to Florence before.  He decides to use SMaK to help him create an itinerary for his trip.  

Months before his trip, Kevin inputs all the destinations he wants to visit in Florence in addition to some constraints such as when he will be in Florence, when he plans to wake up and his meal preference.  Then he presses the schedule button and SMaK creates a detailed hour-by-hour itinerary especially tailored to him, taking into consideration all the constraints.  SMaK displays this itinerary along with a map indicating the most efficient path to take between attraction.  Kevin is quite pleased that he is done planning his trip and puts away the app.

A few months later, Kevin arrives in Florence.  On the first morning, he is supposed to wake up at 8am for breakfast, but due to jet lag, he does not actually wake up until 9:30am.  When Kevin wakes up, he realizes he has missed his hotel's free breakfast and is already behind on his schedule for the day.  He pulls out his smartphone and opens up SMaK.  Kevin indicates to the app that he missed breakfast and SMaK reschedules his day starting at 9:30.

Storyboard designs

Design 1: Digital Guide Book

The idea behind this design is that SMaK would act almost like a guide book by having a database of destinations along with details about this destinations such as hours of operation and average duration of visits. While it will not have detailed descriptions of each destination, SMaK would provide suggested destinations and suggested itineraries that help users who don't have a clue where they want to visit.

1. Select Destination City

Kevin opens the app and is prompted to indicate the city he plans to visit. There are 2 ways Kevin can specify his destination city. He could type Florence into the search box at the top. He could also Europe the map, which would zoom in on Europe. Then he could click on Italy to zoom in. And finally, he could select Florence from the map of Italy.

2. Global Constraints

Kevin next has to specify some global constraints to help customize his itinerary. He is asked for information about when he will arrive and depart from Florence. He is also asked which hotel he will be staying at so that the system can take that into consideration when planning his path through the city. Kevin also indicates what meals he wants to eat each day of his trip.

3. Select Destinations

Kevin is next presented with a map of popular attractions in Florence that he can select and add to a list of attractions he wants to visit. He also has the option to let SMaK suggest a list of destinations (4) or let SMaK suggest an entire itinerary.

4. Suggested Destinations

SMaK can provide a list of suggested attractions that Kevin can choose from.

5. Your Destinations

Kevin can then view a list of destinations he has selected. Each item can be selected to view it's details and constrains. Once Kevin is finished editing his destinations, he presses the Schedule button to have SMaK produce his Itinerary (7)

6. Destination Contraints

Each destination is pre-populated with data about the place such as address, hours of operation and average duration of visit. Kevin can change any of these constraints to match his needs. He can also set a priority for the destination. In the event that SMaK can not fit all the destinations into Kevin's itinerary, it will begin omitting some destinations based on their priority.

7. Itinerary

Based on Kevin's constraints and list of destinations, SMaK produces a schedule for each day of Kevin's trip. SMaK also plans the optimal route in which Kevin take and includes transit time into the schedule. If there is anything in the schedule Kevin does not like, he can directly manipulate the schedule by dragging destinations around or he can go back and change the constraints and list of destinations.

8. Checklist

On the first day of his trip in Florence, when Kevin wakes up at 9:30am instead of 8am, when he presses reschedule, he is prompted to indicate which destinations he has already completed (useful if he's running late in the middle of the day). Once SMaK knows what has already been done, it reschedules Kevin's day starting at the current time.

 

Learnability

Efficiency

Safety

Pros

  • A visual interface, that allows users to select destinations on the map
  • Direct manipulation of path on the map and direct manipulation of the scheduled events increase learnability
  • Suggested itinerary and suggested locations allow quick generation of itineraries
  • Direct manipulation of the schedule allows uses to quick get the schedule to look the way they want
  • Pre-populated constraints (ie hours of operation, visit duration) for each destination so the user doesn't need to look it up or input it
  • This design can schedule multiple days at once so that destinations can be optimally clustered such that destinations that were located close to each other can be visited on the same day.
  •  Destinations and constraints can be changed or deleted after they are created

Cons

  • It is not obvious that the user can directly manipulate the generated schedule.
  • What is a constraint? Is the concept understandable to people outside of CS?
  • Need to check off all the locations visited in order to reschedule
  • Can not manually add locations that are not in the database
  • No way to undo a change
  • Currently no way to save multiple itineraries

Design 2: Explore, select, and budget

After Kevin chooses where and when they are starting and ending the day (probably at wherever they are sleeping, possibly at a transport node), we then consider the problem to be one of choosing which "events" he wants to experience. An event has a location, a set of timespaces when it can occur, a minimum and maximum duration, and a location. "violin concerto" concert for example, will be located at the theater, could occur only from 7pm until 9pm and have both a minimum and maximum duration of 2 hours. "Visit to Uffizi" however, could occur from 9am until 6pm and have a minimum duration of 1 hour and a maximum duration of 3 hours.

object-model.pdf

We first allow the user to explore the city in space and time and choose those events that interest him. He can search for events both by navigating the map and by reading through a schedule of those that are occurring in the city. For those he is interested in, rate them to add them to his list of possible events. He can create events himself such as "lunch with long-lost cousin at Garibaldi Square."

possible-events.pdf (pretend Florence is NYC)

Next, Kevin can schedule the events he *actually* wants to attend. He is presented with an empty schedule filled with 'downtime' and his list of events, sorted by an order that is a function of his rating, the distance from the hotel, and the earliness when the event can take place. At any time, the user can auto-fill the whole day, or a section of downtime.

From this list, he can drag them onto his schedule, place them within the periods of downtime that the event can take place. When an event is placed on the schedule, the time it takes to reach the location (plus a few minutes for safety) is automatically added as buffer before the start of the event.

As Kevin builds his schedule, he fill in times that he could otherwise attend events. Those which can take place tomorrow, are highlighted in yellow and minimized, but can expand when clicked on. Those which cannot, are highlighted in red and can be minimized or removed.

Schedule.pdf

The user can also switch to map view, which will show selected events with arrows indicating the travel from one to the next. It will also show unselected events on the map. those with higher ratings that are closer in time to the most recently selected event will be more brightly coloured. Clicking on an unscheduled event brings up info about it and lets you choose when to schedule it. Clicking on a scheduled event also displays info and lets you remove it.

When Kevin wakes up and sees that he is late, he needs only remove the event he had scheduled in the morning, any event other event he decides is less important than it, and either autocalc again, or manually re-add events to his schedule.

 

Learnability

Efficiency

Safety

Pros

  • Adding events to schedule from possible events is obvious.
  • Two step process lets groups who are jointly planning a trip first compile list of interesting places and then argue over how they spend their time.
  • Direct manipulation of schedule
  • Automatically adds events to next day
  • Destinations and constraints can be changed or deleted after they are created
  • Items can be moved from schedule back to list of possible items and removed therefrom.
  • Deciding an itinerary does not eliminate information about other events that look interesting.

Cons

  • Not obvious how to auto calculate schedule.
  • Not obvious that rating an event adds it to the list of possible events.
  • might not be obvious how to remove events.
  • Two-step process for adding events to schedule takes longer for those who already know what they want to do.
  • Currently no way to save multiple itineraries

Design 3: Schedule-specific constraint solver

The big idea behind the second design is to pose the scheduling problem as a set of activities with constraints that behave like tags. This design isn't designed to look like a guide book, or a post-it note. Instead, it lets the user specify activities (in no particular order). Each activity can be tagged with an arbitrary number of constraints. The "Plan!" button takes all of the activities and schedules them to meet the constraints. By "Schedule" we mean that the activities are ordered and given specific start and end times. Routes on a map are also drawn up between each pair of time-adjacent activities.

We call this a "Schedule-specific constraint solver" because the interface lets the user pick from a list of schedule-specific constraints such as:

  • When to start the first activity
  • An activity's duration and location
  • A partial ordering between activities (breakfast comes before lunch)

Each constraint that the app supports has special meaning that the scheduling algorithm uses when mapping the unordered list of activities and constraints to a time/order specific schedule.

We present this design in three whiteboard snapshots.  The first shows Kevin opening the app, adding activities, and adding constraints for those activities.  The second shows how Smak takes Kevin's activities and constraints and translates them to an ordered/time-specific schedule.  The last snapshot illustrates what Kevin does after arriving in Florence and realizing that he woke up late.  The pictures are color coded (see upper right for legend).

Snapshot 1, Adding activities and constraints

Snapshot 2, Generating the schedule

Snapshot 3, Changing the "Wake-up time" constraint and re-regenerating the schedule

An important feature of this design is that it just plans and saves schedules.  It does not monitor the user or check to make sure the user is following the plan.  If the user/Kevin wakes up late, they have to be the one to tell Smak to reschedule.  This is like the iPhone default navigation app: if the user deviates from the map route, he/she must manually tap "re-route."

 

Learnability

Efficiency

Safety

Pros

  • Users can be "weened" into using the app by creating a constraint-less mode.  This mode just lets the user specify activities.  The system then plans and routes between the activities (think of this as multi-hop google maps).  When the user needs/wants to learn about constraints, he/she can re-enable them.
  • Constraints are schedule-specific and are described in English.  For example, the wake up constraint is "Start day at ___" before being set and fills in to "Start day at 8a" when set.  This allows users to read off constraints as if they were on a TODO list.
  • Each activity can be specified with a minimum number of constraints.  For example, if the user doesn't specify a duration for an activity (see snapshot 2) but does specify a "do this between X and Y time" constraint, the scheduler will interpret this as "make sure there is *some* break between time X and Y.
  • Activities and constraints can be applied in any order.  They can also be added incrementally, so that the user can just CRUD as he/she thinks of more things to add/do.
  •  The "save" button snapshots the schedule at any point with any name that the user specifies.  Once saved, the user can go back to any part of the schedule making process and make changes.
  • Once the user clicks "Plan!", he/she can make manual changes to the generated schedule and Smak will not interfere or make any further changes. 
  • All activities and constraints can be edited and deleted once created.

Cons

  •  The interface doesn't follow a specific metaphor (such as guidebook or post-it note) because it was designed to be multi-purpose---one can plan errands or day trips with it.
  • What is a constraint?  Is the concept understandable to people outside of CS?
  • Common constraints (such as activity duration/location) are not specified by default.  Common activities (breakfast, lunch, dinner) must be added to the schedule every time they are needed.
  • The app works at the level of single days.  On a 5 day vacation, it is likely that some activities (eating) will be repeated.  With the current design, the user will have to add them each day.
  • The save button is only shown on panel 11
  • If an activity or constraint is deleted, there is no "undo."
  • If the user decides to re-plan (take the "woke up late" scenario for example) after making manual changes to the generated schedule, the manual changes are discarded.
  • If the user under-specifies constraints (to save time), he/she might be surprized by what the scheduler generates (see "Pros, Efficiency").
  • This design does not let the user specify when the schedule is going to happen.  This means that if a user opens the app after waking up late on the day of, the user is the one who has to realize "oh, I need to change a constraint and tell Smak to re-plan."
  • No labels

1 Comment

  1. Sacha Zyto

    "Overall: Very nice storyboards and analysis.
    Comments from meeting: suggested using analogies to have people understand constraints better, and more interplay: just come w/ default values and let the user lay them out later.
    "