...
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.
In this section, we provide a high-level description of Hubbub's implementation. 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.
...
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.
In this section, we describe how we performed our final user test analysis for Hubbub. 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:
...
- 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
In this section, we reflect on the design decisions we made throughout the semester, whether they were "good" or "bad", and what we could've done better.
GR1 - User And Task Analysis
...