C’est étrange de constater comme les habitudes ont la vie dure… Prenez par exemple les boutons ‘Reset‘ sur les formulaires : Je ne sais pas qui a eu cette idée folle, mais elle est incroyablement tenace.
J’ai déjà eu de nombreuses discussion à ce sujet, mais je profite du dernier édito de Jaokb Nielsen (Top-10 Application-Design Mistakes) pour vous le redire : Ne mettez pas de bouton ‘Reset‘ dans vos formulaires.
Qui a envie de supprimer toutes les données saisies d’un coup ? Qui va s’offusquer de ne pas se voir proposer cette fonction ? Quelle est l’intérêt pour vous ?
Donc une dernière fois : Ne mettez pas de bouton ‘Reset‘ dans vos formulaires.
Et ça sera mon dernier mot ! A vrai dire, je n’ai plus la force d’argumenter sur ce point, je me demande si je ne devrais pas fermer les commentaires pour ce billet…
Mais oui, quand on y réfléchit, ça se tiens!!! Et pourtant, à la base ça partait d’une bonne intention, donner des options à l’internaute.
Mais celle ci est absolument inutile, au contraire, elle peux pousser l’internaute à supprimer son propre message, tellement l’ergonomie rappelle le bouton “envoyer”..
Bon j’attends un article sur ce qu’il faut mettre dans input “value” pour le bouton envoyer… :)
je suis d’accord avec le billet, mais j’ai une autre question a proposer à fred, comment faire pour conjuguer accessibilité et interface riche car souvent les interfeces riches ne sont pas accessibles.
En tout cas, si un bouton “reset”, “annuler” ou autres “effacer” est indispensable (c’est parfois le cas dans des interfaces outils, applicatives), il faut penser à protéger les internautes contre une erreur de clic.
cf. quelques remarques et conseils sur ce genre de bouton:
“Ce défaut [bouton reset dans un formulaire] est d’autant plus grave si le bouton dangereux :
> est situé sur la droite de l’écran (comme s’il constituait la suite logique de l’action) ;
> se trouve près du bouton de validation ;
> possède un format comparable au bouton de validation ;
> a le format d’un bouton non dangereux (vert, bleu, souriant) ;
> est situé en bas de formulaire ;
> permet d’effacer un nombre important de données ;
> ne propose pas de message de confirmation suite au clic.
Si vous êtes obligé d’employer un tel bouton, essayez donc de faire tout l’inverse ! Présentez le de la manière suivante :
> plutôt sur la gauche de l’écran ;
> loin du bouton de validation ;
> dans un format différent et moins fort que le bouton de validation
(par exemple : plus petit, un lien hypertexte plutôt qu’un bouton, moins foncé, etc.) ;
> dans un format non anodin (et éventuellement qui alerte sur le caractère dangereux si l’on risque d’effacer beaucoup d’informations) ;
> plutôt en début de formulaire (surtout si le bouton sert essentiellement à revenir à l’étape précédente) ;
> associé à un message de confirmation si l’on risque d’effacer beaucoup de données ou des informations difficiles à saisir.”
mince,
j’ai oublié mon exemple préféré (ou presque… c’est vraiment hyper courant), sur le site du loto, où on peut entrer tous ses numéros dans un formulaire (soit 60 petites cases si on a joué 10 grilles), pour faire calculer le montant de ses gains par le site :
http://www.fdjeux.com/jeux/loto/loto_s_combien.php (cliquer sur “simple”, sinon c’est moins horrible)
… sauf si on clique par mégarde sur “effacer”
Désolé, je trouve le bouton RESET très utile …. non je déconne :)
(tu aurais du fermer les commentaires)
Le bouton reset… ah bon, des gens cliquent dessus ? o.O
Oui ! J’ai cliqué dessus mais ce n’était qu’un accident car ce maudit bouton était mal placé… Il était à la droite du bouton envoyer !
Mais, j’y pense… on pourrait aussi supprimer les boutons Preview/Prévisualiser? :D
Nan, mais c’est vrai, ça doit bien arriver que les gens cliquent dessus et ferment la fenêtre en croyant qu’ils ont bien cliqué sur “valider/envoyer”…
Ce qui est quand-même génial sur ton blog Fred, c’est que, même si “prévisualiser” est à gauche, en tapant la touche Tab une fois, on arrive directement à droite, sur “envoyer”, donc moins de risque de se tromper :)
@ marti > En fait une interface riche n’a pas besoin d’être accessible. L’important est de proposer une alternative.
/Fred
et pourquoi pas laisser le bouton “reset” mais le nommer “j’ai de la chance” ?
C’est pas plus utile mais ça ajoute une touche d’humour
Et que dire des Français qui ont traduit “reset” par “annuler” ?
Alors que malgré son utilité douteuse, le bouton reset dispose en anglais d’un sens clair (remise à l’état initial), en français le “annuler” se rapproche plus des “undo” ou “cancel” anglais : annuler la modification en cours, retour à l’état précedent (et non pas initial)…
Je connais une boîte dans laquelle la MOA distingue les valeurs mémorisées de la saisie des valeurs par défaut (elle a bien compris le sens de reset). Nos inputs n’ont donc par 1 valeur, mais 1 valeur et 1 valeur par défaut. Ajoutez à ça que les développeurs voudraient distinguer les valeurs de session saisie, les valeurs par défaut mais aussi les valeur déjà en base dans le cas d’une saisie pour modification, et là vous obtenez un bordel que plus personne ne comprend. Faisons la peau à ce bouton (hohoho) !
» “En fait une interface riche n’a pas besoin d’être accessible. L’important est de proposer une alternative.”
Sauf ton respect, l’alternative ne devrait être considérée qu’en dernier recours. Il n’y a pas lieu de proposer des versions amoindries d’un outil si celui-ci peut être conçu de manière accessible dès le départ.
tout à fait d’accord Fred, et d’ailleurs, pour éviter que n’importe qui fasse n’importe quoi, je compte supprimer aussi tous les submit de mes formulaires ainsi que les liens dans les pages.
à bon entendeur…
Pour éviter le principal désagrément du bouton reset (le clic accidentel), il suffit de placer un petit Javascript confirm() sur le onclick, tout simplement ;-)
Benjamin D.C. :
Tout à fait, l’interface riche peut (et doit), dans beaucoup de cas, être simplement placée, de manière facultative, au-dessus des couches structure / présentation.
Il ne faut d’ailleurs pas perdre de vue que l’accessibilité est utile à tout le monde, y compris à ceux qui activent Javascript et n’ont aucun handicap physique.
Il ne faut pas négliger certains points dans la conception d’une interface riche, comme la navigation au clavier, l’utilisation des ancres dans l’URL lorsque le contenu est généré en AJAX, ou certaines règles d’ergonomie de base.
L’accessibilité, c’est pour moi “faciliter l’accès”, pour tout le monde.
Personnellement je suis Fred dans son combat contre les boutons RESET.
J’ai tout de même identifié 1 cas d’utilisation où le bouton RESET a une utilité : les formulaires où l’utilisateur est amené a ne faire QUE des modifications.
Par exemple vous passez une commande et le système vous propose de l’éditer quand bon vous semble. Lorsque vous l’éditez les valeurs par défauts ont une réelle signification et restaurer leur état initial peut être pertinent.
Bon j’avoue cet exemple est un peu tiré par les cheveux, un bouton “undo” permettant de revenir de façon incrémentale sur les modifications serait bien plus pertinente (voir un “reset” possible sur chaque champs individuellement).
Question bête : pourquoi les navigateurs ne prennent pas à leur charge ces fonctionnalités, plutôt que de coder du JS a gogo ? ;)
Il faut aussi avoué que la gestion des formulaires est relativement pauvre sans recourir au script (gestion des patern etc …) bon c’est une autre histoire ou un autre débat :D
Décidément, Fred n’a rien compris aux formulaires !
Il voudrait d’abord, nous faire remplir des cases vides… Pour ce faire, il faudrait cliquer, à coté de celles-ci, sur des étiquettes ? Il conviendrait ensuite, d’utiliser la méthode GET avec des adresses si longues qu’elles n’ont aucune chance de passer, puis, de généraliser les majuscules (ex : MARTIN à la 7ème étape !) comme sur feu l’annuaire des PTT ? Enfin, il voudrait interdire l’utilisation des resets !
La toile nous offre fort heureusement bien d’autres possibilités…
Alors prenons une form assez étroite pour que les inputs se superposent en une seule colonne et affectons leurs des valeurs par défaut : Votre nom, votre prénom… etc. Un onclick=”eff(this)” sera suffisant pour les effacer (avec la function eff(n){if (n.value==n.defaultValue) n.value=”;}). Ces valeurs par défaut pourront être utilisées lors du test pour vérifier que les champs obligatoires ont été au moins parcourus, mais surtout elles répparaîtront avec l’utilisation du fameux bouton reset alors bienvenu.
Plus besoin de labels, tabindex et autres complications inutiles. Un tel formulaire pourra être néanmoins servi à l’aide des tabulations et soumis avec la frappe de la touche Entrée (ici un onclick=”function(e){o=e?e.which:windows.event.keyCode;if (o!=13) return true;document.getElementById(‘frm’).submit();}” sera nécessaire).
Indépendamment de bien d’autres recettes, les meilleurs cuisiniers de la toile imaginerons sans difficultés les traitements à faire subir aux entrées afin de classer ou retranscrire les noms et prénoms, dans les formes les mieux adaptées, et ceci quelles que soient leurs formes et particularités.
Wow ! Alors là tu me la coupes Julien. Est-ce qu’il existe un formulaire en ligne qui fonctionne sur le principe que tu décris ?
/Fred
Je ne sais pas, mais cela va sans doute venir… Un errata cependant, ce n’est pas un onclick mais un onkeypress qu’il convient de prévoir dans le script pour soumettre le questionnaire à l’aide du seul clavier !