...
- The first task description, "Read something interesting", initially confused some users who didn't realize they were being asked to try to scroll down or expand items. Changing the description to "Find something interesting to read" resolved this.
- Because it is a mobile app we tried to afford scrolling by displaying a partial line of content at the bottom edge, but some users did not realize that the page was meant to be scrollable.
- Users were able to notice the "Expand" button and click on it to expand items to see the full version. In some of the original tests, we didn't display a "Shrink" button on expanded items; users during these tests users tried to touch outside the original menu image to get back, similar to how you close a photo on Facebook. Some users did this even after we started showing the "Shrink" button - we could consider making clicking outside of an expanded item shrink it, though this could be another issue that comes up with a paper prototype.
- A couple of users hit the "Share" button. Ideally, this wouldn't require that the user do anything more, and the backend would make the post in the background using an API. We might need to ask for additional input in some cases though, like email forwarding, which took them to the canonical URL of the item (its imgur page, the e-mail in the Gmail interface, the post on Facebook, etc). Ideally, we could choose a reasonable default mode of sharing so that the user wouldn't have to take further action. There is always the possibility that the user wants to share between services or out-of-band, though.
- Some users thought the interface was busy and suggested hiding buttons. When the interface is on a real screen we can better determine whether decreasing learnability by hiding the buttons the blow to learnability makes sense.
- For the most part, users were familiar with interfaces that present a list of items to read, and did not have encounter significant roadblocks navigating.
Saving
We experimented with two mechanisms to save content for later: the first is to hit a "Read Later" button that presumably shows you the content later; the second is a set of tags that users can apply to items, and later search for, similar to Gmail. One user mentioned that she would save emails often since she doesn't want to reply to them on the phone, and suggested that hitting "Read Later" on an email mark it as unread (this would be desirable by users who use both Hubbub and their email clients to read emails). When the user hit "Read Later", the feedback we used was to change the text on the button to "Saved". Some users thought that this term didn't fit their mental model (emails are already saved), and suggested making the item go off the screen. We could make it do this automatically, or have the user do a sideways swipe similar to dismissing notifications on Android.
...