Omnibar to subscribe & unsubscribe

Question

I have a ux layout on paper which utilizes a single type-ahead search bar for executing the contextually similar tasks of subscribing to a magazine and unsubscribing from it. Is this something that should be separated into the user settings menu for unsubscribing or is it acceptable to have the search bar fulfill both purposes?

Essentially, the search bar shows a "Subscribe" button within the search results for each magazine that matches the query or an "Unsubscribe" button that is highlighted in red if the user is already subscribed to the magazine.

If the user unsubscribes then there will be a confirmation dialog to confirm the action. After they click on it, they will get a clear notification of the action on the page and the magazine's articles will be added or removed from the Stream.

Answer 1

In your question you mention "search results for each magazine", so maybe your application's context would be important here. Otherwise, it sounds like a confusing experience. Maybe you can share wireframes or more context to clarify?

A search bar is used for searching, not for performing actions. And that is how unsuspecting user will approach the search bar. At best, it could find pages that have the subscribe and unsubscribe actions. If you ask yourself how a user will approach the problem of trying to find the subscribe/unsubscribe features, they might look for the pages to do so, not to perform that action in a search bar.

If you want to give more context to the search results listing, it is thinkable to have the subscribe/unsubscribe as a "quick" route of accomplishing that task, but that is a different approach than making that feature accessible exclusively via the search bar.

Answer 2

Problems

Combining two different functions within one control isn't a good idea. Some problems are:

1. Hidden interaction: search box is a clear control for a search functionality, but subscribe interaction is hidden within the search box. Some users never use search box, so they can't even discover subscribe interaction.

2. Concurent interactions: typing activity leads to two totally different interactions: the search one and the (un)subscribe one. Probably your decision was inspired by Chrome omnibox with its rich functionality.
   
   But actually Chrome omnibox designed around one user goal: getting information. To get the information omnibox either goes to an URL or performs search. But the goal is the same.

   Also the principles behind omnibox could be interesting for you. It was designed wery carefully! I just cite some points:

   · We believe that users ignore the dropdown most of the time...

   · In a control with as many heuristics as the omnibox, users can easily feel out-of-control...

3. Wrong scenario: probably user makes decision on subscribing after he got acknowledged with content. So the right scenario could be:

   4. Search for an interested topic

   5. Read the content

   6. Subscribe

   while you decision looks like: Search-Subscribe

.

Possible solutions

1. Separate page for subscription management.
2. Controls for immediate (un)subscription while reading magazine content.
3. Display recently viewed magazines for quick access. This is an alternative for searching for recently viewed magazines.
4. Tag cloud for quick access to topics.