Design

One of our first major design decisions was to determine what level of detail the default display of the calendar should show: daily, weekly, or monthly views?  Because the idea of the pocket or purse calendar formed a central metaphor for much of our design process (including the incorporation of notes), we eventually settled on a monthly view as the default.  Our design decision in this case was also motivated at some level by efficiency concerns, which was also one of our main goals to improve over the most popular existing implementation (Google Calendars).  While in the monthly view, a user is able to create, manage, and view events for an entire month, while retaining sufficient detail as to be useful.  (That is, the improved visibility of calendar state in the weekly view was outweighed by the ability to add events to 30, rather than 7, days.)

However, while the visibility provided by the monthly view is "sufficiently useful," in terms of scheduling new events, it does not show a sufficient level of detail to be very useful as a reminder for "what [the user] has to do today," so we compromised and added a more structured and larger daily panel to the right.  In our original model, the user could specify some number of days over which a particular deadline should be visible, so this daily panel was split into two sections to help keep one-time occurrences separate from running concerns.  This daily panel also became the home of many of the object management features of the interface, because of its larger clickable area and in an effort to keep the main portion of the interface simple.  This basic structure was chosen after paper prototyping of two wildly varying designs (the other of which defaulted to a weekly view and required navigating a myriad of screens to add an event) proved it preferable.

The notes panel, which is in our final design as a permanently-visible panel nearly identical to the daily panel on the right, went through several iterations at every stage.  In one of our original designs, it was hidden under a button on the left hand side of the screen in order to allow the main body of the calendar to occupy more screen real estate.  In its final iteration, notes can be attached only to the month as a whole, but in our original plan they could be attached to daily, weekly, or monthly views.  During paper prototyping, both the original hiding of the notes panel and these divisions were criticized by the users, who said "I would never use the notes feature if it wasn't visible when I opened my calendar" and that "the differing placement of daily, weekly, and monthly notes confuses me--I'm not sure why you can put them in three places."  

Several different methods to add notes were also discussed during paper prototyping, including a popup (rejected because it hindered monthly view visibility) and a permanently visible text box with "Add" and "Clear" buttons in place of "OK" and "Cancel."  This latter option was rejected by the users who thought that the text box occupied too much space and hindered the list visibility, and also because they were confused about how the "Add" and "Clear" buttons functioned; most expected the "Add" button to generate a popup or enable the textbox, rather than adding the content of the text box to the list.  This led us to develop the solution which was integrated into our final design, a large, highly-visible "Add" button which expands into the included textbox, which closes on "Cancel."  The heuristic evaluation revealed yet another mildly confusing behavior with this function, however, because users expected the text box to close again after the note had been added; some also criticized the lack of differentiation between notes and the placement of the delete button (originally at the bottom of the panel).  The final implementation was changed to include the recommended behavior, as well as separating notes by black horizontal lines and duplicating the delete button within the body of each individual note.

One of our major points of trouble while developing the design was innovating a new way of dealing with rapid navigation and making this functionality visible to users.  Most calendar applications we examined had no quick way of navigating more than a single month away from the current date, or these features were difficult to find if they did exist.  We considered a few alternatives, including a button labelled "Jump To" on the left side of the screen, a drop down menu, and two independent drop down menus for the month and year before settling on the current panel in its current position.  The "Jump To" button had insufficient affordances and was ill-placed on the screen, being overlooked by most users during paper prototyping, and both drop down menu options proved inefficient by comparison to the panel shown above during computer prototyping.  We settled on making the monthly label at the top of the calendar serve double duty as the button for this navigation panel, although some users still had difficulty finding it.  In our quest to implement faster navigation, we forgot to implement the expected "left/right" navigation between calendar months that every calendar application has, and added them after heuristic evaluation revealed their absence as a source of confusion.

We determined almost immediately that event addition and editing should be a part of the main body of the interface, and not involve navigation to a separate screen, for the sake of efficiency.  We toyed with several ideas about how to implement this, such as making the form a part of the daily panel (rejected because it posed learnability concerns) or overwriting one of the side panels (rejected in favor of higher levels of visibility and interface consistency).  We settled on creating forms in "popup" windows, even though they hid part of the monthly view.  We placed them in the center of the monthly view for two reasons:  first, because it put the form squarely in the user's locus of attention, and second, because we presume most users will expand the day they wish to add an event to into the daily view, which offers improved visibility over the monthly view in any case.

We then turned to the question of the contents of this form.  In our original model, events and deadlines were almost indistinguishable objects, so we at first tried to make them both available from the same form.  This failed miserably during paper prototyping, because users either would fail to select an event type (and thus be unable to add it to their calendar) or would not understand the distinction between the two types to begin with.  On the next iteration of the interface, we made these objects distinct form one another in their appearance on the calendar and form; we also made it impossible to switch directly from the new event form to the new deadline form as an error prevention measure.  We also made the slightly unusual decision of allowing an event's date to be changed from within the form; while this made errors more likely, we believe the resulting efficiency boost (for people who might schedule months in advance without looking at their calendar) was worth the trade-off.  (Allowing this feature also made for simpler error recovery in the event that a user added an event by double clicking the wrong day.)

One of our last design challenges was choosing how to incorporate the editing and deletions into the interface while minimizing errors and maximizing learnability.  We decided to use the same behavior across our entire interface; one click selects an object, while a second click allows editing by opening the object into the same form or text box in which it was originally created.  While this behavior is not readily visible without randomly exploring the interface, we believed it both internally and externally consistent enough to be found with little trouble.  (Most of our user tests confirmed this notion.)  We also considered a single click for editing, but decided it would cause more errors than the efficiency warranted, and limit other behaviors (such as the ability to select or view some object larger on click).  We also made the decision not to allow this select/edit behavior available from the monthly view, restricting it to the daily view for error prevention and to allow a larger selectable area for days as a whole.  (We and our users both still wonder about this decision, being almost precisely half supporting and half opposing it.)

Deletion behaviors, by contrast, caused almost no issues during user testing, with the exception of some questionable button labeling (see the evaluation section below).

Implementation

Overview:

We used HTML, CSS, and Javascript (with jQuery) to implement the front end of our application.  Since the front end was a deliverable in and of itself for this project, we coded the front end before the back end.  We ended up storing information in the front end that ideally should have been stored in the back end.  For example, the layout of the calendar system (how many days in each months, which months begin on which days in which years, etc.) was all in the front end in Javascript.  The back end MySQL databases contained three tables -- for notes, deadlines, and events.  XMLHttpRequest Javascript objects were used to execute PHP scripts.  The PHP scripts called the appropriate MySQL commands to fetch/store the information from/to the databases.

Some important design decisions we made in the implementation:

We coded the front end using HTML and CSS.  In order to implement dialog boxes, we used <div> tags and hid them when appropriate.  This design choice caused the resulting dialog boxes to be slightly awkward.  They don't have the ability to be moved by dragging on the toolbar and they don't have default minimize and close buttons.  If we had used Ruby on Rails or Flash or some other development tool, designing dialog boxes would have been more native and simpler.

We decided to access the back end using XMLHttpRequest objects and PHP scripts.  This enabled AJAX to be used.  The alternative would have been to populate html forms (hidden, if necessary) and submit them with the PHP script as the target.  This would have been more confusing because it is synchronous and would have refreshed the entire page.

How implementation problems may have affected the usability of the interface:

Implementing the back end took an unexpectedly long amount of time.  As a result, many of the front end features that we would have liked to include were not implemented.  For example, we do not have multiple accounts in our application and we do not have a visual representation of the number of days that a user wants to be reminded before a deadline.  Additionally, we wanted to make the individual day squares clickable so that an event can be edited without navigating to the right hand side of the page.

Additionally, the database that we used seemed quite slow.  This created a feedback issue, since users thought that the application was broken because their actions did not cause a visibly changed state fast enough.

Evaluation

To conduct random user tests, we sat in a public lounge on MIT's campus and asked passersby for volunteers.  Unfortunately, these users came only from the academic subset of our user base, but were from different enough backgrounds to experience a variety of difficulties.  We tested one Course 3 junior with an admitted dislike of computers and two freshman.  Of the three users, all had previous experience with Google Calendars.  One of the freshman also used iCal and the other used the calendar application built into her iPhone.  We would have liked to have tested some users without Google Calendar experience, but were not lucky enough to find one.

We gave our users the following briefing and asked them to complete the following tasks.  We did not conduct a demo for them since we expect most of our users would learn the interface by themselves, not by watching others.

Briefing:

CalendarShare is a new alternative to Google Calendar which we hope will be easier to use for people who are unfamiliar with calendar applications.  In addition to being a calendar which contains events with a fixed start and end time, our application has notes, which function like scribbles in the margins of your physical calendar, and deadlines which are visible over a span of time before the due date occurs.  As an improvement over Google Calendar, we try to aggregate all of the management functionality such as the editing and deleting of things on the calendar in a single screen.  Your participation is completely voluntary and at any time you can stop.  Any difficulties you experience are our fault, so don't feel bad if you have a hard time.  Feel free to talk to us about what you are thinking as you complete the tasks. Thank you for your participation.

User Tasks:

1) Add a note to December 2011 saying "Buy Gifts".

2) Add a final exam to any day of finals week (May 16-20, 2011) with a start and end time.

3) Edit the final exam you added above and put your expected grade in the details section.

4) Delete the deadline on May 19, 2011 that says "Delete Me".

The User Tests:

Our first user was very timid about exploring the interface; she seemed very reluctant to try any button which did not directly correspond to Google Calendar's functionality.  For instance, when asked to add a note to December, she clicked through every intervening month by using the familiar right arrow, rather than trying to find a faster way to navigate.  (When she did eventually have to go back to May, the slow nature of our backend implementation frustrated her enough into finding this feature, but she might not have otherwise.)  She also stated that if the facilitator had not been sitting there and reassuring her that it was merely slow, she would have thought the application broken and given up.  She experienced no difficulty in adding events but could not figure out how to edit or delete them, until she stumbled upon it by accident.  (Even then, she admitted it took her a few tries to determine what she had done to open the editing window.)  She also mentioned that the "minus sign" did not indicate deletion to her at all, and she would have overlooked both plus and minus buttons when using the interface.

Our second user, having never used the interface before, experienced much less difficulty.  (Though, he also complained about the tardiness of the interface.)  He tried to use the right button to navigate once before discovering the quick navigation panel, and then preferred to use it exclusively (even when he'd mistakenly clicked "June" instead of "May").  Unlike our other users, who preferred to add events via double clicking the day or clicking the "New Event" button below the Month, Year label, he immediately went for the plus button in the daily view panel.  (This seemed peculiar to us, but validated one of our design choices.)  By accident, he also found a minor implementation error in that the event details would not accept "plus signs" as contents, causing them to be deleted from the backend.

Our last user experienced nearly as little difficulty as the second user, trying the same sequence of first pushing the right button (and discovering how slow the backend was) before searching for the fast navigation panel.  She (unsurprisingly) also tried to double click on the event inside the calendar itself to edit it.  This confused her momentarily, but after scanning the screen she discovered the daily panel on the right of the screen and edited an event with no difficulty.  Because she'd already discovered how to edit, when asked to delete an event, she went to the daily panel immediately, and then took only a moment to locate the minus sign.

All users were moderately confused about where to put notes, asking the facilitator "Should I add it to any particular day in December?" before locating the notes panel in December and dropping the question.  We suspect this was partially due to the unfamiliarity of the feature, and thus believe we made the right decision in removing different levels of granularity (day vs. week vs. month) from our original design of the notes feature.

Because we knew our decision to disallow event-based selection from the main body of the calendar was risky, we also directly asked our users if they would have preferred this functionality, and got three distinct and conflicting answers, leaving this still an open question for us.  For instance, our first user thought being able to double click the events in the calendar would have completely solved her editing confusion (if not her deletion problems), while our third said the feature would have greatly annoyed her (since she would prefer to be able to double click on a day and have it expand).  Our second user took the middle road, saying it would have been convenient to be able to double click the events in the calendar itself, but he prefers it as is since the current style keeps the interface from being cluttered and hard to read.

As exposed by our user tests, the most obvious problems of our interface are:

1. Slow backend frustrates users, both because it wastes users' time and because it delays feedback so a user believes an action failed when it didn't.  (Catastrophic)
2. Notes functionality is unfamiliar/unclear.  (Minor)
3. Lack of visibility of action (aggregation to daily panel). (Minor due to quick user adjustments).
4. Unclear button labeling (plus/minus instead of add/delete).  (Minor).

To solve these issues, we propose the following changes, where the number of the solution corresponds to the number of the problem listed above:

1. Unfortunately, there is very little we can do about the speed of the backend, since it is largely dependent on the speed of the user's web connection and the underlying SQL server.  Migrating to a different SQL server may alleviate some of the efficiency problem, while adding a progress bar for any of the operations requiring large calls to the server would help provide some feedback to prevent the user from believing the interface has broken.
2. Because note functionality is new and (possibly) unique to our interface, we believe that most of the confusion about notes would simply be alleviated as users became more accustomed to using them.  From a learnability standpoint, however, a help panel button or tooltip might help orient new users as to their use and scope.
3. We aggregated a number of functions to the daily panel in order to preserve the simplicity of our central view and preventing user errors (such as might be caused by trying to double click a day and ending up editing a particular event instead.)  Without compromising these principles, we could increase the visibility of the daily panel by adding short animations on event/deadline creation to draw the user's eye to this area of the screen.  If we instead decided that this functionality outweighed the simplicity and error prevention we tried to maintain, this could also be corrected by providing redundant functionality to the central month view.
4. The buttons primarily in question here are the add and delete buttons in the daily panel.  These are easily fixed by changing the "minus" to an image of a trash can and changing the "plus" to either a textual "add" or a "new file" button consistent with applications like Microsoft Word.  This was not done in the original implementation to avoid copyright violations (because neither of us is skilled at icon creation).

We are also aware of several other smaller issues we found on our own, but which did not seem to distress our users, such as undersized clickable regions, inconsistent selections, and a few other minor input problems (such as event end times which precede start times) caused by implementation errors and insufficient input sanitization.

Reflection

The iterative design process taught us a lot about creating user-friendly interfaces.  The main lesson we learned is that "You are not the user".  No matter how smart we thought we were and how clever our design seemed to be, our users' experience determined the success of the design.  If our users did not find an interesting feature or were unable to use the interface to complete the tasks, we have failed, even if we like our design.  For instance, we had thought having "notes" functionality that had different spans (such as daily, weekly, and monthly) would be helpful to users.  Instead, we discovered that users were completely confused by these distinctions and really had no use for them at all, preferring to use only the monthly notes feature.  We also discovered, to our surprise, that even highly advanced technical users may be timid about exploring a new user interface and might completely ignore a feature if they didn't understand what it was for.  We also came to appreciate just how vital cheap, fast, and repeated prototyping could be.

For example, we had two wildly different designs at the paper prototyping stage and could not unanimously agree on a single one, so we ended up testing two completely unique designs.  While this quickly exposed the superiority of one interface (at least in terms of learnability), we would also found ourselves at a distinct disadvantage when fixing the errors exposed by testing the winning user interface, because it became much harder to find volunteers to test a second iteration.  If we had to do it again, we would probably still have tested both interfaces, but we would also have spent more time developing and testing iterations of the winning prototype at this stage.  Consequently, what users we did test on the repeated iterations were also allowed to simply use the interface as they would (free-form test), which seemed to make them less timid about breaking things.

Although not required by any of the class assignments, we would also do more of this free-form user testing.  While scripted-task tests generally exposed problems with visibility, learnability, and affordances in the particular tasks, we found that free-form users tended to be less timid about exploring the interface as well as exposing certain critical deficits.  For instance, these tests exposed a number of tasks we had overlooked in task analysis, some false affordances in our interface, and some potential redundant actions which would help improve the learnability of our interface (i.e. double-clicking the day to add an event or deadline).  Free-tested users also tended to be less generous about things they didn't like or didn't work.  (Some of these testers even tended to be slightly malicious about trying to break the system, which helped us discover some troublesome errors.)

Because our project was quite large in scope at the outset, we had a large number of tasks and features which really needed to be tested early--therefore, we tried to cram as many high-level features into our early prototypes as we possibly could.  In retrospect, trying to do all of this at once made paper prototyping a bit more difficult and harder to iterate than it necessarily needed to be.  We probably would have benefited a great deal more from many smaller prototypes which tested less features.  For instance, restricting our paper prototype to a single month (and not incorporating a weekly view at all) would have prevented us from testing the visibility and efficiency of these features, but since most users experienced little trouble using these features, we would not have lost much by pushing these tests to the computer prototyping stage.  We missed out on testing some of our riskier design decisions in favor of less risky ones when we chose to prototype by quantity, which was a mistake in retrospect.  We should have spent more time testing the less consistent or more unusual features of our interface earlier in our design process, and tested the familiar much later.

When we did the user tests, we took note mostly of which tasks users had the most difficulty with and their apparent level of frustration.  When deciding on the order in which to fix bugs, we generally tried to fix the problems which afflicted the greatest number of users in order of user frustration (i.e. the most frustrating bugs were handled first).  This meant that we would fix sometimes less catastrophic usability errors encountered by several people before we tackled an inordinately frustrating bug encountered by a single user.  Of course, this sometimes varied by the level of frustration, such as forgoing a change in color scheme in favor of, for instance, including redundant actions for adding events, even if only a single person could not find the appropriate button.  This seems to have been one of our better plans, though admittedly some corrections had to be forgone entirely due to time constraints.