Page History

Initial sketch:
Image Removed
Improved sketch:

Bob would read through his news items using this interface. He would scroll up/down to look at the news items.

The political article would be long enough to be cut off, but he could read all of it by expanding the article with the disclosure triangle. He would hit 'save later' when he decided to read it later, which would cause it to show up in this stream again some time in the future.

He would share the imgur image by pressing its 'share' button, and press 'tag' to put it in the 'cool' category. The tag button would be come 'add/edit tags' after there are tags assigned.

Items would be marked as read automatically as he scrolls past them. 

This interface is very similar to ones people already use to view information (Twitter, Facebook, reddit, etc.). In addition, the vertical list format is very common on phones, so Bob will have little trouble learning how to go through his news items. 

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.

Initial sketch:

Improved sketch:
Image Removed

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.

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.