Page History

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.

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."