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 filter out his annoying Google+ updates, Bob can use this interface to select all of his sources except Google+. In addition, he checks the "important" tag checkbox to sort by importance.

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. Bob will then pick the correct tag from the dropdown menu for his article and specify how long to save the article for in the second drop-down menu. When he is done he hits the "save it" button.

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.

with tag list open:

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. In the case of our scenario, suppose Bob hits a "later" button to have his political article show up later.

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.

After hitting the filter button from the reading menu, Bob comes to this interface. To filter out his Google+ updates, he simply adds a "not on: Google+" to filter them out. 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 (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.

This design attempts to make filter application more prominent by merging
it with the interface for reading items. Filter creation is still separate.

The sidebar on the page (first image) lists the information sources Bob has
registered, and also the filter tags he has made.  Bob selects the particular
sources from which he is interested in consuming information right now,
and they are displayed in the center (second image) as a scrollable list.
Contrast this with Design 1, in which all sources were interleaved and the
sidebar was not present. There are controls for tagging and saving each item
which he uses to do the second and third tasks (not depicted in this image,
but would be similar to Design 1's controls).

In this drawing, custom-made filters are separate from filters available by
default to choose which information sources users want to read from. It
is worth considering the option of unifying these two for consistency, but
this might make it harder to easily divide posts by source.

Reading the material in the center is similar to
existing information feeds, so users can learn by
recognition.

On his first use of Hubbub, Bob may be confused
as to how to operate the sidebar. Giving him the
power to see multiple items in a list, but with filtering
controlled at all times, increases the complexity of
the interface. Learnability can be improved by taking
special care to provide feedback when interacting
with the left sidebar. At a low level, filters should
change in appearance if selected, and at a high level,
the items displayed in the center should immediately
change.

Power users who wish to filter items regularly will
find this interface to be useful to them, as it allows them
to quickly apply filters without loading a different screen.
If Bob uses this application for an extended period of
time (which is possible, the significant amount of time
he spends reading data on the Internet), he will appreciate
being able to easily reapply filters, so he doesn't have to
read about Bill's baby.

 

If Bob skips an entry, he can just
scroll up. It helps that reading is
innately not a destructive action.

Filter application can be undone by
clicking on the filter again. It will
change in visual appearance to
show which state it is in, to avoid
mode errors.

When Bob decides to create or update a filter, the screen shown
in the sketch pops up. Bob can type keywords in the search
bar, and also select advanced settings from the form under
the search bar. Each advanced setting translates to a command
language in the search bar, and selecting them from the form
will enter the corresponding language text in the search bar
for self-disclosure.

The item feed remains available on the screen next to this
form, updating in real time with edits so Bob can preview the
effects of his selection.

Once the filter is created, it becomes available in the sidebar
and can be used as described in the "Read Items" entry.

A design decision to consider is whether the advanced options
should be visible by default, or if they should be hidden and
revealed by a "Advanced Options" link. This design chooses
the former option, so the form is more visible to new users.
Expert users who have learned the command language will
want the form to be hidden though. Testing and prototyping
will shed more light on this question.

An extreme option is to omit the advanced form altogether,
but this would require an effective implementation of search that
can read the user's mind as to what context they want.

This interface is learnable, but only if the instant
updates and self-disclosure features are implemented.

Bob can learn from recognition, by using the search
bar the same way he would use Google Instant
Search. Updating the results in real time is important,
as it provides powerful high-level feedback to Bob's
inputs, so he can tell if he's going the right way.

Self-disclosure of the command language is also
useful and Bob can learn it as he goes along if he
wants to.

Searching by typing is efficient since it allows
Bob to input his ideas without reaching for the
mouse. If he learns the command language, he
can become quite fast at creating filters on the
spot.

It's debatable as to whether efficiency in creating
filters is of high importance or just nice to have.
Many users may only set up a set of filters the
first time they use the application, then reuse
those filters over and over, never making new ones.
On the other hand, changes in information sources
may prompt the need to update filters.

Bob can undo the additions he has made to
the filter by deleting the text typed in the search
bar or unchecking options in the form.

If he accidentally saves the wrong filter, he
still has the ability to edit it and fix the errors.

This design for the saving items task uses a nested folder
layout, similar to the filesystem on desktop computers.

When Bob wants to save an item for later, he drags it and
drops it into a folder. A set of stub folders is created by
default, and Bob can create new folders or navigate the
heirarchy the same way he uses file browsers on his
computer.

Therre's a debate over whether the folder or tag model is
better. Gmail is often advocated as evidence that the tag
model is better for organization. It is true that with tags,
you can categorize the same item under multiple areas.

Bob may not want the additional complexity of multiple tags
for one item though, if he only archives things for a short
period of time. It's interesting to note that Gmail later added
a "Priority Inbox" feature, which is closer to the folder model
(an email in my "Important" section doesn't appear in the
"Everything Else" section).

Bob can learn by recognition, calling on his
experience with file management on his computer.

The interface uses the direct manipulation model,
which is generally considered to produce fairly
intuitive user interfaces, by preserving the idea
of putting objects into folders like you do in the
real world.

Folders may be less efficient than tags,
as a drawback to their similarity. The same
item can't be categorized into multiple folders.

Also, finding an item may require drilling down
multiple layers of folders, which is slow. The
use of a search bar can ameliorate this, but
it does require that Bob remembers roughly
where his item is saved.

Bob can't make unrecoverable errors with this
interface. If he drops an item into the wrong folder,
he can still open that folder and retrive the item,
so that he can move it again.