Page History

Initial sketch:

Improved sketch:
Image Added

Bob would read through his news items using this interface. He would use 2 fingers to scroll up/down looking at the news items. He could tap on the "tag it" button to mark items with predefined or Bob-defined tags. He would use the "share it" button to share the items in the feeds he made available in Hubbub (like Facebook or Google+). The entries are "cut off" if they are too long, so Bob would have to tap them to expand or shrink them accordingly for reading. If he wants to defer reading certain items, he can use the "later" button.

Items would be marked as read automatically as he visits them.

This may be too low level, but I want to note this here:
This interface does not show what happens when you are done sharing or tagging an item. There will be visual cues saying what happens. For example, changing the "tag it" button to "edit/add tag" or something, or changing the "share it" button to say "share again".

This interface is very similar to ones people already use to view information (Twitter, Facebook, reddit, etc.). In addition, this format is very common for phones, so Bob will have little trouble learning how to go through his news items. However, with this interface there is no way to remove or "hide" items from his feed (a feature found in many applications).

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. Also, it is not clear if Bob has to click on entries to change focus between entries (will every button on the screen be accessible through one tap on the phone? Or will Bob have to tap on an entry first before he can use the buttons?).

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 (though this is not clear in the drawing).

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.

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:

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.