GR6 - User Testing

Design

Our design goal was to come up with a clean, simple interface that felt very web 2.0.  We wanted our site to really center on users finding and managing their own events, while not feeling too much like Facebook.  This vision led to a number of major design changes between our original paper prototype to our final implementation including: removal of Google Maps from the home page, removal of groups, a de-emphasis on user profiles, and the removal of all sidebars.  There were also a number of design decisions we made in our final implementation because of the man-hours that would have been necessary to incorporate into what we considered a very expansive GR5 implementation.  This included: the use of friends, the ability to update event information, messaging between users, inviting specific users to an event, user notifications, event privacy settings, creating an event that occurs weekly, and alternative visual representations for a user to manage his events.

Some of the design decisions mentioned above will be discussed in more detail but others were metaphorically scrapped to the floor during prototyping and were not really discussed again.  

The navigation bar was one of the most debated and best parts of the design.  The site was simplified dramatically between design iterations to the point where in our final implementation the navigation bar was a 1-step process to take the user nearly anywhere on the site.  ‘Browse’ brought the user to the main page, which listed all events in EventHub.  ‘Create’ brought the user to a single page where events were created.  ‘MyCalendar’ brought the user to a page that listed all events the user was attending. ‘People’ was unfortunately left unimplemented due to time constraints, but would have brought the user to a page displaying all friends.  ‘MEGAN.KERCHER’ is the name of the current user and brings the user to his profile page. ‘LOGOUT’ simply brings the user to the original sign-in page.

One of the big discussions we had concerning our navigation bar was where to include ‘Create’.  Event creation is not like the other options which are for managing events and friends, but where should it go?  We thought about putting it beside the search bar or possibly making a special icon for event creation that would go next to ‘Logout’.  One other thought was to put ‘Create’ inside of the ‘MyCalendar’ page.  At the end of the day, we decided that our interface was simple enough that users would not be confused by the differing functionality from the other tabs.  We also wanted to emphasize event creation in the site, and we believed that making event creation even slightly harder to navigate towards was a step in the wrong direction.

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.

We also made a few other aesthetic changes to the navigation bar between the computer prototype and implementation that are worth mentioning.  First is the ‘eventhub’ icon.  This icon is very elegant but also feels web 2.0 with its coloring and lower case letters.  More white space was also incorporated in the final design; the buttons were made slightly smaller and the incorporation of the search bar beneath the tabs made the navigation bar feel spread out from the page content.  The ‘Change location’ button was designed to filter events in the ‘Browse’ page to be those located in the user’s area.  Unfortunately, we did not have time to implement this feature.

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.  

This layout does have some nice aspects though, which can be seen better in the snapshot below.  It contains lots of white space and the way events are displayed looks good, efficiently uses page space and provides necessary information to the user about the event.  The event name is clearly clickable and below the name it specifies the start date, start time, event location, and then the event description. The major piece of information not shown is who else is attending the event, which was a part of our original design and would ideally be here as well if not for time constraints.

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 not only looks good, but also makes it easier to select dates. In order to reduce error, 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: (‘.

The original design for the event page included a list of attendees (similar to Facebook) as well as a sidebar that allows a user to invite a friend to the event given the correct admin permissions.  These features would be really nice to incorporate but were left undone due to our time frame.  Therefore, the current list of attendees is static.  Overall this page design is nice looking and has a lot of white space while still providing all important information.

The only functioning part of the page is the comments at the bottom.  Comments are displayed sequentially with the most recent comment displaying at the top of the list, closest to the textbox.  

This design makes reading long lists of comments confusing since it requires reading up the page, but at the same time that may be better than the alternative of needing to scroll to the bottom of the page just to see the most recent comment, which very well may be all the user is looking for.  In that case though, the user would need to scroll all the way back up to make his own comment in response, which is very annoying.  Overall, neither option is wonderful but we figured this design was  slightly less frustrating for long list of comments and easy to figure out for a small number of comments.  One other thing worth noting is that we did not include a timestamp of the comment next to the comment, so it is not even clear which way the comments are sorted until after a user makes a comment himself and sees the page update (not ideal).

Implementation

In order to implement EventHub, we decided to use Google App Engine for several reasons:

1. It's really really easy to set up the environment and database, and we wouldn’t have to worry about technical problems and incompatabilities with our various systems without using a Virtual Machine.
2. We were able to use python for the back-end, which made it easier for all of us to ramp up
3. Databases/filters are not difficult to implement
4. For the front end, we could use the Django templating engine, and templating engines are awesome because they make it easy to separate back end from front end and cut down on code duplication.
5. We wouldn't have to worry about accounts and login information because we’d be able to take advantage of google login.
6. Easy to put up on the web at the end. No worrying about configuring servers.

Overall, we think App Engine was the right way to go. It was extremely easy to set up and get a database/templating engine set up on all of our machines. We also were able to do server-side operations without having to worry about learning a new language. The biggest problem we faced was that not everyone on the team completely understood what the templating engine actually did behind the scenes. This lead to a lot of bugs and frustration.

We also realized way too late in the game that App Engine wasn’t magical and wasn’t going to make everything as easy as they lead us to believe in the tutorials. Don’t get me wrong -- it made everything easier -- just not ridiculously easy. Why? Well it turns out that App Engine has all these really annoying technical intricacies that we hadn’t anticipated. And the database/filtering wasn’t as advanced as we thought it was. And, ironically enough, App Engine doesn’t already implement full-text search... even though... you know, Google happens to be really good at search. So we spent several hours trying to figure out how to make various undocumented packages we found online work for us. We also had to cut the filters because they wouldn’t play nice with our full text search (and frankly, full-text search was cooler than filtering.) Technically we could make it work, but it would have taken more time than we had.

We also took advantage of BlueprintCSS for the front-end layout. We thought it would make alignment much easier because it allowed us to use a grid-based system. However, once again, not everyone on the team was completely familiar with it, and while it made certain elements easier, it really crippled others in a way that pure CSS wouldn’t have. It also cluttered the code and made it more unreadable than it should have been because it used HTML element classes to enforce formatting.

Additionally, we abandoned the feature involving integration with the Google Maps API for auto-completion of location because it was much more difficult than we originally thought it would be.

Evaluation

Briefing: "This is EventHub. It's a website for finding, scheduling, and posting events in the near future in your vicinity. So for example, if you have a couple hours to kill after class, you can come here and find something cool to do; or, if you want to organize a dinner with friends, instead of emailing everyone and juggling replies, you can organize it here. You're entering this situation in the middle of a user 'state': you already have friends, events in your calendar, all that. We're going to give you some tasks a normal user would do, and it would be extremely helpful if you would think aloud while performing these tasks. If you become confused or frustrated, please let us know because that means that we did something wrong, and need to fix it. You are free to leave the user test at any time for any reason. Any questions before we start? <wait for response> On that note, thank you for helping us improve EventHub!" (This is unchanged from the paper prototyping briefing)

Tasks

Task 1: Log in!
Task 2: RSVP for the event “Awesome Event” taking place on 5/12/11
Task 3: Uh oh, you’re going to be late for “Awesome Event”. Leave a comment letting people know.
Task 4: You want to play chess this afternoon. Create a chess game event for 4:00pm today.
Task 5: Log out.

User 1: MIT senior, fits target audience as a college student in the Cambridge area. Has no user interface experience. User was briefed as described above and given the tasks above one at a time. The test went smoothly: the user completed all tasks without problem; the only intervention required was to explain how things should work if they had been fully implemented (in this case, the RSVP button on the "Awesome Event" page didn't visually toggle like it was supposed to). User was unsure about the difference between the Calendar and Browse Events tab; perhaps we should change the title of the Calendar tab to "My Events" or something more descriptive.

User 2: MIT senior who also fits the target demographic and has no previous experience with EventHub.  User was briefed on tasks and was able to complete them all successfully without any need for guidance.  As with User 1, User 2 had a number of questions regarding unimplemented features like the RSVP button that toggles and the Friends tab that does not show any people.  User mentioned that he really likes the idea for the site and liked the "feel" of the site.

User 3: MIT junior who fits the target demographic and has no previous experience with EventHub. User looked at list of events quickly searching for 'Awesome Event', after a couple seconds, user searched for event in search bar, and successfully RSVP’ed. He mentioned that events didn’t clearly display the date (they are labeled, today, tomorrow, etc.) The search bar was definitely visible, though. Perhaps we should use a calendar box next to each of the events to make the date more clear. User also experienced delay when in looking for the 'Create' button -- it wasn't significant, but you could tell that they didn't immediately remember where it was. More testing would be required to find a better location for it.

Reflection

The biggest thing we learned was that making a good implementation takes a lot longer than we expected.  Everything was moving very smoothly for us until it came time for implementation.  We had initially come up with a big idea for our project and over the course of GR1 through GR3 we narrowed our vision into something that seemed like a good idea and very achievable.  The team seemed very optimistic about working together and everyone was communicating well and making compromises to their ideas in order to accommodate other’s ideas into the prototyping. Unfortunately, the biggest issues for us seemed to focus around coming together as a group on an aesthetic vision for the site and then implementing.   

When it came to implementation in GR4 and GR5, our approach was fairly standard for MIT, partition the work and hope that fitting the pieces together into a final product at then end is not too difficult. One major issue for us was that our prototyping up until that point had focused on spatial layouts and pages but not enough on designing elements on the page or thinking about look and feel.  This led to some confusion and disagreements come crunch time.

I don’t think we realized as a group just how big the jump is from prototype to implementation. We all felt very comfortable after GR3 with the vision for our site in terms of spatial layout, navigational features, and what should and should not be clickable.  But the jump from GR3 to GR4 was pretty large and we ended up scrapping a number of features.  This included the ability to update event information, messaging between users, event privacy settings, creating an event that occurs weekly, and alternative visual representations for a user to manage his events.  We dropped some ideas because we thought they would be too difficult or time consuming, but mostly they were removed from the plan because they seemed peripheral to the site’s main goal of helping to organize the short-notice, quasi-important social events that make up our every day lives.  Interestingly, when we were adding a feature to a piece of paper it did not feel like much of a commitment; it was not until we started building the site that we had to decide what facets of the project were most important and which were not.

The jump fro GR4 to GR5 was even larger jump in terms of feature slashing.  We had gotten some good feedback on GR4 and had decided to do away with the Google Map, sidebars, groups, de-emphasize user profiles, notifications, and to really focus on event creating and management.  Our final vision was pretty strong but, unfortunately, was left only half-implemented because of poor time-management and unequal workload between team members.   

If we could do it over, the biggest thing we would have done differently is to spend more time on GR5.  It was a bigger project that any of us really realized, and finishing a project only half-completed left a bit of a bad taste in everyone’s mouth.