GR2 - Designs

Scenario

John Doe is a student at MIT. He just asked out the cutest girl on campus, Jane Smith. He wants to put the date in his CalendarShare calendar and give her a record of the date. He looks at his calendar in order to find a good time. They agree on Thursday at noon for an hour. He enters the date into his calendar and shares it with Jane, who does not have an account with CalendarShare. She creates an account, accepts the event, and realizes that she does not have any clean clothes for her date. She needs to do laundry before her date, which she will enter in her calendar as a deadline.  Finally, she'd like to print her calendar and put it on her door for her friends to see.

Designs

Design 1

The emphasis of Design 1 is on transparency to the underlying state of the calendar, and clarity of all available options.

Step 1: John looks at his calendar.  He sees today's view by default, with the activities, to do lists, and deadlines that belong to that day.  He wants to schedule an event for Thursday, so he goes to the bottom of the page and clicks "Add Event".

Step 2:  John schedules an event for Thursday.  Lunch is a an "activity", so it has a date, a start time, a description, and an end time.  John has the option of putting the event in a particular category he has already created, such as "Dates", "Extracurriculars", or "Schoolwork".  If no category is specified, events are added to the "John's Calendar" category.

Step 3: Now that John has created his event, he decides to share it with Jane by clicking on the "Share Event(s)" button on the "Manage Calendar" part of the page.  Notice that the upper part of the page still shows "Today", which is not the date of the event that he scheduled.  (He could choose to view the event he scheduled by navigating to Thursday.)

Step 4: John shares the event with Jane.  First he enters a date, which populates a list of events on that date.  Of the list of events on that date, he can choose which to share.  Additionally, he can search for events by category.  If he clicks on the "All" category, he will see all events in the system, from which he can choose what to share.

Step 5:  Jane gets an email (at the email address specified by John) inviting her to see the event shared with her by joining CalendarShare.  She clicks on the "Create Account" button to create an account.

Step 6: Jane enters her email address and password to finish creating her account.

Step 7:  Jane navigates to Thursday, March 3 by clicking on the calendar square corresponding to that date.  She can now see the activity that John shared with her.  She can click on the "Edit" button to change the details of the event.  (Not shown: she clicks the "Edit" button to change the description of the activity from "Lunch with Jane" to "Lunch with John".)  She clicks "Add Event" so that she can add a reminder to do laundry.

Step 8: Jane navigates back to "Today" by clicking on the square corresponding to March 2.  She adds her laundry deadline by selecting the radio button for "Deadline" and specifying a time and description for the deadline.  (Unlike an activity which has two times associated with it -- start and end, a deadline has only one time associated with it.)

Step 9:  Jane wants to print her calendar, so she clicks "Print/Publish".

Step 10: Jane specifies that she wants to print a calendar with a week view of the week which includes March 3, 2011.  She wants to physically print the calendar, so she specifies "Printer", and clicks "Print".

Analysis of design 1:

This design emphasizes two main features.  The top panel contains the events on a given day, separated into activities, to do lists, and deadlines.  The bottom panel contains the the calendar management system, which allows users to add events, share events, and print their calendars.

Learnability:  The interface is learnable because of its physical calendar metaphor.  As expected, clicking on the calendar square corresponding to a particular day displays the events for that day.  Additionally, the clear physical demarcation between the different kinds of events (activities, to do lists, and deadlines) allows the user to figure out what kinds of possibilities are offered by the application.  The notion of "Category", however, may be unclear to a user new to the interface.  The use of a default category for events helps in this regard.

Visibility: The interface shown separates the state of the system (which events are scheduled for today, etc) from the available actions (calendar management).  This allows the actions to be visible (in the management section on the bottom of the page) and the state to be visible (in the day-specific section on the top of the page).  A possible visibility problem may arise as a result of the fact that the management is separate from the current view.  Since managing the calendar does not necessarily affect the day view that is shown, an event is not necessarily visible when scheduled.  (For example, when Joe schedules his event for Thursday, the view is still "Today", so Thursday's event is not seen.)  Another visibility issue is the fact that there is no filtering based on category.  As it stands now, one cannot only display events from the "Extracurriculars" category in one's calendar.  This could be fixed by creating another button on the "Manage Calendar" section of the page, but it would decrease the simplicity of the interface.

Efficiency: The interface is reasonably efficient.  A user can navigate to a different day by clicking on a calendar square.  Additionally, one can schedule an event with only a few mouse clicks.  Efficiency issues include difficulty in navigating to a particular month far away from the current month since the left and right arrows only navigate forward and backward by one month.  (This could be fixed by adding a "go to month X" drop down menu.)  Another downside to efficiency is that it is difficult to share events that are not scheduled for the same day or are not in the same category.

Error Prevention: Events can be edited with a new description, times, or category after they are created using the "Edit" button next to the event.  Additionally, the end time for an activity must be after its start time.  Possible errors include users scheduling events for the wrong date or time or sharing them with unintended recipients.

Design 2

The emphasis of Design 2 is on the easy viewing and editing of categories, and on the tabbed management interface on the side of the screen.

John, already logged in to CalendarShare, opens his calendar to view his schedule.  By default, it opens to the current month.

Already familiar with CalendarShare, John selects Thursday and opens the category tab to manage his events.

Deciding he doesn't need his date to belong to its own category (an event group), he proceeds to click the new event button, assigning it by default to the "My Calendar" category.  A new event dialog reflecting these selections appears on the screen.

Eagerly, John fills in the relevant information about his date and clicks the OK button, and his new event appears in the appropriate calendar date and in his category manager.

Wanting to share this new event with Jane, he selects it in the category manager and clicks the share button at the bottom of the menu.  A new dialog appears asking for an e-mail address with which to share the event.

He fills in Jane's e-mail address and clicks "Share".  Since Jane does not yet have an account with CalendarShare, she receives an e-mail notification with the event's details and an advertising request to join CalendarShare.  Jane decides to check out CalendarShare navigates to the homepage.

She decides CalendarShare looks interesting, so enters her e-mail address and password and clicks the register button.  A notice appears telling her to check her e-mail and confirm, which she does and then logs in to the system.

Like John, she is taken to the current month in her calendar.  Unfamiliar with the interface, she double clicks the Thursday of their scheduled date and is taken to a daily details screen, whereupon she decides to post herself a reminder that she really ought to do laundry before her date.

She enters the reminder for herself, then clicks the add button.  Because she now wants to see her calendar, she clicks elsewhere on screen, closing the window.  Since she has recently added an event, the category tab opens on the left hand side of the screen, revealing the new addition.  In addition to the event appearing in both the date and category windows, she notices small boxes have appeared in the days leading up to the date, presumably as a reminder.

Wanting to share her good fortune with her friends on the hall, she looks for a print option so she can post the calendar on her door.  Glancing over the newly-revealed categories pane, she discovers "Print" and "Share" buttons in the lower-right corner.  She clicks the "Print" button, and is confronted with an options dialog, asking what portion of her calendar she'd like to print, at what size she'd like to print it, and an option to create a PDF.  She designates only the current month, chooses 8x10, and clicks "Print", for which she receives the standard printer dialog.

Analysis of design 2:

This design emphasizes a simple, monthly-calendar centered view with all scheduling features aggregated into the same area of the screen.  This maximizes calendar visibility while keeping managerial actions easily accessible.

Learnability:  This interface explicitly features a new "Category" construct which would be unfamiliar and perhaps unintuitive to calendar users; however, its similarity to file systems/directories should make its function and operation slightly easier to understand.  Likewise, containing all the relevant operations (i.e. adding, editing, and deleting of categories and events) should help new users understand the function of this unfamiliar construct.  We include consistent features like event adding by double click on a day in the monthly view to make basic features easy to find.  The appearance of the "Add Event" dialogs which seem very consistent with existing calendar applications might cause some confusion because their behavior is inconsistent with these models.  (i.e.  Different types of events are created based on how many and which time entries are added; adding only an "end" time to an event creates a "deadline" which also creates reminders on the previous days of the month, unlike other types of events which are localized to the date on which they occur.)  We are hopeful that the ": to/by :" wording on the event dialogs will encourage new users to explore various combinations of time data to discover this functionality.

Visibility:   This interface focuses on visibility of state, allocating as much room as possible to the relevant calendar data (the monthly view).  This view also offers a somewhat unusual view of a person's schedule by making a category-centered view of calendar contents visible in the category window.  (This might be helpful in helping a user determine which of their activities plans furthest in advance or which consumes more of their time, for instance.)  Most actions are initially invisible to the user, hiding under one of three tabbed panes to the left of the window.  Upon opening one of these panes, however, most of the calendar functions become readily apparent as buttons.  We also anticipate that this interface would support drag and drop and familiar keyboard shortcuts like new, copy, and paste in the category pane, which would be afforded by the pane's similarity to a file manager.

Efficiency:  Unfortunately, by allocating most of the screen real estate to the monthly view, the interface does require a number of extra mouse clicks to get to certain actions, such as creating a category first requiring an opening of the category pane.  The use of dialogs also requires some extra navigation (to the dialog) and mouse clicks, but it affords a less complicated interface which we believe will be appreciated by less experienced users.  We strategically place the control tabs along the left edge of the window in order to eliminate some of the time lost in navigating to these features.  We anticipate using defaults (such as opening the category pane on event additions) will also alleviate some of this inefficiency.

Error Prevention:  Because we anticipate some of the action buttons (and selections in the category pane) will be quite small, we expect accidental clicks to be fairly common.  We deal with this by making state information (such as dates, categories, and event descriptions) quite visible in any initialized dialog, though it is up to the user to confirm the correct selection.  Since the create, edit, and delete actions are very visible at the same time, error recovery should be relatively straightforward, though we do not anticipate creating an event creation/deletion history to support undo.  (Typing mistakes should be handled by the browser's own undo functionality.)  We do expect uncorrectable errors could occur on share actions, where a user types the wrong e-mail address or mistakenly selects the wrong event before clicking the share button, but short of producing a confirmation alert after every share (which we expect would be largely ignored), we feel there is little we can do to recover from this error.  (Here, too, we rely on visibility of state and the attention of the user to prevent such errors from occurring.)

Design 3

Design 3 emphasizes the ease of viewing in the monthy, weekly, and daily contexts, and transferring between all of them. The notes/todo lists are always visible, as well as some sort of monthly view in order to give context to the dates.

Following the story, we begin with John looking at his calendar. By default, he sees the monthly view, and can change months via the tabs at the top of the screen. When he mouses over a particular date, tabs appear on the box for that day, and on the side of that week as affordances to go to the daily or weekly view. All of the visible days' notes appear in the note box. Because this is likely to be a lot of notes, the box automatically scrolls to the day's notes that the mouse is hovering over.

 John looks at the weekly view first. There is a smaller version of the monthly view in the upper left corner for navigation, and a space for notes beside that. This particular view has better visualization of the timing of events during the day than the monthly view. This view looks a lot like the weekly view of Google Calendar. The notes in the weekly view has an auto-scroll that is similar to the monthly view. John proceeds to select the daily view for Thursday.

The switch to the daily view keeps the monthly view in the corner, and the time visualization introduced in the weekly view. However, since only one day is visible, that day's schedule is put on the side, and more space is given to the details of particular events. When John mouses over an event, he sees the description for the event in the center pane.The event description has several fields. The title field is simply a short text field. Its entry will serve as the identifier for the event in the monthly and weekly views. The time field effects the event's graphical representation. There is a repetition field (not shown in the picture) that allows the user to select via check boxes the days of the week that the event repeats. The category selection field allows the user to put the put the event in one or many particular categories. The categories that an event is in effects the color coding in various views. The people field describes who can see the event. There will be a selectable pencil to the side of every name indicating that the person also has permission to edit the event. The location field is a text field with a link to Google Maps right beside it. Finally, there is a section for miscellaneous notes about the event. The miscellaneous notes might be heavily used for the joint planning of events, or taking notes about certain prerequisites for going. For example, a potluck event might have the event-specific note "make jello" in this field. There will also be a delete button on this screen, allowing the user to more easily delete an event (not shown).

John wants to put in his new date with Jane into the calendar. He clicks and drags in the appropriate time range, and a new event pops up in the center, ready to edit, with most of the fields simply blank. The time slot is automatically filled in based off of the dragging motion that he performed in order to create the event in the first place.

The event data in the center pane visible here would have been reachable from the weekly or monthly view by clicking on the appropriate event. However, instead of being integrated into the view, it would have covered up sections of the weekly or monthly view.

The people field is more than just data associated with an event. It is also the method of sharing calendars. John starts typing Jane's name. Because she does not have an account, the auto complete cannot help. Instead, John must type her entire email address. When he is finished, the system sends an email to Jane telling her that there is an event waiting for her at CalendarShare, and encourages her to visit in order to see it.

When Jane clicks on the link, she sees a very similar view to what John did when he was logged in. However, she does not have any categories available, because she is not logged in. Also, she cannot edit anything because there is no way to give her those permissions without an account. If she is interested, she can easily create an account by clicking on the button provided.

When she clicks on the login  button, a smaller screen pops up that allows her to log in with an account she might already have, either because she created one before, or with her facebook or google account. She can also create a totally independent new account. All that she needs is an email address and password. The email address is pre-populated with the email with which she received John's email.

After making her new account, Jane realizes that she won't have anything to wear to the lunch because she has not done laundry in three weeks. She therefore puts in a deadline for having done laundry right before her date. The deadline's graphical representation in the calendar is shown as a bold line. The only difference between an event and a deadline in the event view is that a deadline has no start time or date. It only has a finish time.

In order to print out her calendar, she simply takes a screen shot and prints it out.

Analysis of design 3:

The interface focuses on providing many levels of granularity for the viewing process, allowing the user to get a more precise picture of his/her time usage.

Learnability:  This interface is easy to learn because its thee main views have strong correlation to other calendar formats not only online, but in print. Adding an event currently does not have many obvious buttons, so a user who is not used to just clicking on spaces in the screen might be confused. However, there is a lot of tactile manipulation, so once the user makes the step of clicking, it should make sense from there. To keep the interface simple, a lot of the functionality only appears when the user tries to do something that suggests that they might want it, especially when sharing events.  Because the sharing functionality is combined with the event editing, it may take some users time to realize how to modify these sharing permissions later.

Visibility: This interface focuses on making the state as visible as possible without heavily compromising simplicity or user freedom. All of the events that the user is interested in organizing are ready to view in three formats, in increasing levels of detail. It also tries to provide a consistent context with the monthly view residing in the top left corner. There is no state that it is impossible to view, although viewing event details in the non-daily view requires an extra click.

Efficiency:  This interface is reasonably efficient because there are redundant ways to do things. Instead of having to do a certain series of clicks in order to get to a particular screen in order to add or view an event, each screen is only a click away. Because all event management is aggregated to a single screen, users can quickly create, read, update and delete without much navigation overhead.  If a user does not discover these redundant options, however, navigating to the daily screen to create an event could introduce some inefficiencies.

Errors:  Everything in the interface is editable, so any errors that do occur will simply be overwritten when the user goes back to fix it. There are only two potentially irreversible actions:  deletion, which would require creating the event from scratch, so we will have a confirmation dialog after every deletion, and accidentally sharing with an incorrect e-mail, which can be corrected but perhaps not before event details have been received by the wrong person.  (Autocomplete may help prevent spelling errors which would cause these sharing errors, but may also cause such errors if the user completes the action prematurely.