Versions Compared

Key

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

...

 

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