Les états stationnaires sont-ils nécessaires?
Nous avons une discussion dans le département UX ici au travail pour savoir si les états de vol stationnaire sont nécessaires à une interface utilisateur. Nous sommes en quelque sorte divisés. Voici les deux arguments:
Contre (a commencé la discussion):
J'ai personnellement eu une prédisposition à ne pas avoir d'états stationnaires… pour moi, cela ajoute du bruit visuel sans vraiment aucun avantage sauf dans des circonstances très limitées. Venant du monde mobile, il n'y a rien de tel qu'un état de retournement, et je n'ai jamais manqué cela ou souhaité qu'il soit disponible pour les articles de base. Le logiciel PC n'utilisait pas les rollovers, mais je le testais juste et je vois qu'ils sont maintenant largement utilisés. Mais j'ai recherché quelques vidéos Mac YouTube Lion et elles ne semblent pas utiliser les états de vol stationnaire.
Pour (première réponse):
La réponse courte est, oui, nous devons avoir des états de survol sur chaque bouton de notre interface. Et j'étends généralement cela à tout ce qui est cliquable (éléments de zone de liste, liens (bien que cela soit gratuit) et tout autre élément personnalisé comme les nœuds de tableau blanc ou les cellules de tableau). Je voudrais aussi hérisser l'idée, et je forcerai généralement l'ajout d'états stationnaires s'ils ne le sont pas déjà.
C'est drôle parce que c'est juste quelque chose de tellement standard maintenant qu'il n'est jamais remis en question. La plupart des recherches que je peux creuser ont trait à ce que le bon traitement en vol stationnaire plutôt que de tester si le vol stationnaire doit être utilisé. Vous avez raison, il n'a pas été utilisé dans le passé, mais il s'agissait plutôt d'une carence en technologie d'interface utilisateur. Il est certainement possible que les utilisateurs s'y attendent et la technique est donc devenue une exigence de facto. De plus, ne pas avoir de vol stationnaire a tendance à apparaître comme désuet. Pour ces raisons, associées au fait que je ne pense pas que les états de vol stationnaire aient un effet négatif sur la convivialité, c'est pourquoi je dirais que nous devrions toujours utiliser le vol stationnaire.
Je ne suis pas sûr de bien voir la composante de bruit visuel. Je pousse toujours les concepteurs à rendre les survols très subtils (comme 60 à 80% de l'état sélectionné). Lorsqu'elles sont effectuées correctement, elles fournissent à l'utilisateur un retour visuel indiquant que le contrôle fait quelque chose. Il aide également l'interface à communiquer avec l'utilisateur - c'est comme si elle indiquait à l'utilisateur que l'application écoutait.
Voici mon ajout à la conversation (je suis des états de vol stationnaire):
Je pense qu'il y a une nécessité inhérente aux états de vol stationnaire sur des éléments d'interface utilisateur particulièrement non traditionnels. Avec les boutons Soumettre, les liens et les éléments de liste, je pense qu'il y a une attente et une supposition qu'ils sont cliquables. D'autres éléments tels que les éléments canvas/draggable ne sont pas des éléments d'interface utilisateur "naturels", de sorte que les utilisateurs ne sauraient pas nécessairement qu'il existe des actions sous-jacentes associées à ces objets.
Les changements de curseur (passant de normal à pointeur) suffisent pour que je sache que quelque chose est cliquable, mais la plupart des gens ne comprennent pas cette distinction. Ce n'est pas assez visuel car c'est un subtil changement de forme. À moins que vous ne soyez mis à zéro sur la pointe de la flèche, vous ne le remarquerez guère.
Les états en vol stationnaire, d'autre part, offrent une stimulation visuelle plus élevée parce que [je dirais que] le cerveau réagit naturellement aux changements de couleur plus rapidement qu'il ne le fait aux changements de forme.
Je voudrais entendre les opinions de tout le monde concernant les états en vol stationnaire. Les utilisez-vous? Quand les trouvez-vous nécessaires? Ou s'agit-il simplement de bruit visuel?
Je vote "oui"! Certes, le survol events ne devrait pas dépendre du fait que les appareils tactiles sont si populaires. Cependant, Jon semble poser des questions sur les états de survol visuel sur les boutons, ce qui est légèrement différent.
Les états de survol visuel offrent une "cliquabilité" . Vous ne devriez pas avoir à cliquer sur quelque chose pour savoir s'il s'agit d'un bouton. Les utilisateurs d'ordinateurs portables et de bureaux s'attendent à ce que les choses "cliquables" réagissent en vol stationnaire, et avoir un bouton "allumé" est un indice utile.
Considérez-le comme une forme d'amélioration progressive . Il est utile à ceux qui peuvent l'utiliser et inoffensif à ceux qui ne le peuvent pas!
J'essaie d'éviter autant que possible les états stationnaires dans la conception. La principale raison en est qu'ils n'ont aucun sens sur les appareils tactiles.
Bien que cela puisse sembler ne pas s'appliquer lorsque vous ne concevez pas pour mobile, de nombreuses personnes utilisent leurs tablettes ou autres appareils tactiles pour parcourir les mêmes sites Web ou utiliser les mêmes applications que vous utilisiez traditionnellement uniquement sur un ordinateur avec une souris .
En vous contraignant à ne pas utiliser les événements de survol, vous améliorez non seulement l'expérience quel que soit l'appareil que vous utilisez, mais vous simplifiez également la création ultérieure d'une application native spécifique au toucher.
L'émergence du toucher étant un moyen majeur d'interagir avec le logiciel, je dirais que les interactions basées sur le survol sont désormais reléguées à `` Nice pour avoir des améliorations '' mais ne devraient jamais être une exigence pour interagir avec le logiciel.
Je duplique souvent l'état: hover pour: focus, car c'est un moyen utile d'indiquer le focus pour un utilisateur avec clavier uniquement (ce qui est nécessaire pour rencontrer WCAG2). Cela indique qu'un élément est interactif d'une manière ou d'une autre, sans avoir besoin d'un événement de clic qui déclenchera une action que l'utilisateur n'a pas encore décidé de lancer. Vous pouvez simplement styliser pour: se concentrer sans: survoler, mais à mon avis, l'intention des deux actions est la même et devrait avoir le même effet visuel dans la mesure du possible.
Je conviens également du point de vue de Sam que les états de vol stationnaire peuvent être considérés amélioration progressive. Je voudrais juste clarifier un peu cela.
D'un point de vue mobile d'abord , les états de survol ne servent vraiment à rien. Ainsi, l'interface utilisateur a mieux à offrir des comportements cliquables pour les objets cliquables sans état de survol (c'est-à-dire que les boutons doivent ressembler à des boutons).
Si vous pouvez prendre en charge cette notion sur un appareil mobile, cette même notion sera également prise en charge sur les appareils de bureau/portables même avant l'introduction des états de survol .
Inclure un état de survol sur les appareils qui prennent en charge le survol - ordinateurs portables, ordinateurs de bureau, etc. - confirmera la perception déjà existante de l'utilisateur qu'un élément d'interface utilisateur spécifique est en fait cliquable.
Donc, pour récapituler:
- Créez des éléments d'interface utilisateur cliquables de manière à permettre un comportement cliquable pour n'importe quel appareil.
- Utilisez les états de survol sur les appareils qui prennent en charge le survol pour soutenir davantage la notion qu'un élément est cliquable.
Ce n'est pas parce que vous concevez à la fois pour ordinateur de bureau et mobile que les conceptions doivent être les mêmes. L'interaction à laquelle les utilisateurs mobiles peuvent être habitués peut ne pas être évidente pour les utilisateurs de bureau.
Par exemple, des cartes blanches avec un curseur sur le côté droit. Pour les utilisateurs mobiles, c'est évidemment quelque chose sur lequel vous pouvez appuyer. Pour les utilisateurs de bureau, pas autant (surtout si la carte est plus large sur le bureau), mais quand ils survolent et voient un état de vol stationnaire, il est soudain évident qu'il est cliquable.
Surtout maintenant que l'animation devient de plus en plus courante, un état de vol stationnaire est une animation de base qui donne aux utilisateurs des informations indiquant qu'ils font ce qu'ils avaient l'intention de faire.
Ne pas utiliser un état de vol stationnaire pour le bureau est paresseux et rend les gens tristes.
+1 à Sam pour avoir mentionné l'amélioration progressive.
Je recommanderais d'utiliser les états de survol s'ils fournissent une certaine utilité qui améliore l'interface utilisateur, mais ils ne devraient jamais être nécessaires pour effectuer une tâche.
Par exemple, les utiliser sur une page de liste de produits pour fournir un peu d'informations sur l'article lors du survol de l'image, avant que l'utilisateur ne navigue. Ces informations devraient ensuite également être disponibles sur la page du produit lui-même. Cela ne nuit donc pas à l'expérience de l'utilisateur de l'écran tactile, mais ajoute une utilité supplémentaire pour ceux qui font le voient. :-)
Je suggère de survoler lorsqu'il n'y a pas d'icône dans le bouton. Si supposons qu'il y ait une icône colorée dans le bouton à ce moment-là, il n'est pas essentiel de donner un survol au bouton. Ex: inscrivez-vous en utilisant le bouton Google.
Les survols sont indispensables pour tous les sites Web qui souhaitent une bonne réponse en ligne. J'ai utilisé certains sites Web qui ont abandonné le statut de vol stationnaire sur mon ordinateur portable, et c'était très frustrant. Tout bon designer sait que les gens en ligne sont pressés de trouver ce qu'ils veulent, et si un bouton ne vous dit pas si c'est le cas et que vous devez l'ouvrir dans un nouvel onglet pour le découvrir - c'est un grand échec!
Correct, les survols ne sont pas requis pour les mobiles. Mais, vous pouvez toujours les désactiver pour mobile. Par ailleurs, n'oublions pas que les boutons pour mobile doivent être beaucoup plus gros que ceux pour en ligne. Et ne sont-ils pas créés de toute façon sur deux feuilles de style différentes?
Je ne crois pas :hover les états sont essentiels; Les éléments de l'interface utilisateur sur le bureau se sont débrouillés sans eux pour toujours et les objets clairement conçus pour permettre de cliquer (comme le bouton "Publiez votre réponse" ici sur UX.SE) testent très bien dans ma propre expérience. Cela ne veut pas dire que ce n'est pas utile ; juste que ce n'est pas essentiel.
Je considère cependant :focus et particulièrement :active les états sont essentiels; ce dernier en particulier est celui que je vois ignoré sur beaucoup trop de sites. Un état actif clair aide l'utilisateur à savoir que le clic sur le bouton a été enregistré immédiatement ( ce qui est extrêmement important pour aider les utilisateurs à sentir qu'ils manipulent directement un objet dans l'interface utilisateur ). Les commandes du système telles que les boutons et les menus ont également rendu cet état attendu, ce qui rend leur oubli encore plus impardonnable.
Je suggérerais que les états stationnaires fournissent une rétroaction positive à l'attente de l'utilisateur que l'élément en question est interactif, éliminant ainsi le potentiel de sentiments de doute et d'ambiguïté plus négatifs.
Les conceptions fournissent un certain nombre d'indices qu'un élément est interactif - forme, taille, position, couleur, un soulignement, etc. Différents utilisateurs auront besoin d'indices différents, et peut-être de l'effet cumulatif d'un nombre différent d'indices, pour percevoir (et se sentir en confiance) que) l'élément est interactif. Changer un élément en survol est une opportunité pour fournir plus d'indices.
La plupart des navigateurs (sinon tous) fournissent des repères au survol par défaut, en changeant le curseur en pointeur. Bien sûr, nous avons le contrôle sur cela et pourrions supprimer l'état de vol stationnaire en supprimant cet effet. Mais j'imagine pour la plupart d'entre nous (prenez un moment pour l'imaginer) que cela introduirait un doute important dans notre expérience de navigation. Les navigateurs (puis les concepteurs) ont créé un tel précédent pour les signaux supplémentaires en vol stationnaire que le fait de ne pas fournir de signaux serait une contradiction significative de tous les signaux précédemment perçus que l'élément est interactif.
La suppression du repère par défaut du navigateur est donc un exemple utile de la valeur de l'état de survol. Pour moi, la question devient donc non pas de savoir si les indices visuels d'interactivité en vol stationnaire sont précieux, mais lesquels et combien d'indices sont optimaux.
Il existe des précédents familiers utiles, mais la réponse à cette question dépendra de l'application et du public cible.