Une liste déroulante doit-elle être fermée lorsque la souris quitte?
Une liste déroulante doit-elle être fermée automatiquement lorsque vous quittez l'objet actuel et accédez à un autre, ou doit-elle rester ouverte jusqu'à l'ouverture de la prochaine liste déroulante?
- Liste déroulante fermée lorsque la souris quitte
- La liste déroulante reste ouverte
Par souci de cohérence, le comportement doit être basé sur l'action d'appel; cliquez ou survolez.
Si vous ouvrez la liste déroulante au clic, laissez l'utilisateur basculer et la fermer, ou fermez la liste déroulante précédente lorsque l'utilisateur clique sur une autre miniature.
Si vous ouvrez le menu déroulant au survol de la souris, fermez-le au survol de la souris.
La réponse à cette question fait partie d'une règle UX plus générale: le déplacement de la souris (sans bouton enfoncé) n'est pas entré et les applications ne doivent pas y répondre en prenant des mesures non triviales. Les actions triviales incluent des éléments tels que l'ajout/la suppression de soulignement, le changement de couleur ou l'exécution d'une petite animation spatialement isolée pour indiquer la cliquabilité. Afficher ou masquer des informations/éléments d'interface utilisateur n'est pas anodin et très ennuyeux pour les utilisateurs qui déplacent le curseur de la souris (qui peut être surdimensionné pour des raisons d'accessibilité!) En haut du texte qu'ils essaient de lire afin qu'ils puissent le lire.
Ajouté (puisque les commentaires semblent générer un débat sur ce qui est "trivial"): Mon intention est qu'une action/réaction au mouvement de la souris soit triviale si:
- L'omettre complètement ne supprimerait pas les informations ni ne limiterait la capacité d'interagir avec l'interface, et
- La présence de l'action ne perturbe ni n'interfère avec la capacité de lire ou d'interagir avec l'interface.
Les menus déroulants/menus survolés (ainsi que les info-bulles) échouent aux deux critères s'ils ne peuvent pas également être activés par des clics, et échouent au deuxième de toute façon, sauf si vous vous arrêtez pour qu'ils apparaissent dans une zone spéciale où ils n'obscurcissent pas les autres contenus.
Je pense honnêtement que les menus en vol stationnaire sont entièrement mauvais UX.
Je soupçonne que la seule raison pour laquelle ils existent en premier lieu est qu'ils sont plus faciles à implémenter en CSS pur, afin que le développeur puisse s'en tirer avec quelque chose que l'utilisateur ne veut pas nécessairement.
Voici quelques points à considérer:
- La plupart des systèmes d'exploitation attendent un clic de l'utilisateur avant d'activer un menu. Le menu survolé va à l'encontre d'un modèle bien établi.
- Le système d'exploitation dispose de menus dans une partie distincte de la fenêtre, où leur comportement est anticipé. Les menus survolés font partie du contenu et rivalisent avec le reste du contenu.
- Les utilisateurs utilisent régulièrement une souris sans aucune intention, ou simplement pour suivre leurs yeux. Le menu survolé perturbe ce comportement, masquant souvent le contenu que l'utilisateur regardait.
- Les appareils tactiles, à ce stade, n'incluent pas de véritable action de survol. Les menus survolés représentent un comportement différent entre le bureau et les appareils tactiles. En fait, ils se comportent souvent comme des menus de clic dans ce contexte.
- Les utilisateurs non voyants ne verront pas du tout le menu de survol, ce qui est une petite pitié.
Bien qu'une application Web ne soit pas exactement la même chose qu'une application de bureau, il existe des conventions et des expériences antérieures, ainsi que des attentes, à adapter.
Les menus activés par clic (ou toucher) sont, de nos jours, assez faciles à implémenter avec quelques lignes de CSS et de JavaScript (non jQuery).
La réponse courte est qu'un menu déroulant doit être activé délibérément et désactivé délibérément. Ce n'est pas avec le déplacement de la souris, mais avec un clic ou une touche.
Je suis d'accord avec la réponse de DPS, mais j'opterais pour un comportement explicite - donc en cliquant pour ouvrir et en cliquant (ou en appuyant sur Echap) pour fermer.
Pourquoi pas "en vol stationnaire"?
Si l'utilisateur ouvre la liste déroulante et fait un mouvement de souris plus généreux (éloignez le curseur pour lire toutes les options) - le menu disparaît augmentant la gêne.
Il y a autre chose que je voudrais mentionner - lorsque la liste déroulante apparaît, elle est placée en bas à gauche du curseur de la souris. À mon avis, il devrait être placé en bas à droite. L'utilisateur suit le pointeur de la souris et dans la plupart des cultures, nous avons tendance à traiter les informations de gauche à droite. Si l'utilisateur se concentre sur le pointeur de la souris, il s'attend à ce que le menu apparaisse à droite, afin que son flux de traitement des données ne soit pas perturbé.
Compte tenu de ce qui précède - si vous optez pour l'option "au survol", il est très facile d'éloigner le curseur de la liste déroulante et de le fermer.
... Ou vous pouvez envisager de changer complètement le design. Personnellement, je pense que ce n'est pas une bonne idée de cacher la fonctionnalité sous trois points.
Afficher les actions au survol
Vous pouvez supprimer complètement le clic/survol en affichant les actions directement en survol. Je dirais que c'est mieux depuis que vous enregistrez le clic (je ne montre pas déplacer/renommer pour plus de brièveté).
Afficher les actions dans l'écran principal
Si la conception le permet, les actions peuvent toujours être visibles sur l'écran principal. Si vous pensez que les icônes sont vagues, vous pouvez ajouter une info-bulle ou modifier la disposition pour afficher les icônes avec des étiquettes.
Vous pourriez envisager d'ajouter un moyen pour l'utilisateur de fermer la liste déroulante. De cette façon, il n'y a pas de confusion sur la façon de le fermer et pas de gêne à le fermer accidentellement en déplaçant la souris hors de la zone.
Il m'arrive de trouver ce comportement assez ennuyeux, en particulier avec les menus imbriqués, sur YouTube sur un HTPC. La souris à distance est facile à dévier et wham Je dois recommencer. Quiconque ayant une dextérité moins que parfaite trouvera cela ennuyeux.
Veuillez ne pas faire du chemin précis du pointeur une partie nécessaire de l'interface utilisateur. Certaines personnes ont des problèmes de mobilité, certaines ont moins que des dispositifs de pointage, certaines sont dans un véhicule en mouvement, etc.
En dehors de ce que DPS a répondu, qui parle de cohérence, je vous suggère de choisir le clic au lieu de survoler . Il semble que vous ayez une disposition de grille, et je suis sûr que vous ne voulez pas ennuyer vos utilisateurs en faisant apparaître le menu d'action lorsqu'ils déplacent la souris sur ces éléments de la grille.
Il vaut mieux le garder explicite, uniquement lorsque l'utilisateur essaie de cliquer sur le bouton d'action. Une autre chose que vous pouvez faire ici est de changer l'icône afin qu'il soit clair qu'il doit cliquer de nouveau pour la basculer, quelque chose comme:
Assurez-vous qu'il doit s'effondrer si l'utilisateur clique ailleurs sur la page (cela inclut également les utilisateurs qui essaient de cliquer sur le menu d'action d'une autre image)
Une autre chose que vous pouvez essayer est d'avoir des boutons d'action communs et de laisser l'utilisateur sélectionner les images sur un clic long. La seule chose qui pourrait être un problème ici est l'option de déplacement. Je ne sais pas quelles fonctionnalités vous avez en place là-bas (c'est-à-dire qu'elles peuvent être déplacées, cliquez sur Trier, etc.)
Vous pouvez animer ces icônes en douceur une fois que l'utilisateur a sélectionné> = 1 image dans la grille.
Je dirais: cliquez sur ... pour ouvrir, cliquez n'importe où mais le menu déroulant pour fermer. Une fois que nous avons cliqué sur le bouton ouvert, nous avons tendance à nous éloigner et à revenir en arrière et en appuyant à nouveau peut être épuisant. Il existe également un danger d'appuyer sur le premier élément de la liste déroulante. J'ai vu l'ouverture/la fermeture en survolant si mal que je pense que cela ne devrait pas être une option. Ce qui se passe, c'est que la liste déroulante disparaît une fois que vous commencez à quitter le ... vers le menu.
- Passer la souris sur les événements, laisser la souris pour ouvrir-fermer un menu déroulant n'est généralement pas une bonne idée.
- De préférence, cliquer ou toucher les événements devrait ouvrir-fermer un menu déroulant.
Pour être plus précis ... Dans l'exemple que vous avez fourni dans votre question où le menu déroulant s'ouvre au-dessus d'un élément d'image, une chose que vous pourriez faire est de réduire l'opacité du menu (par exemple à 20%) si l'utilisateur déplace la souris de la boîte de menu. Dans ce cas, vous aurez entre les mains un menu partiellement transparent afin que l'utilisateur puisse toujours voir l'élément en dessous du menu.
Fermer immédiatement une telle liste même si la souris est un pixel hors de sa région pendant une fraction de seconde - en particulier avec des listes déroulantes où la région change en raison de sous-menus (ce qui signifie également que votre utilisateur doit répéter toute une chaîne de navigation dans le pire des cas), etc. . - a tendance à être très sensible aux mouvements parasites de la souris (aggravé si: mauvaises compétences de la souris, une souris configurée pour la vitesse et non la précision, un environnement de travail riche en vibrations, une petite taille des éléments de l'interface utilisateur).
Laisser le menu ouvert rester indéfiniment peut entraîner la confusion de l'utilisateur quant à la façon de fermer un menu qui couvre du contenu ou d'autres éléments d'interface utilisateur.
Les retards et certaines hystérésis entre les régions d'activation et de désactivation suivront probablement le principe du moins d'étonnement.
Mobile ou pas?
Il y a quelques années, lorsque la seule entrée était d'utiliser la souris (ou d'appuyer sur la touche Alt ... personne ne s'y attendait vraiment), le survol de la souris était une bonne option.
Mais plus maintenant.
La conception réduite que vous utilisez implique que la conception est destinée à un petit appareil, il n'y a donc pas de survol réel de la souris.
Mon opinion est cliquez pour ouvrir et cliquez pour fermer.
Une minuterie?
Mais vous aussi pourrait inclure une minuterie. Si aucune entrée n'est effectuée en quelques secondes, ce menu peut s'effondrer.
Quelques problèmes avec la souris
Problème évident avec un appareil mobile.
Un utilisateur de bureau pourrait avoir des problèmes, par exemple avec une souris défectueuse qui déplace le pointeur de la souris comme un fou (j'avais parfois des souris bon marché)
Certains pads d'ordinateur portable peuvent être difficiles à utiliser. Un survol/sortie de la souris nécessite plus de compétences de la part de l'utilisateur.
Un autre problème de réflexion sur une approche de vol stationnaire avec la souris est que l'utilisateur peut avoir besoin de déplacer le pointeur pour une raison quelconque, mais qu'il a toujours besoin que ce menu soit ouvert. Une capture d'écran? Vous travaillez dans une autre fenêtre?