...
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.) 
Wiki Markup
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."
...
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.
...
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.
...
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.
...