Versions Compared

Old Version 43

changes.mady.by.user Andrew M Farrell

Saved on

compared with

New Version 44

changes.mady.by.user Andrew M Farrell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 

Learnability

Efficiency

Safety

Pros

  • Visual interface, Selecting destinations on map
  • 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.

 

Cons

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

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

<map interface>

<current-events interface>

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

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.

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.

...