...
Sketch | Storyboard | Learnability | Efficiency | Safety |
|---|---|---|---|---|
| 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 He could tap on the "startag it" buttons button to quickly mark items as significant, and with predefined or Bob-defined tags. He would use the "share it" buttons button to share the items in the feeds he made available in Hubbub (like Facebook or Google+). The items would be entries are "cut off" if they are too long, so Bob would have to tap them to expand them or shrink them accordingly for reading. If he wants to defer reading certain items, he can use the "later" button. | 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 a large volume of items multiple items at once (such as read or read later), it will not be easy or quick to do here. | 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). |
Filter Items
Sketch | Storyboard | Learnability | Efficiency | Safety |
|---|---|---|---|---|
| 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 too narrow on its own for adequate filtering for our user population, and 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. | This is extremely inefficient, because it only filters on things you've already tagged, aside from what sources to include. |
Save Items
Sketch | Storyboard | Learnability | Efficiency | Safety |
|---|---|---|---|---|
| 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. | 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 save tags list grows, we can allow scrolling/arranging options for the save tags to speed up the search for the correct tag. | The item Bob is trying to save is displayed to make sure he's saving the right thing. |
...