Page History

Initial sketch:

Improved sketch:
Image Added

To use this filtering interface for our above scenario, Bob would have to mark all of the programming-related posts from Google+ manually and in advance with a tag (like "cool code" or something). If Hubbub could infer this pattern, the design would match our scenario. (sorry we forgot to draw a "search" or "go" button at the bottom, but there should be one there).

We realized while analyzing this sketch for Design # 1 that this design is too narrow on its own for adequate filtering for our user population. We will still need an advanced search option to give users more control if we decide to implement this.

This interface is very easy to use. There are only items and check boxes, so Bob can easily try out some of them to see what they do if he's not sure.

However, it is not clear in Design # 1 how to get to the filter page.

This is extremely inefficient, because it only filters on things you've already tagged, aside from what sources to include. Thus Bob has to tag everything he wants to see before he can properly filter for them.

If Bob accidentally filters on the wrong thing, he will have to start this process all over again.

A cool way to remedy this would be to save the last filter configurations and offer a "edit filter" button somewhere so Bob can revisit it. This would also help with learnability.

Initial sketch:
Image Added
Improved sketch:

This is an example of a menu that would appear after hitting a save button on the page. Here, Bob's previously created/used "save" tags are listed in the first drop-down menu. Since bob has categorized code-related items before, he will already have a "code-related" tag of some kind in the list. This would just be a special tag that makes sure items don't get deleted. For example, if we add options for the user to delete items that have been around for a long time (month or something), items with the save tags would be ignored.

If Bob wants to see these items again, he just has to specify he wants to see items with the "code-related" save tag under filtering, when he goes back to read them. Then he can read them again using the reading interface.

There will be a "new tag" entry in the first drop-down menu, so Bob can specify a new save tag if the current list of tags don't suit his current needs.

With this interface, he can also specify how long he wants items to be saved with the second drop-down menu.

It's pretty clear what is being saved. But Bob may not realize how to create a new save tag with this design. He would have to explore the drop-down menus to see what they do.

This is pretty efficient for saving a single item. Bob could save an item in 1 tap on his phone using the default menu values. As the list of save tags grows, we can allow scrolling/arranging options for the save tags to speed up the search for the correct tag.

However, if you want to save multiple items, this is not an efficient way to save. We will have to look into options for bulk saving, if this turns out to be a necessary feature for our user population.

The item Bob is trying to save is displayed to make sure he's saving the right thing.

Bob's save choices will remain visible after selecting items from the menus, so he can verify them before he hits the save button.

Image Added

with tag list open: Initial sketch:
Image Removed
Improved sketches:
Image Removed

With this interface, Bob This interface displays a single item at a time, filling the screen. Bob is brought immediately to the first item in his feed. He goes from one item to another using the next and previous buttons.

He saves and shares items using the "save" and "share" buttons. He can mark things using the "tag" button, which would open a new (maybe popup) menu. An example of the tag menu is given in a second drawing. We would either add a separate button for read later items, or add "read later" a tag in the tag menu.

Bob may confuse the intent of the read later tag with other tags if we include it in the tag menu. Thus we will probably have to add another button. The issue with this is that there are already 8 buttons at the bottom of the screen. This may make learning how to use the interface more difficult for new users, even if the buttons seem straight-forward in use. Next and Previous are familiar affordances from websites that Bob can use to learn how to navigate through his items.

But here it is much harder to see the full effects filtering will have on the entries to read, since we only look at entries one at a time. This will hinder Bob's ability to learn how filtering works (even though this is the reading interface!)

When 
going through each item one at a time will be very slow for Bob. If he is uninterested in the first 10 items, he will have to click the "Next" button 10 times before he sees something interesting, which is very inefficient. We will want to add a birds-eye view interface so Bob can quickly go through items as well.

If Bob realizes he accidentally skipped an entry he was looking for, he will have to hit the "Prev" several times to get back to the correct entry. However updating tags will be easy. There is no "undo" button for any of the interfaces.