User tests
User 1
TODO: Andrew clean this up
tasks: I told him not to pick Boston, but to pick florence.
he tried to click on a particular place shown by the map.
he looked around the map to pick places.
wants a search feature for the map where you can find restaurants.
he manually plans for walking time, though didn't include enough.
the autocomplete for places doesn't really succeed in finding things that well.
It would be good if you could click on the map to pick a place.
if they type a full name, I should search for the location with google maps
he thought of the idea that he could drag the thing to where he
wants to go. that worked well, but placing it there, it did not stay.
his loop is: seach in the map for interesting places, then type in the name.
he knows how delete works.
The tabs are pretty intuitive.
the start and end time should be shown
"how do I save?" we should have a way to email the schedule or something at least.
the autocomplete should recognise a category name and show options for that.
the location of a specific place is not actually being selected.
It should pop to the nearest place matching that category.
clicking on the pin, the nature of the info displayed is non-obvious.
It is not obvious what the start and end times are.
took a while to discover that you can lock something.
It is hard to lock things because clicking the lock is hard (fatfingers).
redo doesn't completely reverse the operation.
selecting an event should scroll to the event.
Changing the time fucks everything up.
It removes the schedulegrid.
Undo fixes that.
And then he somehow breaks everything and cannot create activities.
"""There should be a button that just says "pick shit for me to do"
that picks the top-10 things.""" (I disagree with this.)
He did not use autoschedule.
User 2
TODO: Danica
User 3
TODO: Chris
Report
Design
Structure and flow
The final design is three-part/column and has the following structure:
- Left column (Add activity): user can add an activity, and change properties related to that activity such as its location, name, earliest start time and latest end time (e.g., museum closing times). When an activity is added, it appears in the list of activities (center) column.
- Center column (List of Activities): A list of all activities that the user wants to do, but have not yet been scheduled. This is conceptually a TODO list: activities in this column have a duration (which can be changed by the user), but haven't been given a specific start time. Activities move between this and the right column as the schedule changes.
- Right column (Schedule): The concrete schedule of activities. This column has an hour-by-hour calendar feel; activities placed on it have a duration and start time and abide by the following constraints. First, no activity may overlap with another activity (you can't be in two places at the same time). Second, no activity can start before its earliest start time (specified in the left column) or after its latest end time (you can't visit a museum after it has closed). Each activity has a "locked?" button which indicates whether the start time is flexible (this will be explained below).
The final design has the following flow. The user adds a set of activities in the left column. Then, the user constructs a final schedule through an iterative process of moving activities between the list of activities and schedule column. When the user moves an activity from the list of activities to the schedule, some activity from the schedule may be displaced and moved back to the list of activities. The application provides a "schedule these activities for me" button, which tries to schedule all of the remaining activities in the list of activities in one click. When the user is satisfied with the state of the schedule column, the scenario is complete.
How the schedule column changes when an activity is added (what if the new activity overlaps some other activity's time slot?) is an important question. We address this below in "Scheduling Algorithms (Controller)".
Platform
SMak is meant to be used on the go, when the user is traveling. The UI is currently a web browser application which has been ported to an iPad for portability reasons.
Design evolution
TODO: what we learned from the first three checkpoints.
Implementation
View
TODO: Danica
Model
TODO: Andrew
Scheduling algorithms (Controller)
When an activity moves from the Activities column to the Scheduling column, an important decision to make is how to "make room" for the new activity in the Scheduling column. We implemented separate algorithms for the following operations:
- Moving an activity onto/within the schedule, or resizing an activity already on the schedule.
- Changing the schedule's start or end times.
- Clicking the "Schedule these activities for me" button (a.k.a. auto-scheduling).
Broadly speaking, the algorithms rely on the principle of least destruction: when adding to/resizing/etc the schedule, don't move activities already in place unless they have to be moved. We chose this heuristic for usability reasons: if the user is planning a schedule and moves some activity A, he/she will not want the rest of the schedule to change in unnecessary ways. So, if an activity is moved into an empty space, no other activities should have to move. If one activity A is moved on top of another activity B, activity B should "scoot" or somehow else move to make room for A. If changing the schedule makes placing some activities impossible (due to time constraints, etc), the activities are moved to the Activities column. The algorithms try out different possible schedule configurations based on these principles and choose the best configuration based on a weight function.
The auto-scheduling algorithm, in addition to the above heuristics, tries to minimize the average euclidean distance between each activity. This was also done to generate better schedules: given a set of activities, the user wants to complete as many as possible in a fixed amount of time. The algorithm internals are traveling-salesman-like: we have a set of unscheduled items which we add to the schedule in different ways (while observing the "principle of least destruction"). Then, we choose the best complete configuration based on the weight function we described above plus the distance metric. Despite our small problem scale, the brute force approach did not work time-wise; so our algorithm is greedy, with intelligence to avoid getting stuck in bad schedules.
Evaluation
TODO user test information (volunteers?)
Reflection
TODO fluff (volunteers?)