...
In this section, we explain the various parts of our interface broken down by essential task. We discuss our the design decisions we made, and their motivation in relation to our prototyping and analysis results.
...
In this section, we describe how we performed our final user test analysis for Hubbub. We had 3 students (not in 6.813) user test Hubbub. All three users owned smart phones and used at least a subset of the services Hubbub supports very frequently. However, our users were not as representative of our target user group as our potential users from GR1. There was no demo, but users were briefed with the same briefing we used in GR3:
...
Initially, we each had very different ideas for how we wanted Hubbub to look and behave, which translated into a lot of different interface sketches for GR2. However, by the end of GR2 we had a pretty clear idea for Hubbub's design, and some of our story boards ended up being fairly close to the behavior of Hubbub's final interface.
We explored different ways to filter feed information, as well as alternative approaches for presenting feed items to the user. Initially, we wanted to restrict the length of the feed based on the amount of free time the user had to devote to interacting with the feed. However, we abandoned this idea in favor of a more intuitive filtering interface. This made Hubbub's filtering implementation simpler for GR5, since the filtering algorithms were easier to implement. Considering how hard it was for us to make filtering intuitive, adding more complicated filtering algorithms would have probably slowed us down.
We also decided to provide a scrollable list of feed items. We felt that this was more efficient than our other designs, which required the user to swipe or tap a button every time they wanted to see a new feed item. The feed list ended up being very intuitive for our users, and none of them suggested changing this part of the interface's design.
...
The feedback we received from users interacting with our paper prototype was very helpful , and we were able to make several major design improvements on the fly. For example, we switched from a tabbed interface to a main page with navigation buttons because users found the tabs counter-intuitive. Doing this for our computer prototype would 've have been a lot harder, more wasteful since we would have had to throw away the work involved in creating the tabs in the first place.
We decided to focus on four sources of information for the prototype (Gmail, Twitter, Facebook, and Imgur), which lasted for the rest of the project. We actually had a long debate about whether to draw a larger or smaller paper prototype, and eventually decided to draw the interface bigger (which was the advice given by lecture and the TA's). Unfortunately, drawing the interface on a large sheet of paper obscured a space issue we had later on in terms of fitting buttons on the screen. When the interface became phone size in GR4, it was more cluttered and considerably harder to navigate. However, there was one user that told us she felt our interface seemed cluttered during paper prototyping. Since she was the only user that thought our interface was cluttered, we decided not to change it at the time. In retrospect, it would have been more beneficial for us to have users interact with a much smaller version of our paper prototype . We with which we could have caught our space issue much earlier.
...
The jQuery Mobile framework was great for prototyping Hubbub's interface. However, its performance was abysmal and we had performance issues that forced us to replace it (with Twitter Bootstrap) before starting on GR5's backend.
...
Heuristic evaluation was very helpful and we incorporated several suggestions from our evaluators into GR5. In particular, we realized that the filtering interface was confusing , and devoted more attention to its learnability in response to feedback.
...
Switching from jQuery Mobile to Twitter Bootstrap made our application much more responsive, and actually simplified the code in places!