Design
Describe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
ReadingÂ
This interface is meant to display feed items to users, so they can be read. Users see a vertical news feed of items. As they scroll down, items are marked as read, and users can mark items as unread for the less common case where they intend to reread them later. Hubbub pulls live data from four sources: Gmail, Twitter, Facebook, and Imgur.
This design remained relatively constant through prototyping, with a couple of exceptions: the paper and computer prototypes included a "Share" button which would have shared the item in question on its social media website (e.g. retweeting for Twitter items). When we implemented the computer prototype, we realized that space was at a premium (a constraint that was not immediately obvious when paper prototyping). Feedback to the computer prototype indicated that controls were taking up too much space relative to the actual information that users wanted to read. Also, the meaning of "Share" was ambiguous - what would it do for Gmail and Imgur? So, we removed it from this version.
In addition, the paper prototype was colorless, and we originally planned for the interface to be mostly grayscale (except for the heading) for simplicity. When working on the computer prototype, we decided to use color to make it easier to tell the interfaces apart (noting that the labels became relatively smaller than the text versus the paper prototype layout because of screen size, and thus needed more contrast). We selected colors to try to stay externally consistent with the information sources; e.g. Twitter is light blue, Gmail is brick red, and Facebook is dark blue. In the computer prototype, we made Imgur yellow, but on closer inspection of their design and feedback in heuristic evaluation, we realized green was more externally consistent and used that instead.
Tagging
Users had the ability to tag feed items, categorizing them for future perusal. Hubbub provided an interface that allows users to pick tags from a list, and also create new tags to add to the list. Tags are persisted in the backend using a database. One original idea we considered was dragging tags onto feed items, but we realized that screen space constraints implied that tags would have to be on a separate page. We used checkboxes to allow aggregation; users can efficiently apply multiple tags to the same item at once.
We made one change from the paper prototype to the computer prototype - adding a wide rectangular area (with a gray background) around each checkbox, and registering clicks inside the area as checking the box. This combats the "fat-finger" problem, which was not obvious when paper prototyping but appeared when testing the computer prototype.
Between the computer prototype and the final version, we moved the button used to cancel tagging. In the paper and computer prototypes, we had a "Cancel" button at the bottom, next to the "OK" button. We decided to move it to the top and rename it "Back" for two reasons: first, having two buttons next to each other was harmful for safety - users would fat-finger one button when they meant to click the other; and second, the filter interface had a "Back" button at the top-left serving a similar purpose, and updating the tag interface improved internal consistency.
Implementation
Describe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
Hubbub's interface is written Javascript using Backbone.js, jQuery, and Twitter Bootstrap. Persistence is achieved by communicating with a Ruby on Rails server application running on Heroku with a PostgreSQL database. When users authenticate with third-party services like Twitter, the server talks to Twitter directly to download recent tweets and store them in the database, which it processes and serves to the client as JSON. Authentication with services uses OAuth, so users do not have to disclose their passwords.
Filters are saved in the database so that the user can access them no matter where they log in, but the server doesn't use them to determine which items to send to the client. Therefore, it sends all items to the client, which will become a performance bottleneck eventually.
Evaluation
Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision. List the usability problems you found, and discuss how you might solve them.
There was no demo, but users were briefed:
Hubbub is a mobile application for people who want to stay on top of information from high-volume sources like Twitter, Facebook, and Gmail. Hubbub lets you skim information from all those places in a single combined timeline.
Reflection
Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.