Menu avec liste déroulante, élément racine cliquable?
J'ai deux options pour une liste déroulante, mais je ne sais pas laquelle est la meilleure du point de vue de l'utilisabilité. Dans l'option (A), il existe un lien explicite "Nos services" qui mène à une page contenant des informations générales sur les services. Dans l'option (B), ce lien est dans l'élément racine.
Je n'aime pas l'option (B) car il ne me semble pas clair que le pointeur de main qui apparaît lorsque vous survolez "Services ▼" est parce qu'il y a un lien ou parce que c'est un menu déroulant.
Le client préfère (B) car il n'a pas à penser à un nom pour le lien, s'il choisit (A) il aura l'élément racine "Services ▼" et alors il serait redondant/laid de mettre un "Services " article…
Y a-t-il une façon préférée de faire cela? Je peux toujours faire un mélange de A + B ayant le lien vers la page Nos services dans l'élément racine et l'élément enfant. Dans les deux cas, je devrais rendre la liste déroulante "À propos de ▼" cohérente avec la solution pour "Services ▼".
Merci!
Il y a un problème de fond ici qui est: Le sous-menu devrait-il s'ouvrir en cliquant ou en survolant?
Si vous choisissez de l'afficher au clic, il est clair que vous ne pouvez utiliser que l'option A (ServiceA, ServiceB, ..., Tous les services). Cela fonctionne de manière cohérente pour les appareils tactiles et sans contact.
Si vous choisissez de l'afficher en survol, certains conflits surviennent:
L'utilisateur saura-t-il que le sous-menu s'ouvre en survol? Vous pourriez faire valoir que comme il s'ouvre rapidement, l'utilisateur comprend qu'il n'y a pas besoin de cliquer, mais il y a encore une chance qu'il clique sur l'élément racine .
L'utilisateur saura-t-il que le sous-menu se ferme lorsqu'il "quitte la souris"? Celui-ci est plus délicat car je peux deviner que certains utilisateurs peuvent cliquer dans l'élément racine pour fermer le sous-menu et arriver à être redirigé.
La seule situation dans laquelle cliquer sur l'élément racine doit rediriger est lorsqu'il n'y a pas de sous-men (donc l'élément racine est un lien).
Je m'en tiendrais au clic. Dans l'un des deux cas (clic ou survol) j'utiliserais OptionA (ServiceA, ServiceB, ..., Tous les services).
Je pense que le risque de cliquer accidentellement est trop élevé pour l'option B. Vous ne pouvez pas vous attendre à ce que les utilisateurs supposent que le menu fonctionne avec la souris - pas avant un premier clic! -, et je suis presque sûr que beaucoup de gens le feraient fais ça. Vous pourriez avoir l'étiquette faire une chose et la flèche une autre, mais vous avez alors très peu d'espace pour les clics autour de la flèche, et le menu devient plus inaccessible.
Une autre complication serait liée à la réactivité et aux appareils tactiles: votre menu change-t-il pour eux? Que se passe-t-il alors lorsque l'utilisateur appuie sur le niveau supérieur? N'auriez-vous pas besoin d'une page "Vue d'ensemble" de toute façon si vous passez à un hamburger ou similaire?
Je choisirais personnellement l'option A. Une étiquette est un petit prix à payer pour la clarté de son utilisation.
Conseil:
- Ouvrez et fermez en cliquant.
- Laissez le libellé du bouton principal clarifier qu'il s'agit d'une catégorie
- Laisser les éléments de menu clarifier les liens/le but
Contexte:
Je conseillerais de ne pas dépendre entièrement des états de vol stationnaire pour les tâches importantes et la navigation.
On suppose souvent que l'indisponibilité des états de vol stationnaire est exclusive au mobile, qui a souvent des solutions de navigation différentes telles que des onglets ou des tiroirs.
Cependant, gardez à l'esprit que dans la plupart des cas, les tablettes et les moniteurs de bureau tactiles seront présentés avec l'interface utilisateur du bureau. Ceux-ci sont souvent construits avec l'hypothèse que les états de vol stationnaire vont bien. Dans votre exemple, cela signifierait que l'utilisateur tactile ignorerait les 3 services car il ne verra jamais la liste déroulante s'ouvrir.
Le design réactif évolue d'abord vers l'état d'esprit mobile/tactile, et pour cause.
Consultez http://uxmovement.com/navigation/why-hover-menus-do-users-more-harm-than-good/ pour quelques informations supplémentaires.
Voici comment je le ferais:
Passez la souris sur le menu. Animez l'ouverture du menu. Lorsque cette animation est terminée, animez le texte du bouton de menu en modifiant pour lire quelque chose comme "Tout voir". À ce moment, commencez à écouter un événement de clic afin de rediriger l'utilisateur vers tous les produits.
Cela donne à un utilisateur de bureau qui a l'habitude de cliquer sur les menus pour lui ouvrir l'expérience qu'il attend (bien que son clic n'ouvre pas le menu, il ne fait aucun mal à ce stade) et en modifiant le texte du bouton de menu, il leur montre ce qu'il faut faire pour obtenir une page de tous les produits.
Cela donne à un utilisateur de bureau qui a l'habitude de survoler les menus exactement la même chose: l'expérience qu'il attend.
Enfin, il donne à l'utilisateur de l'écran tactile ce qu'il attend. Ils peuvent devoir cliquer pour attribuer le focus, mais ce premier clic, car le menu n'est pas encore affiché, ne les redirige nulle part.
En d'autres termes, à mon avis, cette solution ne casse aucune attente et ne nécessiterait pas une mise en œuvre/présentation spéciale selon que l'utilisateur possède ou non un appareil tactile.
J'apprécie vraiment votre question et j'aimerais donner quelques suggestions basées sur mon expérience.
Visualisation
Tout d'abord, votre menu a une icône de flèche vers le bas, il est donc clairement visible qu'il y a quelque chose en dessous. Différents utilisateurs agiront différemment avec cette visualisation, par exemple les utilisateurs plus techniques auront une idée qu'elle sera ouverte au survol de la souris, mais les novices auront l'impression qu'ils doivent cliquer là pour faire fonctionner quelque chose et, d'après mon observation, ils ne cliqueront que sur cette flèche.
Cohérence
Lorsque vous parlez de cohérence, vous n'avez pas de liste déroulante sur tout le menu, si vous allez avec le survol de la souris sur le menu déroulant, il y aura un décalage où pour certains utilisateurs du menu doivent cliquer et pour d'autres, ils doivent effectuer le survol de la souris.
Facteur de forme
Votre application/site Web sera-t-il utilisé sur des appareils tactiles? Si oui, le vol stationnaire ne fonctionnera pas là-bas.
Recommandation
Je vous recommanderais d'aller avec un clic pour ouvrir le menu et d'avoir des sous-menus pour la navigation qui fonctionneront pour tous les facteurs de forme et cela dérouteront moins les utilisateurs.
Si vous voulez regarder l'exemple, regardez comment Amazon a mis en œuvre cela.
C'est la même chose que ce que vous avez suggéré pour l'option B. En cliquant sur le titre, vous accédez à la page de la commande et une fenêtre contextuelle s'ouvre au survol de la souris.
Le problème: Le problème principal est avec son UX. Compte tenu de l'expérience utilisateur, c'est assez ennuyeux car le menu contextuel ne s'ouvrira qu'après que la page est entièrement chargée et j'ai vu de nombreux utilisateurs qui survolent la souris dessus, mais comme la fenêtre contextuelle ne s'affiche pas, ils cliquent dessus, ce qui redirige directement vers la page de la commande. Mais après tout, c'est Amazon. Le choix vous appartient.