Voilà plus de 10 ans que je conçois des sites web et plus de 10 ans que les formulaires sont une source de discussions sans fin pour savoir comment les optimiser (j’avais même publier un tutoriel en 2004). Alors que je pensais avoir trouvé LE formulaire parfait (j’hésite encore entre Remember The Milk et Ballpark), voici que l’Apple Store nous propose un formulaire d’achat qui risque bien de faire date : The Apple Store’s Checkout Form Redesign.
L’idée de génie est de proposer un formulaire où les intitulés sont directement dans les champs :
Cette solution permet de gagner beaucoup de place et d’afficher toutes les étapes du processus d’achat en une seule page (grâce à un principe d’accordéon). Le principe n’est pas nouveau mais c’est la première fois que je le vois mis en application sur un formulaire entier et sur une boutique en ligne à très forte fréquentation.
Il y a d’autres exemples de ce type de mise en page, notamment chez FoodSpotting :
Une solution particulièrement efficace mais qui n’est pas forcément meilleure que d’afficher les intitulés à gauche (ou au dessus) des champs, comme ici un très bel exemple chez LaunchMind :
Bref, ça m’embête de vous dire ça, mais il n’y a toujours pas de solution « ultime », tout reste une question de contexte, d’ambiance, de place disponible et d’intégration dans votre charte graphique. Plus d’exemples ici : Interface Design Inspiration | 30 Impressive Ways to Design Sign-Up Page/Form.
Il faut peut être voir là un rapprochement avec ce qui se fait sur Mac OS, dans le carnet d’adresse, depuis longtemps, où les nom, prénoms et autres champs sont présentés ainsi. De même sur l’iphone, les libellés sont à la place des champs tant que ceux-ci ne sont pas remplis.
Avec les divers technos disponibles, les interfaces sur le web tendent de plus en plus à rassembler à celle de nos OS.
Cela ne représente t’il pas un risque en matière d’utilisabilité ?
Une fois le focus fait sur un champ le libellé de l’information attendue n’est plus visible.
A moins d’être un poisson rouge, tu te souviens de ce que tu as lu il y a environ 2 secondes ! ?
Je n’ai pas vu se formulaire fonctionner mais par exemple, au moment du focus tu peux sélectionner l’ensemble du libellé qui sera donc effacé que au moment de la saisie. Et si efface tout ce que tu as saisi, le libellé est réaffiché.
Dans le genre pas très ergonomique pour un formulaire, la nouvelle version du formulaire pour la demande d’horaires des chemins de fer suisse (très bien, comparé à voyages-sncf au demeurant) :
http://www.cff.ch/
Je ne sais pas si on peut voir ce qu’ils avaient avant (les labels étaient en texte à gauche et les différents choix {gare, adresse …} étaient dans un menu à droite du champ).
En regroupant tout ils ont réduit la largeur nécessaire (la colonne de la case Horaire a réduit d’autant). Mais je ne suis pas convaincu du résultat.
Raphaël, je ne suis pas un poisson rouge. Mais ce « nouveau » système que l’on trouve notamment sur des sites comme ceux de +tuts ou de vendeesign, est particulièrement ennuyeux quand on revient sur le site comme lors de la saisie des commentaires !
Ce système est intéressant à condition qu’on puisse facilement retrouver l’intitulé du champs et/ou que le formulaire ne soit utilisé qu’une fois.
Pour moi, c’est clairement le point noir : comment retrouver le nom du champs (facilement ?) ?
« A moins d’être un poisson rouge, tu te souviens de ce que tu as lu il y a environ 2 secondes ! »
Ou à moins d’être aveugle… Si le texte disparaît au moment où l’on fait le focus, ça paraît peut-être un peu délicat d’utilisation pour une personne aveugle qui utilise un logiciel tel que Jaws qui « lit » la page.
Sinon, force est de constater que ça rend quand même la page plus claire et agréable, du moins pour ce qui est des formulaires de taille réduite et non critiques (on n’aimerait pas ne pas savoir si l’on a tapé son numéro de CB au mauvais endroit à la fin du formulaire).
Perso quand j’arrive sur un formulaire, j’aime bien que le focus soit sur le premier champ. Avec cette solution, ce n’est pas possible. On peut évidemment sélectionner le texte, mais on perd alors l’essence même du truc (cad faire joli…)
Et en ce qui concerne l’accessibilité des formulaires ? Il me semble que le label associé au champ est indispensable…
Insinuer qu’un internaute qui ne ne souvient pas de ce qu’il a fait « deux secondes plus tôt » est un poisson rouge, c’est mettre à la poubelle les notions de charge mnésique, et de mémoire de travail.
Notions d’autant plus importante sur le web, où l’internaute passe de page en page( avec des retours fréquents en arrière), et se retrouve à remplir des champs « presque » tout le temps identiques.
(Exemple: si les libellés des champs de saisie de commentaire « Nom », « Adresse e-mail » et « Site Web » étaient absents, nous supposerions leur rôle en fonction de leur ordre d’apparition.=
Donc, un petit conseil à Raphael Y : ne traitez pas vos internautes de poisson rouge. Mais, concevez pour des poissons rouges. Sauf si l’analyse utilisateur vous montre qu’aucun internaute poisson rouge ne fait partie de votre public cible.
Néanmoins, demeure le problème de la lisibilité. A priori, une fois le focus fait sur le champ, le libellé n’est plus visible.
Et donc, même pour les internautes à la mémoire plus grosse que les autres, le problème d’identification semble présent.
L’idée reste intéressante, sur le principe: réduire la quantité d’information affichée à l’écran (avant : champ + libellé, maintenant : champ libellé!). Peut-être que les effets secondaires de cette idée n’ont pas été évalués jusqu’au bout.
La question de l’accessibilité est effectivement pertinente. Je ne sais pas comment réagissent les différentes aides techniques fasse à ce type de formulaire. Est ce qu’elles lisent les champs préremplis ? Est ce qu’une balise « Label » peut être utile ?
@ Zackatoustra, Je ne traite justement pas les internautes de poissons rouges, ou je me suis mal fait comprendre. Jusqu’à preuve du contraire, les internautes étaient pour l’essentiel composés d’une population d’humain disposant de capacités cognitives avancées (Empan mnésique, effet de récence, divers mémoires…). Il faut donc s’appuyer sur ces capacités lors de la conception.
On remarquera d’ailleurs que l’organisation des champs reprend ce que l’on peut trouver sur les cartes de visites et les adresses postales, réutilisant ainsi les connaissances des utilisateurs.
@ Zackatoustra & Raphael Y. > Pas la peine d’invoquer les poissons rouges ou les capacités cognitives supérieures des êtres humains, une simple distraction peut te faire oublier ce que tu étais en train de faire il y a qq secondes.
@ Maxence > Tout à fait, que fait-on du focus sur le premier champ à l’ouverture de la page.
Bon… vos remarques sont valables, mais dans ma philosophie les règles d’accessibilité ne sont pas là pour alourdir les pages web. De plus, je pense qu’il est tout à fiat possible de mettre des intitulés dans le code source mais de ne pas les afficher.
/Fred
[…] Nous avons ici une grille de lecture beaucoup plus simple et de larges zones de respiration. Vous noterez le travail réalisé sur les choix typographique, sur la complémentarité des couleurs ainsi que les 3 illustrations. Autre particularité intéressante : le formulaire sans intitulés de champs (cf. Avons-nous encore besoin des intitulés de champs dans les formulaires). […]
Si l’on designe (pour une raison d’ergonomie et d’utilisabilité) ce genre de formulaire « condensé », m’est avis qu’un rappel mnémotechnique du genre de Culinary Culture peut éviter « le trouble mémoriel du poisson rouge » ou du moins apporter des repères simples pour éviter de se perdre : http://www.culinaryculture.com/#signup
Peut-être est-ce une solution rassurante dans ce système de champs-label…
Un tooltip au survol des champs qui ont « perdu » leur libellé minimiserait cet inconvénient.
Le gain de place de ce principe label/content me paraît aussi très très utile pour des applications de gestion web.
Je vais essayer…
1/ Un autre problème n’a pas été cité. Lors de la phase de validation, il est fréquent que l’internaute fasse une vérification de sa saisie.
Dans les deux premiers exemples (champs sans label) on peut vérifier les infos saisies, mais pas leur validité dans le contexte, c’est à dire : « quelles infos me demande de remplir l’interface ? ». Pour faire simple, est ce que j’ai bien rempli mon Nom dans la case Nom et pas dans la case Prénom ?
Les repères apporté sur http://www.culinaryculture.com/#signup sont un plus indéniable, mais on voit les limites : pictographier deux concepts proches (nom et prénom) n’ai pas aisé.
2/ D’autre part, l’affordance des champs de saisie est diminuée. En effet, un champ dans lequel on est invité à saisir des données doit être vide, sinon cela signifie qu’il est déjà rempli (et donc n’invite pas à l’interaction). C’est essentiellement pour cette deuxième raison que je bannis toujours les intitulés dans les champs.
Cette idée est valable pour les formulaires d’inscription mais en aucun cas pour les formulaires d’édition. Par exemple une fois inscrit, un utilisateur souhaite modifier son profil, cette méthode n’est plus adaptée dans la mesure ou les champs sont déjà remplis par les infos de l’utilisateur. Une bonne idée donc (quoi que pas nouvelle) mais une demi idée quand même…
Mmmh … Je viens de voir un script qui pourrait être entre ce que Frédéric nous propose et l’ancienne solution : http://www.csskarma.com/blog/sliding-labels/
Maintenant, il faut voir si c’est respectueux du SEO et autres mots complexes qui font baver certains.
[…] les plus notables, mais qui font encore débat, concernent les intitulés et la mise en page : Avons-nous encore besoin des intitulés de champs dans les formulaires, Et on reparle de l’emplacement des intitulés de champs de formulaire et Champs, libellés, […]