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Â
(Some names blacked out for privacy)
This interface is meant to display feed items to users, so they can be read. Users see a vertical news feed of items. We picked the vertical feed format (as opposed to one item per page, or horizontal swiping) for external consistency with other news feeds, and also because users tend to be more willing to scroll vertically than they are to scroll horizontally or constantly hit "Next Page" links. 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.
Filtering
(Text has been shrunk so the image is not too tall)
Users can filter the feed items displayed to them, to look at what is most of interest to them currently. We gave users the ability to filter by service, by content text, by tags, or by existence of hyperlinks. This interface gives users a fair amount of power, but it was also the trickiest to design for learnability. When showing our paper and computer prototypes to users, the filter interface tended to be the most troublesome. In particular, users were unsure how the different criteria composed (boolean "and" or "or"?) and some were confused about the function of the service icons or the text box.
The interface for the most part uses standard widgets like checkboxes for external consistency An alternative approach would be a drop-down menu, but those are susceptible to fat-finger problems, require more clicks, and are typically not used on phones so users are less familiar with them in that environment.
We made several changes to this interface to address these problems. First, we updated the icons in the Services section. Previously, we only showed faded icons for each service that became highlighted when selected. Users were unsure whether these icons were clickable, so we added checkboxes next to them (that get checked at the same time the icon is highlighted); users can select a service by fat-fingering the general area bordering the icon and checkbox. Unchecked checkboxes are an affordance showing that something is clickable.
Next, we updated the wording of the header text in the form. Previously, we had fairly minimalist text that simply named the category, like "Services", "Tags", and "Text". We updated the headers to be more verbose, which made the interface less minimalist but gave users more guidance and helped answer the "and"or"or" question.
The paper and computer prototype had a collapsible region called "More Options" which included the tags and the "Has a Hyperlink" option and was hidden by default. The collapsible region used less space, but had flaws. Users in paper prototype testing had a harder time finding options inside the collapsible region. The region also impaired efficiency by requiring one more click to access the items in there. Finally, one heuristic evaluator reported that it was unclear whether the items inside the region were selected when it was collapsed. For these reasons, we decided to eliminate it and show all sections all the time.
Our final change was to the button controls. In our paper and computer prototypes, we envisioned the "Execute", "Save Filter", and "Reset" (renamed "Remove Filter as users thought "Reset" would clear the form, not remove the filter), buttons to be grouped together. Heuristic evaluation pointed out the fat-finger problem; users would click one button while meaning to click another - this version has one button in each corner to avoid that.
For reference, here's a screenshot of the filter interface from the computer prototype. The new interface updates alignment of form fields to make scanning easier.
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.
Using a browser-based interface made Hubbub run slower than native apps. However, various updates to improve performance made the delay tolerable, and as a benefit, it runs on all smartphones, not just iPhone or Android.
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.