Design
Reading
(Some names blacked out for privacy)
The goal of this interface is to facilitate the reading of feed items. We picked a vertical feed format over one item per page or horizontal swiping for external consistency with other news feeds. We also chose this format because it allows users to skim many items quickly. Items are automatically marked read as the user scrolls down the feed page. The user can save items for later reading by hitting the item's save button. Hubbub pulls live data from four sources: Gmail, Twitter, Facebook, and Imgur.
This design remained relatively constant through prototyping, with two exceptions: removing the "Share" button, and color-coding services. The paper and computer prototypes included a "Share" button on each item for sharing on their respective social media websites (e.g. retweeting for Twitter items). When we implemented the computer prototype, we realized that controls were taking up too much space on the page. Also, the behavior of "Share" was ambiguous to users. Therefore, we removed it from the final version of Hubbub. In addition, we originally planned for the interface to be mostly grayscale for simplicity. However, we decided to use color to make it easier to tell the interfaces apart. Due to screen size, the labels of the computer prototype became relatively smaller than the text, and needed additional contrast. We chose colors that were externally consistent with the information sources. For example, Twitter items are color-coded light blue, and Gmail items are red. 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.
Tagging/Saving
The goal of this essential task is to give users a way to manage their items through categorization and saving. Users save items for later reading by hitting the save button, and optionally tag items to make them easier to search for.
Hubbub provides an interface for users to select tags from a list, and also create new tags to add to the list. Tags are persisted in the back-end using a database. We considered an alternative approach that involved dragging tags directly onto items in the feed, but we realized that this approach did not meet our screen space constraints. Tags are selected via checkboxes so users can apply multiple tags to the same item at once.
When implementing the computer prototype, we decided to add a wide rectangular area (with a gray background) around each checkbox, and register clicks inside the area as checking the box. This combatted the "fat-finger" problem, which was not obvious during our paper prototyping user testing.
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 to "Back" for two reasons: first, having two buttons next to each other was harmful for safety - users may accidentally click one button when they meant to click the other; and second, we wanted the tagging interface to remain consistent with the rest of the application. The filter interface also has a "Back" button at the top-left corner serving a similar purpose.
In GR4, the "Save" button's functionality was not implemented. When we switched to providing live data in the feed, we needed a way to prevent old items from diluting the content on the feed page. After getting feedback from Sacha, we updated functionality of the "Save" button to keep items in the feed so the user could read them later. Saving and tagging together comprise one of our essential tasks and provide better usability than the prototypes.
Filtering
(Text has been shrunk so the image is not too tall)
Users can filter feed items to find what is currently of the most interest to them. Hubbub allows users to filter by service, content text, tags, or existence of hyperlinks. This interface was difficult to design for good learnability. When testing our paper and computer prototypes, the filter interface was the hardest for users to use. 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.
We had 3 students 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:
Hubbub is a mobile application for managing incoming information from Twitter, Facebook, e-mail, and so on, and reading what's important to you as efficiently as possible.
We had our users perform the following four tasks, updated from GR3:
- Find something interesting to read.
- Mark something to read later
- Tag an Imgur image as "silly pic"
- Create a filter for items from Gmail and Imgur, save it and run it.
Our observations:
- Users weren't sure how to show that they had found something interesting to read. All users asked if they were supposed to click on links, and most users tried to click on the items to follow links or open the item.
- This is a user test issue that didn't appear in our paper prototyping.
- There was something about testing our app on an actual phone that made users think they had to try and click on the items they wanted to read.
- As expected, most users marked items to read later by hitting the save button. However, the behavior of the save button was not clear for all users.
- One user tried to mark an item to read later by tagging.
- He suggested providing an optional popup explaining what happens when you hit the save button.
- All users tried hitting the load more items button, but it was not obvious whether new content was actually loaded. It was also not obvious that the button existed on the page
- Some users scrolled past the load more items button looking for more content.
- A possible solution is to reduce the amount of space between the button and the end of the feed page.
- Specifying filters appeared intuitive for users. However, saving and then executing filters was not obvious.
- Two possible solutions are to not clear the user's filter selections on a save, or to auto-select the newly saved filter after clearing the form.
- Users often clicked items several times, and backtracked on operations for tasks due to slow response times in our app.
- Users seem to be accustomed to quicker response times, which affects the learnability of our system.
- We will need to look into optimizing our system and providing quicker visual response cues to the user
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. For example, we originally had a tabbed interface to switch between the news feed and the filter form, but users found it counterintuitive so we dropped it.
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. In particular, we realized that the filtering interface was confusing, and devoted more attention to its learnability in response to feedback. Our evaluators did not disagree on any points, so we were able to make changes that would satisfy them all.
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!