Page History

...

The user was a 42 year old white male geek who occasionally travels for work and uses an ipad regularly.  I  

I instructed the user to pick Flourence as we had not implemented the ability to change cities in the splash page.

Usability Problems:

•  The user began by clicking on a particular place on the map to try to pick an event.  Finding that that did not work, he he looked around the map to pick places and then typed their names into the text field.  He said he wanted a search feature for the map where you can find restaurants.

...

•  
  • (major) This indicates not so much a flaw as a lack of a feature.

...

• • An improvement would greatly increase the efficiency of the application.

...

...

• At the

...

• time of the evaluation, changing the start and end time caused the schedule to disappear. 
  • (catastrophic) It rendered the application unusable until the user pressed undo. This was fixed by demo time.
•   He was frustrated by the fact that when he typed the name of a location, it did not search for the location and place the pin at that place.

...

•  
  • (major) This is easy to overcome but decreases efficiency

...

• He automatically plans for walking time when the number of events in the schedule is small. However, when it is large, he left an unrealistically short amount of time between activities.

...

•  
  • (minor) This can be overcome as the user will learn not to do it, but it will make him late to things the first few days.

It would be good if you could click on the map to pick a place.  if they type a full name, 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.

• There is no way to save the schedule. Thus, the user has to leave the application open the whole time.

...

•  
  • (catasrophic) Realistically, the user is going to be closing and opening this application.
• Clicking on the pin of a scheduled event, the nature of the info displayed is non-obvious and less than useful. 
  • (minor) This

...

• • doesn't impede usability except by confusing the user why it is there momentarily.
• It took him a while to discover that you can lock something. The lock icon should be within something that looks like a button.

...

•  
  • (minor) This is discoverable, just after a while. 
• It is hard to lock things because clicking the lock is hard. It should be bigger.

...

•  
  • (major) This is a major flaw in that

...

• • it causes the user frustration in using the feature.
• Redo does not completely redo operations, as it ignores locking.

...

•  
  • (minor) The user can still manually redo all operations.
• Selecting an event should pan such that the event is visible on the map. 
  • (minor) This just requires the user to spend more time panning around and remembering.

Usability Successes:

He finds the dragging of events from the todo list to the schedule very intuitive, as well as resizing events and moving them around to change event times.  He also finds it intuitive to be able to drag the map pin to the location of the event in order to place it.

Notes: 

He did not use autoschedule That it does not do this makes it less learnable for the user to change the location. This is a major flaw.At the time of the evaluation, changing the start and end time caused the schedule to disappear. This was a catastrophic flaw, how ever was fixed by the time of the demo.

He expressed a desire for a button that just says "pick stuff for me to do" that picks the top-10 reccomended activities in the city. He did not use autoscheduleI am skeptical.

User 2

User 2 was a grad student from the media lab.  We chose this user because the user has never been to Florence but has some experience planning trips.

Usability problems:

• User tried tapping instead of dragging the resize handles.  (minor)
  • Possible solution: better grip icons
• Earliest start and latest end times were unintuitive and unused by the user.  When the grey bars appeared, the user was unsure of their meaning. (minor)
  • Possible solution: remove feature altogether. 
• On multiple occasions, the user tried to add a new activity while an activity was selected. Because the uses the same form to add a new activity as to edit an activity, a new activity could not be added until the activity was deselected. (major)
  • Possible solution:  Do not reuse the form to edit activities. Make the form inside the activity or as a popup box. 
• User tried pressing the “Schedule these activities for me” when there were no activities in the unscheduled activities column.  It is unclear to users that auto-schedule does not help optimize the current schedule, but instead optimally moves unscheduled items into the schedule.  (major)
  • Possible solution: Make more descriptive  label for button

...

• User was able to quickly add all the activities he wanted to do that day
• User understood and used the dialogue for change the start and end time of the day
• User quickly discovered how to move location markers on the map since the marker said "Drag Me!"
• The user was able to select an activity by clicking on the corresponding location marker on the map. 
• The user immediately understood that the activity boxes were meant to be dragged.

User 3

User 3 was a college graduate (early/mid twenties age range) who had just finished applying to law school.  This user was chosen because his personality was meticulous and thought-out but had very little experience planning trips.

Usability problems:

• User had a different iPad with a different resolution: the "end of day" pull down was not on the screen and there was no indication of where it was supposed to be. (minor)
  • Possible Solution: set default day to be sufficiently small so that the entire (default) schedule fits on one screen with high guarantee (easy fix).  OR adjust based on dynamic iPad resolution (more difficult).
• As described in the list of tasks, finding the specific locations on the map was difficult.  It was confusing to have to constantly zoom in and out of the map to pinpoint locations. (major)
  • Possible Solution: allow the users to input street addresses to locate places, as opposed to pinning the location down on the map itself.
• User complained that activities disappeared all of a sudden (the user had accidentally clicked the X button for that activity).  Fortunately, there is an undo button but the user did not see it (the facilitator had to give a hint).  (major)
  • Possible solution: ask for confirmation when an activity is to be moved from the List of Activities column to the trash.
• There was no way to specify "end of day" when setting the latest start time---one can only specify exact times. (minor)
  • Possible solution: add both "end of day" and "beginning of day" to the start time/end time pull-downs.
• There is no way to make an activity with no location.  User wanted to have lunch anywhere around 12p-2p (minor)
  • Possible solution: if the user specifies no location for an activity, that activity will still take up space in the schedule column but not appear on the map for distance routing purposes
• User did not use the lock button for the opera. (minor)
  • Possible solution: add an element in the "Add Activity" flow for specifying specific starting times.
• User did not use the auto-schedule button. (minor)
  • Possible solution: Couple the auto-schedule button more tightly with the schedule column (see below for details).

...

In addition to rendering the boxes for each activity, the view also dynamically updates the activity boxes as they are moved and resized so that they show error messages, map labels and the current duration and times.  A single activity can be selected, at which point, it greys out parts of the schedule in which the selected activity cannot be done between.

TODO: Andrew: maps

Model

TODO: Andrew

- object array / uniqid

- invariant checking

- handler propegation

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:

1. Moving an activity onto/within the schedule, or resizing an activity already on the schedule.
2. Changing the schedule's start or end times.
3. 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

We chose users who had a desire to travel to foreign places and had different travel.  For example, young people who travel through Europe do so "by the heals of their pants," jumping from hostel to hostel.  Older travelers, however, probably want a more set-in-stone schedule.  Older travelers are probably more experienced in traveling, as well.

Procedure

We read the briefing (below) to each user.  We then gave each task on an index card to each user.  The next card was given when the user completed the task on the current card.  No demo was given to any user.  After the user test completed, we debriefed each user and let them know how to overcome problems they were having (if any) with the interface.  We have listed usability problems during the user tests (and potential solutions) at the top of the page under the User tests section).

Briefing

SMak helps you plan your schedule.  When people travel to foreign countries, they typically know what you want to see but not how to go about doing it.  With SMak, your job is to specify what your activities are and give hints as to how you want to carry out those activities.  Smak's job is to help fill in the details of your schedule: how to get from place to place, in what order to do your activities---these sorts of things.

Tasks

1. You want to visit Florence.
2. You want to wake up at 8am and go to bed at 10pm.
3. You want to do the following activities throughout the day: eat breakfast/lunch/dinner, visit the dome, and go to the opera.
4. Now, you want to visit tourist places in Florence *and want to do as little walking as possible.*  You want to visit the dome (at the piazza del duomo) at some point in the day for two hours; it doesn't matter when you go.  The dome opens at 10am and closes at 5pm.  You also want to go to the Medici chapel for a special opera showing that starts at exactly 3pm and lasts for 2 hours.

Reflection

TODO: Andrew

Form: The user first selects events using a form and map. The form has little more than a textbox for the name of the event and two dropdown menus to pick the start and end times of the event. The textbox suggests activities within each area from the google places API.  
Map: The map indicates both the location of an individual activity and the user's itinerary.  When an event is selected (or first created) a pin is placed on the map saying "Drag Me", which the user drags to indicate the location of the activity. When a user deselects an event, the pin becomes a normal google maps blue pin. A User can click on a pin to select it When the event is scheduled it becomes part of the user's itinerary. The walking path from event to event given by the google maps API is displayed.

Model

The fundamental object in our application is an activity: something that can be done at a particular location in between two particular times. There was simply an array of these, each with a unique id. This activity could be in one of four states: 

- Suggested, as one of the events that the google palces API returned or one of our created events. These were not visible except in autocomplete.
- Todo, as an event in the middle column that the user was interested in visiting but not certain.
- Scheduled, as an event placed on the schedule and itinerary.
- Locked, which was also placed on the schedule, but unable to be displaced without being unlocked.
Three things could be done to these events:
- They could change state, and there were a number of functions provided by the model to do this while preserving invariants. Of course, javascript is still a dynamic language and so no real invariants could be enforced.
- The event could be selected or deselected. Only one event at a time could be selected.
- Other properties such as start time, end time, opening, closing, location, or name could be changed.
Views each register handlers to such changes in an activity. Thus, when an event's time changed in the schedule, the schedule updates the model, which files all handlers for that change, which fires the handlers in the view, form, and map. The function call to propegate the change can take a parameter naming a view whose handler should not be called. This allows us to prevent the schedule from twice dealing with the movement of an event.
Model: The fundamental object in our application is an activity: something that can be done at a particular location in between two particular times. There was simply an array of these, each with a unique id. This activity could be in one of four states: 

- Suggested, as one of the events that the google palces API returned or one of our created events. These were not visible except in autocomplete.

- Todo, as an event in the middle column that the user was interested in visiting but not certain.

- Scheduled, as an event placed on the schedule and itinerary.

- Locked, which was also placed on the schedule, but unable to be displaced without being unlocked.

Three things could be done to these events:

- They could change state, and there were a number of functions provided by the model to do this while preserving invariants. Of course, javascript is still a dynamic language and so no real invariants could be enforced.

- The event could be selected or deselected. Only one event at a time could be selected.

- Other properties such as start time, end time, opening, closing, location, or name could be changed.

Views each register handlers to such changes in an activity. Thus, when an event's time changed in the schedule, the schedule updates the model, which files all handlers for that change, which fires the handlers in the view, form, and map. The function call to propegate the change can take a parameter naming a view whose handler should not be called. This allows us to prevent the schedule from twice dealing with the movement of an event.

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:

1. Moving an activity onto/within the schedule, or resizing an activity already on the schedule.
2. Changing the schedule's start or end times.
3. 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

We chose users who had a desire to travel to foreign places and had different travel.  For example, young people who travel through Europe do so "by the heals of their pants," jumping from hostel to hostel.  Older travelers, however, probably want a more set-in-stone schedule.  Older travelers are probably more experienced in traveling, as well.

Procedure

We read the briefing (below) to each user.  We then gave each task on an index card to each user.  The next card was given when the user completed the task on the current card.  No demo was given to any user.  After the user test completed, we debriefed each user and let them know how to overcome problems they were having (if any) with the interface.  We have listed usability problems during the user tests (and potential solutions) at the top of the page under the User tests section).

Briefing

SMak helps you plan your schedule.  When people travel to foreign countries, they typically know what you want to see but not how to go about doing it.  With SMak, your job is to specify what your activities are and give hints as to how you want to carry out those activities.  Smak's job is to help fill in the details of your schedule: how to get from place to place, in what order to do your activities---these sorts of things.

Tasks

1. You want to visit Florence.
2. You want to wake up at 8am and go to bed at 10pm.
3. You want to do the following activities throughout the day: eat breakfast/lunch/dinner, visit the dome, and go to the opera.
4. Now, you want to visit tourist places in Florence *and want to do as little walking as possible.*  You want to visit the dome (at the piazza del duomo) at some point in the day for two hours; it doesn't matter when you go.  The dome opens at 10am and closes at 5pm.  You also want to go to the Medici chapel for a special opera showing that starts at exactly 3pm and lasts for 2 hours.

Reflection