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/Saving
The goal of this essential task is for users to be able to read items later. To do this, they signal that the item should be kept by hitting the save button, and optionally tag the item so it's easier to search for.
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.
In GR4, the "Save" button was a no-op, and items never disappeared. We had to provide a mechanism to phase out old items once live data became available, to avoid swamping our users with a massive feed. After feedback in the TA meeting, we updated the "Save" button to complement the tagging interface, by keeping around items to read later. Together, they comprise one of our essential tasks and provide better usability than the prototypes' version.
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.
We used jQuery Mobile for the computer prototype, but dropped it for the final version because it had significant performance issues.
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 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.
GR1 - User And Task Analysis
Our initial writeup for GR1 did not fully cover the details of the user population and listed only superficial details. We revisited it later and worked to resolve those issues. Evaluating the user population turned out to be quite important, to learn more about what they expect from our interface and how to fulfill their needs. The next time we go through the user interface design process, we plan to spend more time talking with users and understanding what they are looking for.
Also, our initial writeup did not clearly focus on the difference between essential and non-essential tasks (this has since been fixed). In the future, we plan to spend more time looking at the frequency and necessity of tasks to better understand what components to focus on. At this point, we picked three valid essential tasks: reading, filtering, and saving items to read later (which took the form of tagging items to make them searchable). Reading and filtering remained essential tasks in their current form throughout the whole project. Saving items for later was fleshed out into a tagging interface for GR2-4, and augmented with a save button in GR5.
GR2 - Designs
We were fairly pleased with how our storyboard turned out. It was fairly close to the actions most users would do with the final version of our interface.
Our designs turned out relatively well and provided a clear way forward when prototyping. We didn't consider the real-estate issue that come up when designing for mobile, but for the most part the GR2 sketches translated into a useful prototype. Looking back, considering the screen space issue might have made the results of GR2 even more useful.
GR3 - Paper Prototyping
The paper prototyping sessions were quite satisfying and getting feedback from users about our interfaces after they played out an interaction was very helpful. We made several amendments to improve the interface at a time when doing so was cheap.
At this point, we decided to focus on four sources of information (Gmail, Twitter, Facebook, and Imgur), and this choice lasted for the rest of the project.
Drawing the interface on a large sheet of paper hid the real estate issue that comes with designing on phones. When the interface was shrunk to phone size in GR4, it was more cluttered and fat-finger problems emerged. Even if users used their whole hand to "click" on elements, their input device was at a higher resolution than it is on phone screens. We don't think we should have drawn the paper prototype on a phone-sized sheet of paper - it would still not be that close to the computer interface, and Prof. Miller explained in lecture that building and amending a smaller-sized prototype is significantly less efficient (so a phone-sized sheet would have compromised our ability to respond to feedback from paper prototype testing).
GR4 - Computer Prototyping
This part of the project took a fair amount of work, but we were happy with the results. We were able to produce a usable interface suitable for heuristic evaluation. Starting work earlier could have made the process less stressful.
On the technical side, we used the jQuery Mobile framework, which was helpful in building the interface quickly. It had performance issues, so we had to make a brief detour to replace it with Twitter Bootstrap before starting on GR5's backend. The lesson we learned is that jQuery Mobile can help prototype, but is not suitable in its current state for final interfaces, and that you don't necessarily need a framework specifically for mobile HTML - Twitter Bootstrap worked fine, and is general purpose.
While jQuery Mobile wasn't the best framework, we think it was better than using no framework. Implementing grid layouts and UI widgets by hand would have significantly slowed us down.
Using canned data actually masked one problem - how to handle items being marked as read? We don't want to keep stale items indefinitely, but we also don't want to remove items the user still wants to see. Increasing the volume of canned data wouldn't have helped; a finite set of data will be exhausted significantly faster than data from a stream. Looking back, we could have implemented some sort of canned feed item generator that periodically added items to the feed, to simulate input streams.
Heuristic evaluation was very helpful and we incorporated several suggestions from our evaluators into GR5.
GR5 - Implementation
Our final implementation reached relative feature-completeness, incorporating live data from all four sources. We didn't get to implement the "Share" feature because of time constraints (it was a non-essential task). Starting earlier might have enabled us to get to it. We may have taken the time constraint too likely and not prioritized well enough - on a couple of occasions we fixed cosmetic/smaller issues when major tasks should have gotten more attention. In a future project, a better approach would be to completely handle all issues with major tasks before moving on to minor ones.
We think switching from jQuery Mobile to Twitter Bootstrap was the right move - the interface was much more responsive, and the code actually got simpler in places!