Pourquoi existe-t-il une convention sur le Web pour les menus déroulants au survol plutôt qu'au clic?
C'est quelque chose que je me suis toujours demandé. Sur tous les principaux systèmes d'exploitation, les menus d'application (Fichier/Modifier/Afficher, etc.) n'apparaissent que sur clic. Cependant, presque tous les sites Web qui utilisent un menu déroulant l'instancient au survol, pas au clic.
Comment et pourquoi cette convention a-t-elle vu le jour?
Je n'ai aucune idée de la bonne réponse à cette question, mais permettez-moi de spéculer: je pense que c'est parce que le Web a des hyperliens. Cliquer sur quelque chose sur un site Web est associé à la visite d'une page différente, et en tant que tel, si vous créez un menu déroulant qui s'active au clic, l'attente de ce qu'il peut faire lorsqu'il est activé est incertaine: cela me dirigera-t-il vers un nouvelle page ou ouvrira-t-elle un menu? Donc, si vous continuez cette ligne de logique, la création de menus survolés a beaucoup de sens, car avant qu'un utilisateur clique, vous pouvez lui présenter des commentaires indiquant qu'il a activé un menu.
Il peut également prendre en compte le célèbre Internet problème de déficit d'attention d'où viennent tous les chiffres montrant les gens qui traînent sur votre page pendant quelques secondes seulement. Je sais que le concept "les utilisateurs ne cliquent pas" est un mythe, mais beaucoup de gens ne le font pas, et cela peut conduire à l'implémentation de nombreux menus en utilisant le survol, car les concepteurs s'attendent à ce que les utilisateurs ne cliquent pas parce qu'ils pensent cela peut les mener à une autre page.
De plus, j'imagine que c'est un cycle répétitif: les concepteurs voient les menus survolés et conçoivent les menus survolés, que plus de concepteurs voient et plus de concepteurs conçoivent. Tout le monde ne pense pas à chaque contrôle d'interface utilisateur individuel qu'ils utilisent en termes de raison pour laquelle ils en ont besoin et quel est son objectif; de nombreux concepteurs avec qui j'ai travaillé choisissent des contrôles "parce que c'est ce que vous utilisez" (voir: surutilisation incessante de la zone de liste déroulante de saisie semi-automatique; une diatribe pour une autre fois).
Comparez ce qui précède avec les applications de race de bureau où il n'y a (généralement) aucun état de vol stationnaire, certainement pas en tant que modèle d'interface utilisateur pour les menus, et je pense que nous avons bouclé la boucle.
Juste une supposition, mais hover est probablement utilisé par opposition à onclick car css a une pseudo-classe: hover.
Ou peut-être que la liste déroulante a été utilisée parce que l'utilisateur ne s'est pas rendu compte qu'il devait cliquer pour ouvrir le menu. La moitié du temps, un menu déroulant ressemble à n'importe quel autre menu jusqu'à ce que vous survoliez. Et l'action attendue lorsque vous cliquez sur un bouton de navigation est que le site vous amène à cette page. Alors peut-être que les utilisateurs ne trouvaient tout simplement pas les options de menu supplémentaires.
Rahul fait un point intéressant concernant l'absence d'une action cohérente sur un "clic"; Cependant, je pense que cela va au-delà de cela dans un sens plus général de découverte sur la surface de la page.
Les gens peuvent ne pas cliquer en raison du désir de ne pas quitter une page particulière, mais beaucoup de gens "survolent" la page à la recherche d'états actifs. Comme les menus réagissent au survol et non au clic, l'utilisateur peut plus facilement découvrir la structure du système de menus sans recourir aux clics.
Bien entendu, cela entraîne certains problèmes d'accessibilité. Lorsque je clique sur un menu sur une application de bureau, le comportement par défaut consiste à laisser le menu ouvert jusqu'à ce que je fasse un choix, ou à cliquer hors du menu. Cela aide les utilisateurs qui peuvent avoir des difficultés à manœuvrer la souris sur la commande correcte sans sortir du menu (ce qui la réduit dans le paradigme du survol).
Les applications Web sont extrêmement incohérentes en termes d'interface utilisateur, mais l'utilisateur doit les comprendre rapidement (sinon sa durée d'attention se tarit et il ira ailleurs).
Le menu en vol stationnaire a une bien meilleure découverte - lorsque je vois un bouton sur un site récemment visité, je ne sais pas s'il ouvrira un menu avec plus d'options (que je veux), ou s'il m'emportera, détruisant l'état actuel d'une page (y compris un commentaire à moitié écrit) - ce qui n'est évidemment pas ce que je veux. Cela ne prend que quelques pour cent des sites avec une dernière pratique pour me faire craindre de cliquer sur quelque chose que je ne sais pas - et un utilisateur intimidé n'est pas un utilisateur heureux.
Par la souris, nous explorons des choses qui sont à l'écran, en survolant signifie `` je vous regarde actuellement '', il est donc assez naturel que l'élément d'interface utilisateur montre ce qu'il fait (un menu) ou un indice (info-bulle: cela supprimera le message que vous écrivez).
D'un autre côté, ne pas réagir en vol stationnaire est impoli - l'utilisateur demande ce que fait l'élément, et vous ne répondez pas. Les gens aiment sentir qu'ils ont le contrôle et savent ce qui se passe; chaque commentaire est important, et en ne réagissant pas en vol stationnaire, vous perdez une chance de communiquer.
Dans notre logiciel de bureau récent (complément Outlook TaskConnect ), nous sommes allés jusqu'à mettre l'info-bulle d'aide à chaque élément actif, et définir le délai d'expiration de l'info-bulle à zéro - le faisant ainsi apparaître instantanément. Vous pouvez voir une courte vidéo de son apparence en action . Qu'est ce que tu penses de ça?
PS: Dans tous les cas, le menu devrait également toujours apparaître au clic, sinon les utilisateurs d'écran tactile ou les personnes au clavier (y compris les utilisateurs handicapés) ne pourraient pas l'utiliser.
En règle générale, l'élément supérieur d'un menu vous amène à la page avec ce titre. Vous n'allez nulle part dans une application. Le survol des éléments de menu a été développé comme un raccourci pour voir les sous-sections dans une section particulière du site plutôt que de devoir aller à la page pour voir les sous-sections. Avec une application, vous ne vous rendez pas dans la section "fichier" par exemple. L'abandon des conventions Web pour l'écran tactile est une erreur pour moi. Les sites Web ne sont pas destinés aux doigts.
La "découvrabilité" est certainement un facteur ici.
Ma distinction est l'état d'esprit de l'utilisateur, surtout lorsque l'on compare une application à un site Web.
Lorsque vous cliquez, vous voulez faire quelque chose, effectuer une certaine action - cela doit être intentionnel.
Les utilisateurs exploitent généralement des applications dans cet état d'esprit.
Cependant, (certains) sites Web sont davantage axés sur la consommation de contenu. Vous parcourez, lisez et exécuterez peut-être une action. En fait, l'un des plus grands défis pour amener les visiteurs du site à FAIRE activement quelque chose, pas seulement à visiter. Par conséquent, il est très logique d'essayer de vous pousser à faire quelque chose en vous montrant les options plus facilement.
Il y a une autre différence entre les deux états d'esprit:
Habituellement, vous utiliserez une application plusieurs fois, devenant ainsi un peu plus familier et compétent avec elle. Sur le Web, il est probable qu'un grand nombre de vos utilisateurs soient nouveaux, par conséquent ils ne savent peut-être pas où chercher des choses et peuvent également avoir "peur" de s'engager à (cliquer) sur quelque chose qu'ils ne connaissent pas.