...
| Learnability | Efficiency | Safety |
|---|
Pros | - Visual A visual interface, Selecting 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 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.
<insert object model>-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
...
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.
...
| 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 (unless the user hits "Back" and "Plan!" again).
- 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."
|