Versions Compared

Old Version 33

changes.mady.by.user Unknown User (cwfletch@mit.edu)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (d_chang@mit.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

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.

...

 

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 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?

Cons

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

...