Versions Compared

Old Version 25

changes.mady.by.user Unknown User (leibatt@mit.edu)

Saved on

compared with

New Version 26

changes.mady.by.user Unknown User (leibatt@mit.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 is too narrow on its own for adequate filtering for our user population, and we . 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.

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.

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

...