Versions Compared

Key

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

...

 

Learnability

Efficiency

Safety

Pros

  • A visual Visual interface, that allows users to select Selecting 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

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 3: 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>

...

Design 2: Schedule-specific constraint solver

...

 

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