Omnibar pour vous abonner et vous désinscrire

Question

J'ai une mise en page ux sur papier qui utilise une seule barre de recherche de type avant pour exécuter les tâches contextuellement similaires de s'abonner à un magazine et de se désinscrire de celui-ci. Est-ce quelque chose qui devrait être séparé dans le menu des paramètres utilisateur pour se désinscrire ou est-il acceptable que la barre de recherche remplisse les deux objectifs?

Essentiellement, la barre de recherche affiche un bouton "S'abonner" dans les résultats de recherche pour chaque magazine qui correspond à la requête ou un bouton "Se désabonner" qui est mis en évidence en rouge si l'utilisateur est déjà abonné au magazine.

Si l'utilisateur se désabonne, il y aura une boîte de dialogue de confirmation pour confirmer l'action. Après avoir cliqué dessus, ils recevront une notification claire de l'action sur la page et les articles du magazine seront ajoutés ou supprimés du Stream.

Answer 1

Dans votre question, vous mentionnez "résultats de recherche pour chaque magazine" , donc le contexte de votre application pourrait être important ici. Sinon, cela ressemble à une expérience déroutante. Peut-être pouvez-vous partager des wireframes ou plus de contexte pour clarifier?

ne barre de recherche est utilisée pour rechercher, pas pour effectuer des actions. Et c'est ainsi que l'utilisateur sans méfiance s'approche de la barre de recherche. Au mieux, il pourrait trouver des pages contenant les actions d'abonnement et de désabonnement. Si vous vous demandez comment un utilisateur abordera le problème de la recherche des fonctionnalités d'abonnement/désabonnement, il se peut qu'il recherche les pages pour le faire, et non pour effectuer cette action dans une barre de recherche.

Si vous souhaitez donner plus de contexte à la liste des résultats de la recherche, il est envisageable d'avoir l'abonnement/le désabonnement comme un itinéraire "rapide" pour accomplir cette tâche, mais c'est une approche différente que de rendre cette fonctionnalité accessible exclusivement via la barre de recherche.

Answer 2

Problèmes

La combinaison de deux fonctions différentes au sein d'un même contrôle n'est pas une bonne idée. Certains problèmes sont:

1. Interaction cachée : la zone de recherche est un contrôle clair pour une fonctionnalité de recherche, mais l'interaction d'abonnement est masquée dans la zone de recherche. Certains utilisateurs n'utilisent jamais le champ de recherche, ils ne peuvent donc même pas découvrir l'interaction d'abonnement.

2. Interactions concurrentes : l'activité de frappe conduit à deux interactions totalement différentes: celle de recherche et celle de (dés) abonnement. Votre décision a probablement été inspirée par Chrome omnibox avec ses riches fonctionnalités.
   
   Mais en fait Chrome omnibox conçu autour d'un objectif utilisateur: obtenir des informations. Pour obtenir les informations, omnibox va vers une URL ou effectue une recherche. Mais l'objectif est le même.

   Aussi les principes derrière omnibox pourrait être intéressant pour vous. Il a été conçu avec soin! Je cite juste quelques points:

   · Nous pensons que les utilisateurs ignorent la liste déroulante la plupart du temps ...

   · Dans un contrôle avec autant d'heuristiques que l'omnibox, les utilisateurs peuvent facilement se sentir hors de contrôle ...

3. Scénario erroné : probablement l'utilisateur prend la décision de s'abonner après avoir été reconnu avec le contenu. Le bon scénario pourrait donc être:

   4. Rechercher un sujet intéressé

   5. Lire le contenu

   6. Souscrire

   pendant que votre décision ressemble à: Search-Subscribe

.

Solutions possibles

1. Page séparée pour la gestion des abonnements.
2. Contrôle l'abonnement (dés) immédiat lors de la lecture du contenu du magazine.
3. Affichez les magazines récemment consultés pour un accès rapide. Il s'agit d'une alternative pour rechercher des magazines récemment consultés.
4. Nuage de tags pour un accès rapide aux sujets.