GR3 - Paper Prototyping

Prototype photos

Figure 1:  The main calendar window after adding the note in Task 3, with note panel open on the left.

Figure 1:  The event creation dialog, completed with the information from Task 1 (appears over main window)

Figure 3:  The share dialog after adding brandic@mit.edu to the share list (appears over main window)

Figure 4:  The new category dialog (appears over main window)

Figure 5:  The category pane after the Extracurriculars category has been added for task 2 (replaced the note panel shown in figure 1)

Briefing

Our project is a calendar application that is capable of handling more than short events with a fixed start and end time.  We want to make it easier to integrate notes, to-do lists, and deadlines as one could with a paper calendar but with added sharing functionality.

(Since MIT students are in our user domain, we did not feel it was necessary to instruct the users about the target user population.)

Scenario Tasks

Task 1:  Create a deadline on May 20, 2011 at 10:00 PM for GR3 and share it with brandic@mit.edu.

Task 2: Add an event to the "Extracurriculars" category and then hide the category.

Task 3: Add a note to March listing your group members' e-mail addresses.

Observations

We observed our users struggling with a number of aspects of our initial design, primarily related to lack of information scents, interface inconsistencies with Google Calendar, and a variety of visibility problems.

In performing task one, only one of our users was actually able to locate the navigation panel under the Jump To button on the left, so most resorted to clicking the "New Event" button at the bottom of our interface while still viewing March.  While our interface did allow users to add events to arbitrary days via drop down menus, this left the newly added event invisible to the user.  While this allows the user to add events more efficiently to arbitrary months, we believe it to be somewhat ill-advised since the user receives no visible feedback from their action.

Once in the new event dialog, users became frustrated because they could not add an event before selecting an event type from one of three radio buttons at the top of the dialog, which most of our users overlooked completely; these radio buttons served only to change the requirements for time specifications, and so somewhat baffled the users as to their existence.  Because the task one deadline was added to a month that was invisible during most user tests, users could not observe that different event types produced different representations in the interface, so found this selection needless.  Because these distinct event types do produce different results in our model, we feel that this information needs to be better communicated without eliminating the distinction, perhaps with distinct dialogs.

Though most users found the share button easily, they were confused by the resulting dialog, which was poorly labeled.  (Although one user did complain about not being able to share the event in the same dialog in which they created it.)  Some complained about how poorly labeled the dialog was, since most options were disabled until a selection was made in the upper box.  Further confusion resulted from having to enter text before clicking the "Add" button on the lower text box, since it could not easily be distinguished that the lower half of the dialog consisted of a text box and a selection box; users expected clicking the "Add" button would result in another dialog.

Task two saw few of the same problems, since users now had a feel for how event creation functioned.  However, many were surprised when the "Extracurriculars" category did not already exist and were required to create it themselves.  Some had difficulty initially locating the category pane, but none had any real difficulty with the actual category creation.  Several did express some confusion as to why they were creating a category and did not really understand why categories were nested hierarchically, as they were already accustomed to the "Calendar" notation and functionality from Google Calendars.  When questioned after the test, one user confessed they might never use the categories functionality because they did not understand what it was for.

For task three, users easily found the notes pane, but again had difficulty with the preexisting text box above a selection box, repeating the same errors exposed by the share dialog.  As with the previous task, users expressed some confusion about the function of notes and why they would want to use them.  Others suggested that the attachment of notes to months seemed arbitrary, and while they might like the feature, would like some ability to attach notes to particular days or weeks instead of the month as a whole.  Another commented that notes would be more useful if the panel was visible when the calendar loaded.

On the whole, our users seemed most perturbed by "inconsistencies" with Google Calendar, though one particularly savvy user had little trouble with the interface and another mentioned that it shared some similarities with iCal.  We believe our interface could be improved by relocating some of the buttons (such as the panel buttons located on the far left of the screen and the quick access buttons below the calendar), and by redesigning the new event and share dialogs.

Prototype iteration

We had an alternate design that we also tested.

Figure 1: The initial screen presented to users. Note that there is a monthly calendar view in the upper left corner, a notes bx at the top, and a weekly view on the bottom. The Sunday in the weekly view looks like it is separate from the rest of the week because we also used it as the daily slot in the daily view.

Figure 2: Event/daily view. This is the daily view. (note, the black paperweights only exist in order to keep the paper from rolling up on itself, and are not part of the interface).

On the daily view, the calendar stays in the upper left corner, and the day of interest is located on the left side of the screen. The Notes section becomes vertical and is located on the side. The center of the screen is filled with information about events. It defaults to the first event in the day of interest, or the event that the mouse is currently hovering over.

User observations:

The users did not understand how the people section worked for sending records of an event. They did not understand that putting an email address in the people section would automatically send an email, or do anything other than just manipulate text. One tester ignored the section completely, and put the email address in the notes section as a note for himself. He also mentioned a feature request for keeping track of contact information. Another user complained about the lack of any confirmation screen, or recovery from a mistyped email address.

All three of the test users were confused about the category terminology. Two of the three were able to figure it out once they saw where they could input categories in the interface, but they had to explore the interface in order to find something to satisfy the prompt instead of actively searching for the functionality.

One user complained about the visibility of created events in the monthly view. This interface uses the monthly view mostly for navigation and reference instead of active manipulation of events. He wanted little bubbles in it in order to increase visibility.

None of the users realized that the daily view was different from the event view, because the even panel was such a dominant part of the interface. Navigating to and from the daily view and weekly view was therefore confused.