...
We had a lot of debate over the best way to RSVP to an event. Our current design has a toggle button that shows the opposite state of what the user is currently committed to. For example, because the user is not RSVP yes to the event ‘Thursday Party’, the button shows ‘Count me in!’ so that he can click it to attend. When he does so the button will change to say ‘Can’t make it: (‘. This design does not make much sense from a simplicity or error handling perspective because many users may become confused. It would have been better to use two buttons where the current RSVP state is unclickable or to have a single ‘RSVP’ button and then a popup screen to chose (like Facebook does).
The last major aspect of the design was the ‘Create’ page, snapshots shown below. The fields necessary to create an event are ‘Event Name’, ‘Start Date’, ‘Start Time’, and ‘Event Location’. The optional fields are ‘End Date’, ‘End Time’, and ‘Event Description’. If one of the necessary fields is not filled in when the ‘Create Event’ button is clicked then an alert pops up, as an be seen in snapshot below. Preventing improper events from being created is essential for error prevention for the backend data storage. It is also important to communicate this to the user and give them easy to understand advice as to how to avoid this issue in the future. The snapshot below is missing an ‘Event Name’ and the corresponding alert states: “Please give your event a name”. Very easy.
As for other design decisions, using a calendar for date selection looks very cool. Only days from the present day and forward are clickable and it is very easy to navigate between different months, if necessary. The ‘End Date’ only allows dates subsequent to the ‘Start Date’ to be clickable, which is another nice feature. Our original computer prototype had string inputs for all of these fields which made it much less aesthetic on the creation page and also made searching for events and displaying events on the ‘Browse’ and ‘MyCalandar’ pages much harder to read for the user.
We also made the user specify time of day in a consistent manner. The snapshot below shows how each event must start on the hour or half-hour. This allowed us to handle time in a consistent manner, but it is also a bit annoying for the user since he cannot specify his desired time, which may be something as general ‘in the afternoon’. Also, the time of day scroll bar always starts at 12:00am and only reaches to 9:00am before it is necessary to start scrolling. This is a bit annoying because most events will not be done during this time of the day, meaning that scrolling to the desired time will almost always be necessary when creating an event. 
After an event is created, the user is brought to the ‘MyCalendar’ page. As we saw in a number of screenshots above, the event names are clickable, bring the user to an event page, shown below.
The event page shows the event information in the upper left corner. The date is shown in design mimicking the appearance of a real life calendar. It then says the event name, time, location and description. In the upper right corner is a toggle button, identical to the button discussed on the ‘Browse’ page, that shows the opposite state of what the user is currently committed to. For example, because the user is not RSVP yes to the event ‘Thursday Party’, the button shows ‘Count me in!’ so that he can attend. When he does so the button will change to say ‘Can’t make it: (‘.
...