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
|
1. Select Destination CityKevin 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 ConstraintsKevin 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 DestinationsKevin 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 DestinationsSMaK can provide a list of suggested attractions that Kevin can choose from. |
|
5. Your DestinationsKevin 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 ContraintsEach 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. ItineraryBased 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. ChecklistOn 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 |
|
|
|
Cons |
|
|
|
Design 2: 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.
|
Learnability |
Efficiency |
Safety |
---|---|---|---|
Pros |
|
||
Cons |
|