Nous avons une discussion dans le département UX ici au travail pour savoir si les états de survol sont nécessaires ou non à une interface utilisateur. Nous sommes en quelque sorte divisés . Voici les deux arguments:

Contre (a lancé la discussion):

Jai personnellement eu une prédisposition à ne pas avoir détats de survol… pour moi, cela ajoute du bruit visuel sans vraiment aucun avantage sauf dans des circonstances très limitées. Venant du monde mobile, il nexiste pas détat de basculement, et je nai jamais manqué cela ou souhaité quil soit disponible pour les articles de base. Les logiciels PC navaient pas lhabitude dutiliser des rollovers, mais je faisais juste des tests et je vois quils sont maintenant très utilisés. Mais jai recherché des vidéos Mac YouTube Lion et elles ne semblent pas utiliser détats de survol.

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 serais hérissé de lidée aussi, et je forcerai typiquement des états de survol à être ajoutés sils ne sont pas déjà.

Cest drôle parce que cest juste quelque chose qui est tellement standard maintenant quil nest jamais remis en question. La plupart des recherches que je peux creuser ont à voir avec le bon traitement de survol plutôt que de tester si le survol doit être utilisé. Vous avez raison de dire quil nétait pas utilisé dans le passé, mais cétait plutôt une carence de la technologie de linterface utilisateur. Il est certainement possible que les utilisateurs sy 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 survol aient un effet négatif sur la convivialité, cest pourquoi je dirais que nous devrions toujours utiliser le survol.

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é). Lorsquelles sont effectuées correctement, elles fournissent à lutilisateur un retour visuel indiquant que le contrôle fait quelque chose. Cela aide également linterface à communiquer avec lutilisateur – cest comme si elle disait à lutilisateur que lapplication écoute.

Voici mon ajout à la conversation (je suis pro des états de survol):

Je pense quil y a une nécessité inhérente pour les états de survol sur des éléments dinterface utilisateur particulièrement non traditionnels. Avec les boutons Soumettre, les liens et les éléments de liste, je pense quil y a une attente et une supposition quils sont cliquables. Dautres éléments comme le canevas / Les éléments pouvant être déplacés ne sont pas des éléments dinterface utilisateur «naturels», les utilisateurs ne sauraient donc pas nécessairement quil existe des actions sous-jacentes associées à ces objets.

Les changements de curseur (passant de normal à pointeur) suffisent pour un identifiant pour moi de savoir que quelque chose est cliquable, mais la plupart des gens ne comprennent pas cette distinction. Ce n’est pas assez visuel car il s’agit d’un changement subtil de forme. À moins que vous ne vous concentriez sur la pointe de la flèche, otice it.

Les états de survol, en revanche, offrent une stimulation visuelle plus élevée car [je dirais que] le cerveau répond naturellement aux changements de couleur plus rapidement quaux changements de forme.

Jaimerais entendre les opinions de tout le monde concernant les états de survol. Les utilisez-vous? Quand les trouvez-vous nécessaires? Ou sagit-il simplement dun bruit visuel?

Commentaires

  • De quel type de contenu parlez-vous dinclure dans ces états de survol? Juste un retour visuel du survol? Ttooltips, ou cherchez-vous à inclure du contenu de données réelles auquel vous ne ‘ pas accéder par dautres moyens?
  • Juste le retour visuel en général.

Réponse

Je vote « oui »! Certes, les événements de survol ne devraient pas être dépendants car 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 permettent « clickablity » . Vous ne devriez pas avoir à cliquer sur quelque chose pour le savoir sil sagit dun bouton. Les utilisateurs dordinateurs portables et de bureau sattendent à ce que les éléments « cliquables » réagissent au survol, et avoir un bouton « allumé » est un indice utile.

Pensez-y comme une forme de amélioration progressive . Cest utile pour ceux qui peuvent utiliser il, et inoffensif pour ceux qui ne le peuvent pas!

Commentaires

  • En fait, je ‘ aller jusquà dire que sur un bureau environnement de navigation, lutilisateur pourrait presque penser quil y a quelque chose qui cloche si rien dautre que le curseur ne change – nous sommes devenus tellement habitués à survoler les changements.
  • Cétait mon argument / pensée le plus fort. Nous ‘ nous y sommes tellement habitués quil ‘ serait bizarre de ne pas lavoir.
  • Bon point sur lamélioration progressive. Je ‘ d ajouter une autre chose à "You shouldn't have to click something to find out if it's a button." cependant; vous ne devriez pas ‘ avoir à survoler quelque chose pour savoir si ‘ est un bouton.
  • Je dirais également que lajout détats de survol visuels sur les boutons donne à lutilisateur un retour positif sur son action ou un sentiment de récompense mentale.
  • Ayant quitté Windows 7 qui reposait fortement sur les états de survol et souvent utilisé des contours ou des panneaux pour indiquer les boutons, à Windows 8 qui ne fait souvent ni dans le  » Metro  » interface de style, jai ‘ trouvé Win 8 incroyablement frustrant à utiliser parfois. Cest peut-être ce pour quoi MS veut que les concepteurs codent pour Win 8, mais IMX ‘ est clairement incorrect de le faire.

Réponse

Jessaie déviter autant que possible les états de survol dans la conception. La raison principale en est qu’ils n’ont pas de sens sur les appareils tactiles.

Bien que cela puisse sembler ne pas sappliquer lorsque vous ne concevez pas pour mobile, de nombreuses personnes utilisent leurs tablettes ou autres appareils tactiles pour parcourez les mêmes sites Web ou utilisez les mêmes applications que vous nutiliseriez traditionnellement que sur un ordinateur équipé dune souris.

En vous contraignant pour ne pas utiliser les événements de survol, non seulement vous améliorez lexpérience quel que soit lappareil que vous utilisez, mais vous facilitez également la création dune application native tactile plus tard.

Commentaires

  • Les états de survol sont toujours utiles sur les sites Web mobiles. Le CSS :hover est effectivement traité comme :active lorsquil est affiché sur un appareil mobile. Cela indique visuellement que le doigt de lutilisateur ‘ a atteint la cible. Ces commentaires sont beaucoup plus utiles sur les conceptions mobiles en raison de la parallaxe. Lorsque votre ligne de visée sécarte de la ligne perpendiculaire à lécran, les chances de toucher incorrect augmentent.
  • @JoJo survole les états ne sont ‘ détectables sur mobile , et taper équivaut à cliquer sur un ordinateur.
  • John, daprès mon expérience de consultation de sites que jai ‘ conçus pour un ordinateur de bureau sur mobile, je crois que JoJo a raison de dire que létat de survol agit [parfois] comme létat actif. Je dis parfois parce que ‘ est un peu capricieux et ne ‘ pas toujours affiché.
  • @Jon I ‘ m ne dis pas comment il se traduit, je ‘ m discute de la façon dont il est logique de traduire. Si le survol devient actif, comment sélectionnez-vous? Tapez deux fois? Cela brise tout le paradigme tactile.
  • @JoJo pas toujours, je ne ‘ pas croire que Chrome sur Android déclenche létat de survol du tout, et Safari ‘ est souvent gênant

Réponse

Avec lémergence de le toucher étant un moyen majeur dinteragir avec le logiciel, je dirais que les interactions basées sur le survol sont désormais reléguées à « agréable davoir des améliorations » mais ne devraient jamais être une exigence pour interagir avec le logiciel.

Réponse

Je duplique souvent létat: hover pour: focus, car cest un moyen utile dindiquer le focus pour un utilisateur utilisant uniquement le clavier (ce qui est nécessaire pour répondre aux WCAG2 Cela indique quun élément est interactif dune certaine manière, sans avoir besoin dun événement de clic qui déclenchera une action que lutilisateur na pas encore décidé de lancer. Vous pouvez simplement styliser pour: focus sans: hover, mais à mon avis, lintention des deux actions est la même et devrait avoir le même effet visuel dans la mesure du possible.

Réponse

Je suis également daccord avec Sam pour dire que les états de survol peuvent être considérés amélioration progressive . Je voudrais juste clarifier cela un peu.

Dun point de vue mobile dabord , les états de survol ne servent pas vraiment à servir. Linterface utilisateur devrait donc offrir des comportements cliquables pour les objets cliquables sans état de survol (cest-à-dire que les comme les boutons).

Si vous pouvez prendre en charge cette notion sur un appareil mobile, cette même notion sera également prise en charge sur les ordinateurs de bureau / portables même avant lintroduction des états de survol.

Linclusion dun état de survol sur les appareils prenant en charge le survol – ordinateurs portables, ordinateurs de bureau, etc. – confirmera la perception déjà existante de lutilisateur selon laquelle un élément dinterface utilisateur spécifique est en fait cliquable.

Donc, pour récapituler:

  1. Créez des éléments dinterface utilisateur cliquables de sorte quils permettent un comportement cliquable pour nimporte quel appareil.
  2. Utilisez les états de survol sur les appareils qui prennent en charge le survol soutiennent en outre la notion quun élément est cliquable.

Réponse

+1 à Sam pour avoir mentionné lamélioration progressive.

Je recommande dutiliser les états de survol sils fournissent une certaine utilité qui améliore linterface utilisateur, mais ils ne devraient jamais être nécessaires pour terminer une tâche.

Par exemple, en les utilisant sur une page de liste de produits pour fournir un peu dinformations sur larticle en survolant limage, avant que lutilisateur ne navigue. Ces informations devraient alors également être disponibles sur la page du produit elle-même. ne nuit pas à la expérience de lutilisateur de lécran tactile, mais ajoute une utilité supplémentaire pour ceux qui font le voient. 🙂

Réponse

Ce nest pas parce que vous « concevez pour le bureau et le mobile » que les designs doivent être les même. Linteraction à 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, cest é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 survol, il est soudainement évident que cest cliquable.

Surtout maintenant cette animation devient de plus en plus courant, un état de survol est une animation de base qui indique aux utilisateurs quils « font ce quils avaient lintention de faire.

Ne pas utiliser un état de survol pour le bureau est paresseux et rend les gens tristes.

Réponse

Je ne crois pas que les états :hover sont essentiels; Les éléments de linterface 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 «Publier votre réponse» ici sur UX.SE) testent bien dans ma propre expérience. Cela ne veut pas dire que ce nest pas utile ; juste que ce « nest pas essentiel.

Je considère cependant que les états :focus et surtout :active sont essentiels; le ce dernier en particulier est celui que je vois ignoré sur beaucoup trop de sites. Un état actif clair permet à lutilisateur de savoir que le clic sur le bouton a été enregistré immédiatement (, ce qui est extrêmement important pour aider les utilisateurs à sentir quils manipulent directement un objet dans linterface utilisateur ). Les commandes système telles que les boutons et les menus ont également rendu cet état attendu, ce qui rend leur oubli encore plus impardonnable.

Réponse

Je suggérerais que les états de survol fournissent une rétroaction positive à lattente de lutilisateur que lélément en question soit interactif, supprimant ainsi le potentiel de sentiments plus négatifs de doute et dambiguïté .

Les designs fournissent un certain nombre dindices quun élément est interactif – forme, taille, position, couleur, soulignement, etc. Différents utilisateurs auront besoin de repères différents s, et peut-être leffet cumulatif dun nombre différent dindices, pour percevoir (et être sûr que) lélément est interactif. Changer un élément en survol est une opportunité de fournir plus dindices.

La plupart des navigateurs (sinon tous) fournissent des indices au survol par défaut, en changeant le curseur en pointeur. Bien sûr, nous avons le contrôle sur cela et pouvons supprimer létat de survol en supprimant cet effet. Mais jimagine que pour la plupart dentre nous (prenez un moment pour limaginer), 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 indices supplémentaires lors du survol que ne pas fournir dindices serait une contradiction significative de tout signal précédemment perçu que lélément est interactif.

Suppression de la valeur par défaut du navigateur cue est donc un exemple utile de la valeur de létat de survol. Pour moi, la question nest donc pas de savoir si les repères visuels dinteractivité en survol sont précieux, mais lesquels et combien sont optimaux.

Il y en a précédents familiers utiles, mais la réponse à cette question dépendra de lapplication et du public cible.

Réponse

Je suggérerais survolez lorsquil ny a pas dicône dans le bouton. Si vous supposez quil y a une icône colorée dans le bouton à cette heure, il nest pas indispensable de donner un état de survol au bouton. Ex: inscrivez-vous à laide du bouton Google.

Réponse

Les survols sont indispensables pour tous les sites Web qui souhaitent obtenir une bonne réponse en ligne. Jai utilisé certains sites Web qui jai abandonné le statut de survol, sur mon ordinateur portable, et cétait très frustrant.Tout bon concepteur sait que les internautes sont pressés de trouver ce quils veulent, et si un bouton ne vous dit pas sil en est un ou non et que vous devez louvrir dans un nouvel onglet pour le savoir – cest un gros échec!

Correct, les survols ne sont pas nécessaires pour le mobile. Mais vous pouvez toujours les désactiver pour mobile. En outre, noublions pas que les boutons pour mobile doivent être beaucoup plus gros que ceux pour en ligne. Et, ne sont-ils pas créés sur deux feuilles de style différentes de toute façon?

Commentaires

  • Pour les sites Web, changer le style du curseur en main (ou équivalent) est leffet de survol sur lequel jagis.
  • Je pense quil faut encore montrer le survol, juste une main confond lutilisateur, car nous voulons que le Web fonctionne aussi réaliste que possible, et lorsque nous cliquons sur des choses si elles sont réelles, elles reflètent. De plus, du point de vue dun stratège ‘, vous voudriez que votre site Web se sente plus sécurisé et quil ‘ que la plupart les sites Web frauduleux ne ‘ ne prennent pas la peine dinstaller leffet de survol – par conséquent, lorsque les utilisateurs ‘ ne voient pas leffet, ils commencent à se sentir bizarre à lintérieur.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *