Tous les articles

:hover vs :active

Par Eric Le Bihan

Qu’est-ce qui fait qu’une interface est agréable à utiliser ?

Qu’elle soit intuitive, claire, que le regroupement des catégories soit logique, que les risques d’erreurs soit limités, que les messages d’information soient clairs ?
Tout ça et bien d’autres choses encore.

Je voudrais aujourd’hui parler plus particulièrement des boutons d’actions que ce soit des boutons de validation de formulaire ou des liens de navigations.

En général et dans la plupart des sites professionnels il sont particulièrement mis en valeur (avec plus ou moins de succès) pour que l’internaute sache comment naviguer et comment valider ses formulaires. Dans la vraie vie, en appuyant sur un bouton on s’attend à ce qu’il s’enfonce ou du moins qu’il réagisse à notre action par un changement d’état ou par l’émission d’un son. Je me demande pourquoi cette convention parfaitement adaptée aux interfaces de sites web n’est pas appliquée systématiquement, surtout que pour les boutons de validation, le langage html intègre ce comportement par défaut ? Dans la plupart des cas le mode :hover et préféré au mode :active, si bien qu’on a l’impression d’avoir une réponse en décalage avec l’action. Je survole le bouton = changement d’état (voire état enfoncé), je clique = rien. ça peut paraitre anodin comme ça mais testez la différence sur un site qui se rapproche d’une interface physique avec des changement d’état au clic et vous me direz quelle version vous préférez.

Le site web Metalabdesign.com, est un bon exemple de mise en application de ce principe :

Meta Lab Design

Article rédigé par , publié le dans la catégorie Ergonomie. Vous pouvez suivre les commentaires de cet article en utilisant le flux RSS dédié. Les commentaires sont fermés sur cet article.

20 commentaires

Flux RSS des commentaires de cet article

A priori, sur le site donné en exemple, il n’y a que sur la navigation du haut que l’état « :active » a été travaillé. Puis après quelques clics, je me suis rendu compte que l’image enfoncée de « next client » par exemple, n’était pas chargée.

Le 13 Sep. 2009 à 21h35 par raphaël

l’état :active pour ma part je ne l’utilise pas via les CSS justement pour une raison, un clic relâché en dehors du bouton laisse l’état enfoncé du bouton (:active).

Je lui préfères le javascript onmousedown et onmouseup pour gérer ces états. Néanmoins il est aussi possible d’utiliser l’événement de déplacement de la souris afin de replacer le bouton dans son état normal en cas d’événement onreleaseoutside (qui n’existe pas en javascript certes mais c’est pour l’analogie avec l’événement en flash). Mais je trouves l’effet moins convaincant.

Cela dit je concède l’aspect rapide de cette méthode pour gérer les 3 états d’un bouton html.

Le 15 Sep. 2009 à 06h42 par bertrand germain

Un effet qui ne prend pas beaucoup de temps à mettre en place (pas d’image à préparer) avec :active est :

p.lienenformedebouton a:active {
position:relative;
top: 1px;
left: 1px;
}

Ça décale d’1px le « bouton » au clic et donne l’illusion qu’on enfonce celui-ci. J’ai oublié la source de cette astuce (CSS-Tricks peut-être) ; elle est visible en ligne sur http://www.alsace.com (boutons verts « About us » et « Read more » sous les deux colonnes de texte)

Le 15 Sep. 2009 à 09h50 par Felipe

C’est vrai ça je ne m’étais jamais fait la remarque mais c’est un peu con de mettre un effet « enfoncé » sur un bouton au survol de la souris et rien au clic en lui-même. Cet article tombe bien je refait la home de mon site. J’en prends bonne note merci !

Le 17 Sep. 2009 à 20h48 par moins52

Il faut dire que très peut de graphistes déclinent leurs maquettes avec cet état (ou avec un état :hover) Il est donc difficile de remédier au problème rapidement mais j’approuve ta démarche en affirmant que la mise en avant de cet « effet » est important pour l’utilisateur.

Pour appuyer ton article tu as un excellente utilisation du :active dans la partie administration de la galerie Picsengine.

Le 20 Sep. 2009 à 19h51 par Xavier

En effet c’est au graphiste à penser à ce genre de chose. Il serait d’ailleurs intéressant de penser à implémenter les états des boutons dans Photoshop… ou Gimp :)

Le 16 Oct. 2009 à 14h20 par Raphaël

A voir: gog.com, un site qui est d’ailleurs tres classe au cote dez effets GUI.

La reponse tactile du bouton , c’est bein quelquechose de sacre, mais la pluspart de temps on l’a deja — soit du clavier, ou de la souri. Avec l’iPod Touch, on commence a voir des problemes, surtout que la vitesse de la connection peut bien etre en doubte, de plus que les effects :hover/:focus ne vallent plus rien.

Mais sur ordi, je trouve beaucoup plus important de montrer que l’on peut cliquer — la confirmation devrait etre evidente dans le resultat de l’action…

Le 11 Nov. 2009 à 16h17 par Barney

Une fois n’est pas coutume, je ne suis pas d’accord.

On insiste sur l’importance de cet effet (ou tout bêtement son caractère positif) en faisant l’analogie avec un bouton pressoir physique. Or, un lien ou bouton sur un site ou une application web n’est pas un élément physique, et les caractéristiques de l’un se prêtent mal à l’autre.

Pour commencer, il faut bien comprendre que si le bouton pressoir s’abaisse, c’est parce que ce mouvement est nécessaire pour que l’action de l’utilisateur soit enregistrée. C’est une contrainte mécanique avant tout. On remarquera qu’elle n’existe pas, cette contrainte, pour les interfaces tactiles. La métaphore du bouton pressoir physique n’est pas négligeable, mais c’est aller un peu vite en besogne que de dire qu’elle est adaptée pour les interfaces informatiques en général, ou pour un menu de navigation de site web en particulier.

Qu’est-ce qui importe vraiment dans ces interfaces? Simplement: fournir un feedback à l’utilisateur pour qu’il comprenne que son action a été prise en compte (et ne cherche pas soit à la répéter inutilement, soit à trouver un autre moyen d’effectuer une action). C’est pourquoi certaines interfaces tactiles rajoutent un son ou un tremblement de l’appareil lorsque certains «boutons» sont «pressés». Mais ce type de feedback n’est pas un passage obligé; il s’agit en général de cas particuliers (claviers virtuels sur mobile tactile…).

Quid d’un site web, et notamment d’un menu de navigation sur un site classique avec des pages HTML séparées? La réaction principale, c’est le changement de page. On peut découper cette réaction en trois éléments:
1. indicateur de chargement dans l’interface du navigateur (barre de progression ou visuel tournant dans l’onglet, voire les deux);
2. possible chamboulement visuel de la page (passage au blanc, phase d’affichage progressif d’un contenu);
3. au final, présence d’un contenu différent, avec éventuellement variation de la mise en page.

Ça fait déjà pas mal de choses. À cela, on peut rajouter la pression du doigt sur la touche Entrée (navigation au clavier), ou sur la souris ou le pavé tactile, avec éventuellement un clic (son) en réaction. Il se peut aussi que le système d’exploitation rajoute un son au clic (il me semble que certaines versions de Windows font ça, non?).

À cette profusion de signaux, on voudrait rajouter un effet graphique sur le bouton. On obtiendrait donc, de manière détaillée:
0. Action physique de l’utilisateur.
1. Éventuel retour physique et/ou sonore du périphérique de saisi (souris, clavier, pavé tactile).
2. Éventuel retour sonore du système d’exploitation.
3. Changement graphique du bouton.
4. Indicateurs de chargement du navigateur.
5. (Latence.)
6. Dessin du nouveau contenu (de instantané à plusieurs secondes).
7. Chargement d’un nouveau contenu.

Je ne suis pas sûr qu’on ait besoin de ce numéro 3.

Et je ne reviens pas sur les incohérences d’implémentation de :active dans IE 6 et 7, le fait que l’état :active persiste dans plusieurs navigateurs si on relâche la pression en dehors du lien, ou encore qu’il persiste lorsque l’on revient à la page précédente. Diverses petites choses qui font que le signal donné peut être contre-productif, en plus d’être superflu.

(La prochaine fois, on parle de l’inutilité de :visited?)

Le 22 Déc. 2009 à 12h38 par Florent V.

Le point 3 représente pour moi la couche applicative, entre le système d’exploitation et le navigateur.

Pourquoi n’aurait-elle pas le droit à son propre retour pour indiquer qu’elle fonctionne bien, comme le peuvent les périphérique, système d’exploitation et navigateur ?

J’ai hâte de débattre sur le :visited qui est utile très souvent, mais ça tout le monde est d’accord.

Le 22 Déc. 2009 à 13h58 par Corentin

Je me sers d’active et hover de la même manière car la navigation au clavier par la touche tabulation rend le lien sélectionné actif et donc, cela permet d’avoir un hover pour les personnes qui n’ont pas de souris.

En fat, active signifie : si tu appuie sur entrée, tu suivra le lien sélectionné.

Bref, je pense que ton interprétation du sélecteur est mauvaise. Mais bon, tu as ouvert le débat, peut-être qu’il manque certains sélecteurs CSS, vous avez vu qqchose dans CSS 3 qui comblerai la lacune actuelle ?

Le 28 Déc. 2009 à 11h35 par Nicolas Froidure

Re,

En fait, ton interprétation est probablement bonne, j’ai fait un raccourci un peu hâtif. Focus est plus approprié effectivement pour afficher le focus même si IE se comporte différemment.

Du coup, :active reste un mystère car il ne fonctionne qu’avec la souris, pas quand on navigue au clavier et qu’on tape entrée (du moins sur mon Firefox 3.5) ce qui devrait être le cas si ton interprétation de sa destination est correcte.

En fait, en regardant les specs, on s’aperçoit que le comportement cité en exemple est implémenté, sans vraiment aller plus loin et le transposer à la navigation clavier. En fait, il serait mieux que le parcours d’un lien avec la touche entrée ne se fasse qu’au relâchement de la touche, et non à l’enfoncement de celle-ci (onKeyPress). Ca permettrai d’appliquer ce sélecteur à la navigation clavier.

Le 28 Déc. 2009 à 13h45 par Nicolas Froidure

Il est parfaitement exact qu’il faudrait prévoir les enfoncements de boutons dans les interfaces. Une excellente raison pour cela est que les IHM des window managers le font très souvent et que donc, que cela soit mal ou bien, les usagers sont habitués à un tel comportement.

Maintenant, il est absolument nécessaire de se rendre compte que ce comportement « par défaut » des window managers dépend de la plate-forme. Par exemple sur Mac OS X, certains boutons ont un comportement en mode :active mais pas en mode :hover (les + et – des listes par exemple). On règlera ce genre de choses (dans une page Web) par exemple en mettant programmatiquement une classe dépendant du système à l’élément body et en utilisant un body.telleClasse dans les sélecteurs appropriés des feuilles de style. On peut aussi utiliser des « hacks » CSS sélectionnant la plateforme mais personnellement je trouve cela très cracra…

Globalement, il faut utiliser les sélecteurs :hover pour le survol et :hover:active (les deux à la fois) pour l’action. J’ai lu plus haut que quelqu’un se plaint qu’un navigateur ne « relacherait » pas l’état si la souris est relachée hors du bouton. Face à ces sélecteurs, un tel comportement doit être traité comme un bug. Utiliser des event handlers sur la souris, ça marche aussi mais pourquoi faire du programmatique quand on peut faire du déclaratif ?

Voila, en hopant que ça helpe.

Daniel Glazman, W3C CSS WG Co-Chairman

Le 28 Déc. 2009 à 14h11 par Daniel Glazman

Re,

Ca sert d’avoir un frenchy dans le working group CSS3 ;). Le coup du :hover:active est simple, mais fallait y penser.

Sinon, je me permet de retourner encore plus ma veste en appuyant le discours sur la nécessité ou du moins, l’utilité d’implémenter un comportement :active sur un bouton.

En effet, la représentation visuelle du bouton enfoncé pourrait correspondre à l’enfoncement de la touche entrée si :active était également implémenté pour la navigation au clavier. Reste à savoir si ça le sera et si c’est justifié que ça le soit.

Peut-être qu’il faudrait créer un ticket pour Firefox sur ce thème ?

Le 28 Déc. 2009 à 14h21 par Nicolas Froidure

> Peut-être qu’il faudrait créer un ticket pour Firefox sur ce thème ?

Oui probablement. La spec Selectors Level 3 dit explicitement « The :active pseudo-class applies while an element is being activated by the user ». Ce qui tendrait à signifier que keydown avec la bonne touche clavier devrait basculer l’élément en mode :active.

Le 28 Déc. 2009 à 14h38 par Daniel Glazman

Il resterait alors trois bugs à signaler pour Firefox:

1. Lors d’un retour à la page précédente (bouton back du navigateur), le dernier lien cliqué a l’état :active, qu’il ne devrait pas conserver.

2. Lors d’un clic sur un lien pointant dans la page en cours, le lien cliqué conserve l’état :active jusqu’au clic sur un autre élément de la page. Il devrait perdre cet état dès le moment où le bouton d’action (bouton de la souris ou touche du clavier) est relâché.

3. Dans le cas où le bouton d’action (bouton de la souris ou touche du clavier) serait conservé appuyé par l’utilisateur, le lien devrait perdre l’état :active si le pointeur quitte la zone du lien. Ou dès que le lien perd le focus. C’est ce que fait Gnome, par exemple. (Et la solution du :focus:active est intéressante, mais du coup il faut renoncer à déclarer un comportement valable également en navigation au clavier…)

Le 28 Déc. 2009 à 19h15 par Florent V.

Florent : Pour les points 1 et 2, tu décris le comportement de l’état :focus sur Firefox. Le :active n’existe plus lorsque le bouton est relâché (couleur rouge par défaut sur les liens).

Firefox, contrairement à d’autres navigateurs, déclenche le :focus à la souris ; je pense que le problème vient de ce comportement.

Le 28 Déc. 2009 à 19h30 par Pierre Bertet

« Il serait d’ailleurs intéressant de penser à implémenter les états des boutons dans Photoshop… ou Gimp :) »
Le 16 oct. 2009 à 14h20 par Raphaël

Pour Gimp, lors de la création d’un bouton il crée automatiquement 3 images, pour les 3 positions ! Ça fait longtemps maintenant. On peut même personnaliser ces états.

Le 30 Avr. 2010 à 10h21 par Damien

Les commentaires sont fermés sur cet article.