Quels boutons pour un formulaire / assistant ?
Je travaille en ce moment sur un projet de guide ergonomique dans lequel des recommandations doivent êtres faites quand à la présentation et mise en page des formulaires en ligne. Etant dans l’incapacité de me décider pour une solution ou une autre, je me permet de vous solliciter sur un problème bien précis :
Nous sommes dans le cas de figure où les utilisateurs doivent remplir un formulaire en ligne découpé en plusieurs étapes, une sorte d’assistant (wizard comme disent les anglo-saxons). A votre avis, laquelle de ces 4 propositions vous semble la plus claire, intuitive et posant le moins de problèmes d’interprétations :
Solution A :
Solution B :
Solution C :
Solution D :
Alors ? Votre avis ?
sebastien billard a dit :
Personnellement je préfére la solution B, qui est très proche des interfaces d’installation de logiciels par exemple (enfin sur windows).
Mon second choix est la A. C et D sont très peu intuitifs AMHA
HTH
Sebou San a dit :
hello pour moi la solution B est la plus clair: - étape précédente et suivante ont la meme taille - abandonnez reste discret mais visible
seb
François Palaci a dit :
Je trouve également que la proposition B est la plus claire. Elle présente l’avantage par rapport aux trois autres propositions de bien mettre en évidence le fait que le formulaire comprend plusieurs étapes. Ca devrait aider l’utilisateur à se repérer plus facilement.
solo a dit :
La B
arnauld mascret a dit :
Je préfère également la solution B qui me semble plus agréable que la D grâce aux flêches et au texte inscrit ( de plus la notion de validation n’apparait pas ce qui conforte dans la possibilité de revenir en arrière). Sur la solution D je préfère le bouton annuler au lien “abandonner tout” des autres qui correspond mieux aux IHM habituelles.
kangoo a dit :
“B” comme tout le monde, mais je n’aime pas la notion d’abandon. Je trouve cela traumatisant pour l’utilisateur.
Pourquoi pas “tout recommencer“ ? (la perspective d’un nouveau départ est plus enthousiasmante que celle du renoncement par l’abandon)
kangoo a dit :
ou “revenir à…“, mais pas “tout abandonner” svp. :]
LapinLove404 a dit :
La B aussi…
Le terme “étape” me semble meilleur que la notion de “validation” (qui, comme ca a été déjà dit, donne une impression de non-retour)
Tout abandonner me semble aussi un mauvais terme. “Annuler” a l’avantage d’être moins négatif et d’être déjà utilisé à beaucoup d’autres endroits…
vincent a dit :
Ravi (pour une fois) d’aller à contre courant en proposant plutôt la A. La B revient à mettre sur un pied d’égalité le fait d’aller à la suite ou de revenir. Selon moi 90% des utilisateurs vont aller à l’étape suivante, donc pourquoi ne pas mettre le suivant en valeur tout en laissant quand même la possibilité de revenir en arrière. Application dans Internet Explorer (heureusement que je l’ai encore au boulot pour vérifier ça) : le bouton précédent est plus gros que le bouton suivant (moins utilisé). Néanmoins en choisissant la B on se rassure l’utilisateur en lui proposant un standard plus répandu (Cf commentaire de Sebastien).
Emeric a dit :
Bonjour,
Fred, as-tu regardé comment font les gros acteurs du marché, en matière de commande en ligne ? Amazon, la Fnac, cdiscount, pixmania ?
Je pense qu’il serait bon de s’inspirer de leurs modèles, d’abord parce qu’ils reflètent une expérience et une recherche déjà effectuée, mais aussi parce qu’il font office de standards et que les utilisateurs sont plus susceptibles d’être habitués à leurs procédés.
Sinon, si je devais choisir parmi les propositions ce serait la B, mais je lui trouve quand même quelques défauts :
1°) le terme “Abandonner tout” n’est pas clair. S’il s’agit d’une commande, par exemple, je mettrai “annuler la commande”. Il faudrait éclaircir le “tout”.
2°) L’accès à l’étape précédente est clair, mais peut-être qu’il serait plus confortable pour l’utilisateur d’avoir une sorte de rappel des étapes effectuées et une possibilité de les modifier directement. Ex : Modifier les infos de l’étape 2 sans passer par la 3 quand on est à la 4.
Je crois que le calcul des APL sur le site de la CAF offre cette possibilité :
un autre Vincent a dit :
Bonjour,
Pour être franc, rien ne me convient… Peut-être qu’un mélange de la solution
Aet de laDserait pratique :Dparce que, pour moi, la fonctionAnnulerouAbandonnerfait partie intégrante du formulaire et est une validation ;Bainsi que les termesÉtape précédente,Étape suivanteavec, tout de fois, la même remarque que Vincent pour la grandeur de celles-ci.Bon, cela reste un avis et les .
(Pour titiller inutilement ; la belle barre d’outil WYSIWYG n’est pas trop une barre d’outil WYSIWYG justement ;p)
Fred a dit :
En fait Emeric, les poids lourds du commerce en ligne utilisent une solution que je juge trop radicale : un seul bouton “Continuer” avec la possibilité de modifier sur la page finale de récapitulation avant confirmation définitive.
/Fred
vincent a dit :
Encore peu répandus, les formulaires en flash qui dialoguent avec une base de données (cf le vu et revu exemple de reservation de chambre d’hotel, dont j’ai plus l’adresse sous la main). L’avantage est qu’on est pas obligé de recharger la page, de changer de page, etc… Peut être en 2007 ?
Laurent Denis a dit :
Instinctivement :
Solution A de préférence (a priori, c’est le lien “valider et continuer” que je vais chercher à atteindre le plus souvent. En cas d’erreur, il me faudra un peu plus d’attention pour trouve le lien de retour en arrière, mais c’est un effort qui sera tout à fait de circonstances). Sinon B.
Dans C, je vais confondre “Annuler” avec “Abandonner” et je ne vais pas y voir un moye de revenir en arrière.
D me semble visuellement confus.
Patrice a dit :
Tout pareil. B aussi en premier choix et D sinon. D est assez “exotique”, il risque de faire peur à M. Tout-le-monde…
Julien a dit :
Personellement, je suis plutôt la réponse A mais tout est question d’avis et d’habitude.
Philippe a dit :
Ma solution préférée serait de copier les interfaces d’installation des applications windows auxquelles les utilisateurs sont habitués :
<Retour Continuer> Annuler
Cela se rapproche de la solution D. Je crois aussi me souvenir avoir lu le même conseil dans un article qui parlait des normes d’IHM (malheureusement, je ne le retrouve pas).
Frédéric a dit :
Bonjour,
Je me permets une petite remarque. (J’utilise SPIP pour mon blog et il me permet de répondre à une réponse de message, ce qui est très pratique pour savoir qui répond à qui). Dommage j’avais une très bonne opinion de dotclear jusqu’à présent … Aie, en plus le saut de ligne dans SPIP est géré automatiquement !
Réponse à Vincent : Il est tout à fait possible de construire grâce au javascript et CSS, un formulaire “tout compris” style flash. Ce n’est pas une question de technologie.
Réponse à Fred Cavazza : Pourquoi s’embêter à choisir ? En matière de web, le nombre fait le standard. Il suffit de voir ce que font les autres.
Fred a dit :
, certes mais cela est à relativiser en fonction du contexte :
Reste à savoir si le formulaire en question correspond plus à un contexte de commerce en ligne ou d’application en ligne. Je n’ai toujours pas la réponse…
/Fred
laure a dit :
solution A : chacune des étapes va être validée individuellement (”valider”.. pas de possibilité de modifier)
solution B : on remplit chaque page, et on valide / termine le tt à la fin… un peu comme amazon, mais avec une possibilité de revenir en arrière pdt la transaction.
Pour un wizard, je pencherais moi aussi pour le B (suivant, suivant, suivant, terminer de windows).
Emeric a dit :
L’ennui avec la solution A, c’est la proximité du lien “annuler tout” et “retour en arrière”. L’erreur de clique coute cher en temps et patience.
Martine a dit :
Bonjour,
en tant qu’utilisatrice de base, je préfère les textes bien explicites, donc je suis pour un mixte des solutions A et B :
en dessous le lien “abandonner tout” tout seul pour qu’il soit bien visible
gou a dit :
Hummm… j’aime bien le défi.
Je dois dire, avant tout, que je trouve très originales les solutions C et D avec des boutons de taille plus imposante. Efficace? difficile à dire comme ça, mais l’idée est vachement intéressante… je vais y penser…
Pour ce qui est de la solution que je privilégie… j’hésite. Parfois la A, d’autres fois la B et, pourquoi pas, la d? ça dépend vraiment du contexte.
Si c’est vraiment un Wizard, la version A me plait, mais j’y ajouterais un indicateur d’étapes. Cet indicateur pourra alors servir deux fonctions: le retour en arrière et le suivi du processus. Un bouton annuler devrait être présent en tout temps.
Si on parle d’une application avec de grands formulaires, un bouton «enregistrer» peut être nécessaire pour permettre de conserver les données partiellement en cours de travail.
M’enfin… peut-être que je me casse la tête…
fablog a dit :
Tout simplement la B.
^fabrice^^ a dit :
Avant et après lecture des commentaires, c’est B !
Avec peu être, comme c’est évoqué dans un des commentaires, la liste des étapes (passées, présente et à venir).
lotof a dit :
Tout simplement la B
Patrick a dit :
B c’est bien…
(explosion de commentaires
Matthieu FAURE a dit :
Quelques remarques en vrac:
Enfin, voici mes impressions au “premier coup d’oeil” (comprendre à l’instinct):
Voilà, en espérant que cela te soit utile
stephane a dit :
Je vote A.
Amélie a dit :
B? (héhé)
avec peut-être une distinction de format entre étape suivante et précédente (en plus de la situation, du sens de la flèche et du texte), par exemple une couleur ou une différence de taille
indication de l’étape courante (exemple 2/4), et selon le contexte du thème de l’étape suivant (exemple paiement)
idem emeric pour “abandonner tout”: contextualiser le terme, et éventuellement utiliser annuler au lieu d’abandonner
JCG a dit :
Salut,
Personnellement, je partage l’un des derniers commentaires: un indicateur d’étapes situé en haut de page indiquant l’étape en cours, les étapes passées et ce qui suit me paraît nécessaire. A toi de voir son look et ensuite, si tu te sers de cet indicateur comme un simple outil de repérage ou comme un outil de repérage et de navigation (ça complique les choses ;les utilisateurs ne le comprennent pas forcément et ne l’utilisent pas toujours ! vu en test !)
En ce qui concerne les boutons, la solution D correspond en partie à ce que j’ai déjà préconisé dans le passé pour les écrans (étapes) de saisie. Toutefois, je garderais les mêmes dimensions de boutons et remplacerais > par … derrière Continuer.
Je dis en partie, car évidemment sur la 1ère étape de saisie, je ne mettrais pas de “Précédent” ou “Retour” mais simplement un “Annuler”, et sur un écran récap., je remplacerais “Continuer” par “Envoyer” (ou un équivalent “Valider”).
Comme tu peux le constater, l’ensemble va varier selon moi en fonction du nombre d’étapes de saisie, du nombre d’écran, du fait que tu proposes ou non un récap et du type de feedback système. Sans parler du contexte de l’application, des tâches utilisateur et des transactions en jeu … car le modèle B par sa simplicité est trés “utilisable” dans certains contextes.
A bientôt,
JC
frederic a dit :
et oui fred tu as le réponse depuis le début,solution a pour du e-commerce et solution b pour une application plus administrative, pour moi il faut eviter le terme abandonner, reprendre depuis le début me parait mieux ou un truc du style.
solution d et c definitivement non ( et oui je suis assez classique)
Natacha a dit :
Comme Martine je propose un mixte des solutions A et B :
- à gauche la grosse flèche bleue avec “retour à l’étape précédente”
- à droite la grosse flèche bleue avec “valider et continuer”
- en dessous le lien “abandonner tout” tout seul pour qu’il soit bien visible
Des choses simples et limpides
SoWhat a dit :
Quel plaisir de voir tant d’interet pour une ergonomie de dialogue….oui oui GOU ça vaut la peine de se casser la tête. Pour votre plaisir regardez ce qu fait M. David Lynch…http://patricklynch.net/
Denis a dit :
Tous les éléments pertinents ont été apportés il me semble. J’opte aussi pour la proposition B.
katsoura a dit :
Je vote B. Les deux flèches indiquent clairement, même sans lire son intitulé ce que je peux faire: aller en avant et en arrière. Contrairement à Laurent, je dirais que la flèche retour rassure le visiteur qui sait qu’à tout moment il peut revenir en arrière. Ce procédé est utilisé également pour l’installation de logiciel.
Par contre le mot “abandonner” est trop péjoratif. Il s’assimile à “baisser les bras” qui pourrait signifier “être incapable de”.
Bed a dit :
Bonjour,
Comme quoi une question a priori anodine peut provoquer des réflexions intéressantes.
Personnellement je suivrai l’avis général et, dans le contexte d’une application, je choisirai l’option B en reprenant les propositions d’adaptations suivantes :
Pöur aller un peu plus loin, et au risque de peut-être rendre l’interface un peu moins claire, je propose également de :
Bien à vous.
Fred a dit :
Oui Bred, ton intention est louable, mais est-ce que cela ne fait pas un peu trop de boutons ? Rappelons que nous sommes en train de parler des boutons qui viennent en plus des éléments du formulaires (champs, cases à cocher, boutons radios…).
N’y a-t-il pas dans tes propositions un risque de surcharge cognitive (trop de choix) ? Encore une fois, je ne connais pas de solution miracle (sinon je n’aurais pas demandé l’avis des lecteurs), mais je préférerais privilégier la solution où les utilisateurs sont sur des rails : ils se concentrent sur les questions du formulaire.
/Fred
Jean-François Paquerot a dit :
Salut Fred,
De mon coté, je préfère la D :
-JF-
Fred a dit :
Merci JF pour ce choix, c’était ma proposition à la base
/Fred
Wolf a dit :
La D car elle suit les process d’install des applications windows
De plus des elements de même niveaux doivent etre representé de la même maniere
Donc adios les liens de A B C
-Ces liens ont ils un rapport avec mon action en court ???
-Pourquoi sont ils representés differements ??
herve a dit :
et pourquoi pas un formulaire en une seule page ! avec boutons de deplacement dans les pages et ascenceurs faute de quoi : solution B
pom a dit :
J’aime bien cette problématique d’un processus par étape.
Je pense que la solution D est claire. On pourrait cependant y ajouter un nouveau bouton, qui serait “Finish”, qui permettrait éventuellement de finir tous le processus sans forcément passer par des étapes postérieures.
Cette possibilité est par exemple offerte dans Eclipse, quand vous voulez créez un projet. Ce bouton est “grisé” tant qu’il n’a pas assez d’informations pour créer un projet, mais dès lors qu’il a les infos minimales, on peut finir le processus (et éventuellement le reprendre plus tard).
Une idée qui est bonne, si vous voulez tenir compte de l’élément “vitesse” de remplissage de formulaire chez un utilisateur.