Page History

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 there is supposed to be a "search" or "go" button at the bottom of the sketch).

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 Removed
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.

Initial sketch:

Similar to searching in the  Finder application on a Mac, Bob can build a filter by creating "key-value" pairs for various attributes of the content (keyword, source, date, etc.). To add a pair, Bob hits the "Add Filter" button, with creates a list of attributes Bob can specify. In the sketch, the first item in the list asks what source the content came from, the second when it was posted. To remove pairs, Bob can hit the "minus" button next to the appropriate pair.

To execute the filter, Bob hits the "search" button. The results appear in the reading interface so Bob can see the results.

This filtering option is fairly complex. If Bob is unfamiliar with say Google Advanced Search options or Finder's search options, Bob will be very lost using this interface. However, if he is familiar with them, those affordances will make searching in Hubbub straightforward for Bob. The initial text however does give some indication of what kind of information Bob should input. For example, "on:service" shows Bob that he should input an information source. Putting in an actual source like Twitter would make this clearer for Bob.

Bob could repeatedly use the filter to see what happens when he provides different kinds of input, but this will take a long time.

This interface does not provide options to save filters, remember the last set of filter options, or update the filter. Thus Bob will have to input the parameters for his filters from scratch every time. This is tedious and aside from specifying maybe only 1-3 of the options, Bob may avoid using this interface entirely and filter manually instead.

We may want to add buttons for Bob to specify filters when convenient, such as making the time we receive an entry or the source of the entry buttons. Thus Bob can filter quickly on common filters, and save the complicated interface for more in-depth filtering.

Bob can easily remove a specific pair by using the "minus" button of that pair. However, if Bob simply wants to update the pair, he will have to remove the pair entirely and read it. And as described in efficiency, if Bob messes up his search, he will have to do it all over again from scratch with this interface.

To save an entry, 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.