Page History

Bob would read through his news items by scrolling up and down. The first few lines of each item are visible.

The political article would be long enough to be cut off, but he could read all of it inline by expanding the article with the disclosure triangle.

Since articles are automatically marked as read as he scrolls through them, When Bob is interrupted, he would hit the 'later' to indicate that the item should show up again the next time.

Bob would begin filtering by pressing a filter button at the bottom of the screen (not pictured).

This interface is very similar to the interfaces for reading Twitter updates and Facebook's stream. The list format (common on phones) affords scrolling through the items, and the buttons use text to be fairly self-describing. Bob should have little difficulty figuring this UI out.

It is very efficient for reading items. Bob can quickly scroll through and skim the first line of each entry as he looks for things to read. However, If he wants to mark multiple items at once (such as read or read later), it will not be easy or quick to do here because he has to do them all individually. Having the buttons always visible may mean more scrolling is necessary, which could slow Bob down.

Bob can easily expand/shrink entries. With this interface, items are currently not deletable, which avoids Bob accidentally removing something he wants to keep. If Bob doesn't like a tag he put on an entry, he can edit or remove it using the "tag" button again.

To save an entry (in this case the programming article), Bob has to navigate to that entry and hit the "save" button. A (maybe popup) menu appears with checkboxes specifying what save tags to use on the entry. Bob finalizes by hitting the "ok" button at the bottom of the menu.

Because this isn't traditional save, the word save may confuse Bob. We are using tags to specify an entry is "saved", but we don't move it to a separate location like a folder.

However, we observed through our interviews from GR1 that it won't matter to most users whether their content is physically moved to a folder or just specified through a tag. The save tags are specified and filtered the same way as other tags in Hubbub, which may be a good and bad thing. On one hand, Bob doesn't have to learn drastically different steps to save or tag an entry. However, Bob's mental model may group save tags and regular tags together as being the same thing (where they are not, because entries marked with save tags will not be deleted unless explicitly deleted by Bob. This is generally how save mechanisms behave for other applications as well).

Because the interface is very simple, Bob will be able to save individual entries very quickly. Specifying new save tags will also be fast. After hitting the "new tag" button, a new check box and text box will appear where the "new tag" button was. Bob will simply just describe the name of the tag in the text box and tap the check box next to it (or something similar to this).

However, this interface only supports saving for one entry at a time, which may slow Bob down if he knows he wants to save several things within the same time period. We will have to see if this tasks becomes necessary to our user population.

Ideally if Bob saves an item, Hubbub will remember this and turn the "save" button into an "update/unsave" button so Bob can remove the save tag or change/add save tags. The menu would be the same, but unchecking boxes would unsave the entry. The issue with this is it is unclear what should happen if Bob is initially trying to save but doesn't check one of the boxes. What if he inputs text for a new tag but doesn't check the correct box? There is potential here for Bob to produce input Hubbub would handle in a non-intuitive way. We will have to choose whether to err on the side of save or not save, and default to particular tags accordingly.