...
Another debate our group had is whether it was better to possibly rename the ‘MyCalendar” tab to ‘MyEvents’. Given our final implementation, after other features were scrapped, this change probably makes intuitive sense, although it is a relatively minor change in terms of usability.
On the navigation bar, the current page was highlighted in orange (in this case the ‘Browse’ page) and the when the mouse was over any clickable object in the navigation bar the object displayed a green hue behind it to show that it was now clickable. Overall these features are easily learnable, simple, visibly aesthetic, and extremely efficient.
...
The search bar is available on every page and will always return its results in the ‘Browse’ page. Our original design was for the search to return all events and people that matched the query and then provide some additional on-page filters like the events, people, friend versus non-friend, and event the user is attending versus not currently attending. Our current implementation only has the query results for events and they are displayed in the same visual format as we do for displaying all other events. The results show what the query is with ‘Displaying results for ‘event’’.
The way events are displayed was designed to provide chronological event management for the user. We chose it because it works very well when the number of events in the system is small (during implementation and user testing), but we do not believe it would make the best representation as the number of events gets larger.
...
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: (‘.
...