Vers une standardisation des champs de saisie typés ?

Il y a 6 ans (6 ans !) je vous parlais de la standardisation des formulaires à l’aide d’attributs date, number, range et email : Des formulaires standardisés. À l’époque il était question de XForms pour typer les champs de saisie. Aujourd’hui l’objectif est toujours le même, sauf que cette possibilité nous est offerte par HTML 5 et que ça se passe maintenant puisque si vous utilisez un navigateur moderne vous y avez déjà accès.

Le site 456 Berae St nous propose ainsi de faire le point sur les nouveaux attributs : HTML5 input types. Pour faire simple, il vous suffit de spécifier dans votre code source le type de données que vous voulez collecter (une date, un nombre, un email…) et le navigateur se charge d’afficher un champ adapté à la valeur à saisir. Cette technique est déjà employée avec brio sur les smartphones (cf. A propos des formulaires mobiles et narratifs) et l’on commence déjà à voir des choses intéressantes sur les navigateurs de dernières génération (Opera, Safari et Chrome).

Je vous invite donc à tester ces différents types de champs dans la page suivante : HTML5 input types test page. Voici à quoi ressemble un champ search dans Safari (coins arrondis comme dans le Spotlight de Mac OS et croix pour vider le champ comme sur l’iPhone) :

Un champ de recherche avec Safari

Un champ de recherche avec Safari

Voici à quoi ressemble un champ number avec opera (avec les deux boutons) :

Le champ number avec Opera

Un champ nombre avec Opera

Le champ range avec Chrome (dommage que la valeur ne s’affiche pas sous la glissière) :

Un champ range avec Chrome

Un champ range avec Chrome

Le champ email avec Opera (incluant un contrôle de surface):

Saisi d'un email avec Opera

Saisie d'un email avec Opera

Et pour finir le champ date avec Opera :

Saisi d'une date avec Opera

Saisie d'une date avec Opera

C’est ce dernier exemple qui m’intéresse particulièrement car la saisie d’une date ou d’un horaire est compliquée et qu’il y a beaucoup de différences dans les techniques employées. Standardiser le comportement des champs typés permettrait d’assurer de la cohérence au travers des différents sites et de réduire de façon considérable les erreurs de saisie.

Pour le moment il n’y a que la dernière version d’Opera qui implémente correctement les types mais nous ne devrions pas tarder à voir apparaitre ça sur les autres navigateurs. Deux types de champs pourraient grandement améliorer l’expérience utilisateur : Le champ tel pour saisir un numéro de téléphone (uniquement implémenté sur les smartphones) et le champ price pour saisir un prix (pas prévu pour le moment).

C’est un début encourageant et il reste beaucoup de travail mais nous sommes visiblement sur la bonne voix avec d’autres standardisation (notamment les pseudo-classes valid, invalid et required avec CSS3). C’est avec ce type d’améliorations que les navigateurs modernes vont pouvoir faire la différence vis à vis des vieux navigateurs qui sont plus lents, moins bien sécurisés et qui ne simplifieront pas la saisie des formulaires. Mais vous aviez déjà abandonné Internet Explorer depuis longtemps, non ?

A propos des formulaires mobiles et narratifs

Je termine une série d’articles sur la conception de formulaires avec deux sujets encore non-traités : Les formulaires pour terminaux mobiles et les formulaires narratifs.

Tout ce que vous avez besoin de savoir sur les formulaires mobiles est ici : Forms On Mobile Devices: Modern Solutions. Cet article est en fait un résumé d’une série de billets publiés par Luke Wroblewski sur son blog (Web Form Innovations on Mobile Devices et Better Mobile Form Design). J’ai eu la chance d’entendre ce fameux Luke en conférence lors du MIX et je peux vous assurer que son discours est parfaitement au point.

Dans son article il recommande ainsi d’exploiter au maximum les spécificités des interfaces des terminaux mobiles pour faciliter le travail de saisi dans les formulaires avec :

  • La fonction de zoom
    mobile_inputs_zoom
  • L’adaptation du clavier virtuel en fonction du format du champ
    mobile_inputs_formats
  • L’affichage temporaire du dernier caractère saisi dans un champ de mot de passe
  • Les menus contextuels pour la saisie de valeurs numériques
  • Les menus spéciaux pour la saisie de données complexes (comme la date ou la taille en pieds / pouces)
    mobile_inputs_date
  • L’adaptation de la mise en page en fonction de l’orientation de l’écran
  • L’utilisation d’éléments d’interfaces natifs qui sont livrés avec le système d’exploitation
    mobile_inputs_native
  • L’utilisation des composants hardware comme le micro, le GPS ou le compas.

Cet article est une véritable perle pour qui veut se lancer dans le développement de sites web adaptés au smartphones. Vous remarquerez que je ne fais pas référence aux applications mobiles ni aux sites web mobiles mais au cas bien particulier des sites web destinés aux smartphones (iPhone, Android, Blackberry, Palm, Windows Phone…). Il y a beaucoup de paramètres à prendre en compte dans ce contexte particulier car les différences de rendus peuvent être spectaculaires (comme en témoigne la dernière capture d’écran).

Si vous connaissez un article sur les meilleures pratiques de conception de formulaires pour sites web mobiles (à destination des feature phones) je suis preneur…

Changeons de sujet maintenant pour rebondir sur un autre article de Luke W qui traite des formulaires narratifs : Mad Libs Style Form Increases Conversion 25-40%. Pour faire court, les formulaires narratifs utilisent une mise en page complètement différente des formulaires traditionnels et privilégie une approche plus narrative : “Je suis … et je recherche … pour faire … à partir de …“. À découvrir par exemple chez Effduffer.

Dans les faits, ce type de formulaires transformerait mieux que les formulaires traditionnels, les équipes de Vast ont ainsi constaté une amélioration de 25% à 40% de leur taux de transformation sur le formulaire de contact :

vast_contactdealer

Des résultats surprenant pour une approche très originale. Assurément une piste à creuser…

Bonnes pratiques pour les formulaires d’identification

Avec la vague du tout social, chaque site (ou presque) propose une couche sociale, donc des comptes pour les utilisateur. Il en résulte l’omniprésence des formulaires d’identification que l’on retrouve un peu partout. Oui mais voilà, l’espace se fait rare et il ne reste plus beaucoup de place pour ce type de formulaire. Qu’à cela ne tienne, il existe différentes astuces pour palier à cette contrainte.

Le site Design Reviver nous propose ainsi une très belle collection de formulaires d’identification : 100 Outstanding Login Forms. De cette collection je retiens trois tendances :

  • Les sites qui affichent le formulaire directement sur la page d’accueil ;
  • Les sites qui affichent un lien ouvrant un panneau flottant avec le formulaire ;
  • Les sites qui affichent un lien menant vers une page spécialement prévu à cet effet.

Afficher les deux champs d’identifiant et de mot de passe sur la page d’accueil est la solution idéale, mais ça prend de la place là où vous en avez désespérément besoin. Utiliser un lien ouvrant un panneau est une très bonne solution de replie, mais cela pénalise les utilisateurs qui ont désactivé le javascript sur leur navigateur. Utiliser une page spécifique est encore mieux car cela ne pénalise personne et peut être combiné avec le formulaire de création de compte et les éléments de réassurance / incitation qui vont avec.

Des formulaires présentés, je retiens celui de Wordpress (simple et efficace) :

Le formulaire d'identification de Wordpress

Le formulaire d'identification de Wordpress

Dans le même style mais avec un peu plus de… style il y a celui de Tumblr (minimaliste mais cordial) :

Le formulaire d'identification de Tumblr

Le formulaire d'identification de Tumblr

Signalons aussi celui de Facebook (très faible encombrement) :

Le formulaire d'identification de Facebook

Le formulaire d'identification de Facebook

Notez au passage qu’avec des intitulés en français c’est tout de suite plus laborieux comme chez Ning :

Le formulaire d'identification de Ning

Le formulaire d'identification de Ning

Enfin mon préféré est celui de RedBrick Health avec un mélange de compacité et de sophistication :

Le formulaire d'identification de RedBrick Health

Le formulaire d'identification de RedBrick

Je serais bien incapable de vous sortir une règle d’or sur l’emplacement des intitulés de champs car il existe plusieures possibilités :

  • Au-dessus des champs ;
  • À gauche des champs aligné à gauche ;
  • À gauche des champs aligné à droite ;
  • Dans le champ.

Ces quatre solutions fonctionnent bien, c’est juste une question de place disponible.

Par contre je peux vous recommander les bonnes pratiques suivantes :

  • Localiser le formulaire ou le lien vers le formulaire en haut à droite de la page (là où se trouvera le nom de l’utilisateur une fois identifié) ;
  • Afficher un lien vers l’oubli de mot de passe ET d’identifiant ;
  • Prévoir un lien vers la création de compte ;
  • Proposer de retenir le mot de passe pour une durée fixe (2 semaines semble une convention) ;
  • Utiliser un cadenas pour symboliser la connexion sécurisée.

Voilà, si vous en avez d’autres, n’hésitez pas.

Avons-nous encore besoin des intitulés de champs dans les formulaires

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 :

Le nouveau formulaire de l'Apple Store

Le nouveau formulaire de l'Apple Store

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 :

Le formulaire de créatino de compte de FoodSpotting

Le formulaire de création de compte de 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 :

Le formulaire de création de compte chez LaunchMind

Le formulaire de création de compte 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.

Une autre étude sur la mise en page des formulaires

Les formulaires ont toujours été  au coeur de nombreux débats dans le petit monde de l’ergonomie web. J’ai d’ailleurs déjà eu l’occasion de m’exprimer à ce sujet sur ce blog. L’auteur de référence sur ce thème est pour moi Luke Wroblewski avec son livre Web Form Design: Filling in the Blanks.

Malgré quelques différents, les avis convergent tous grosso-modo vers un ensemble de bonnes pratiques bien résumées ici : Web Form Design Patterns: Sign-Up Forms. Une récente étude vient relancer le débat avec des conclusions tout à fait intéressantes et surtout des données statistiques issues d’un test d’oculométrie pour cautionner le tout : Web form design guidelines: an eyetracking study.

Les enseignements de cette étude sont les suivants :

  • La mise en page doit être verticale (pas de formulaires avec des champs sur deux colonnes) ;
  • Les intitulés des champs sont lus plus facilement s’ils sont placés au dessus ;
  • Certains champs peuvent être groupés sur une même ligne  (exemple : date de naissance en 3 menus déroulants) ;
  • La chapitrage des formulaires est mieux distingué si les intitulés de groupe ont un traitement graphique distinct (avec la balise fieldset) ;
  • Mieux vaut indiquer les champs optionnels plutôt que les champs obligatoire (cela réduit le “bruit” des caractères parasites) ;
  • Un seul champ suffit pour les numéros de téléphone ou les champs numériques complexes (mieux vaut passer par du reformatage : Vive les assistants de saisie pour les champs de formulaire) ;
  • L’aide contextuelle doit être la plus proche possible (généralement à droite du champ) ;
  • Le nombre d’étapes doit être clairement affiché.

Des enseignements très instructifs qui pourtant ne vont pas forcément dans mon sens (j’ai toujours été un fervent defenseur des intitulés de champs alignés à droite).

Jusqu’à très récemment mon formulaire favori était celui de Remember The Milk (cf. Le formulaire parfait) :

RememberTheMilk.jpg

Le formulaire d'inscription de Remember The Milk

Mais j’ai récemment découvert celui de Ballpark qui est plus sophistiqué :

Ballpark.jpg

Le formulaire d'inscription de Ballpark

Bien évidement c’est une affaire de goût puisque ces formulaires sont tous les deux très bons mais j’apprécie énormément le jeux des couleurs ainsi que les têtières des groupes. Et vous ?

Vive les assistants de saisie pour les champs de formulaire

Je ne le répèterais jamais assez : Les formulaires sont les bêtes noires des internautes. Surtout quand il s’agit de saisir des données avec un format bien particulier comme un numéro de téléphone ou une date.

Mais rassurez-vous car la situation est en train de changer grâce aux assistants de saisie qui sont décris ici : Input Masks Design. Le principe est révolutionnaire : simuler le formatage des données lors de la saisie.

Illustration avec une première technique de Masked Input Plugin (cliquez sur l’onglet “Demo“) :

Exemple de formatage de données en cours de saisie

Exemple de formatage de données en cours de saisie

Deuxième illustration avecle Dynamic Field Masking :

Deuxième e

Deuxième exemple de formatage de données en cours de saisie

Je trouve ce principe révolutionnaire car il permet une bien meilleure appréhension du format à respecter sans pour autant perturber la saisie.

Dans le même genre il y a aussi la correction orthographique sur les formulaires de recherche de Transport-IdF mais qui est bien plus perturbante car très dirigiste (ne fonctionne que sur certains navigateurs).

En tout cas cette nouvelle variante de la saisie assistée mérite largement que l’on s’y intéresse, surtout si elle se dégrade correctement pour les navigateurs non compatibles (à vérifier).

Cloudo et son formulaire de création de compte

Les formulaires de création de compte sont un grand classique du web. Exercice aujourd’hui bien maîtrisé (cf. Le formulaire parfait ?), il ne pose plus trop de problème. Et pourtant, les équipes de Cloudo nous propose une version encore améliorée avec notamment un système d’aide contextuel très performant :

Le formulaire d'identification de Cloudo

Le formulaire d'identification de Cloudo

Les points forts de ce formulaire :

  • Une vérification de surface des champs (matérialisée par la petite coche) ;
  • Un indicateur de “force” pour le mot de passe (plus ou moins dure à trouver) ;
  • Un petit rappel pour la correspondance entre les deux champs Password (la double flèche).

Rien de très révolutionnaire mais des petites attentions qui font plaisir aux utilisateurs et améliorent l’intuitivité et préviennent les erreurs.

L’ergonomie Web ou l’art du formulaire en ligne

L’architecture Web, l’ergonomie Web et la rédaction Web sont à considérer pour la création d’un formulaire en ligne. Afin de proposer une bonne expérience utilisateur, le formulaire doit proposer un contenu clair et précis et efficace. L’internaute doit également pouvoir y vivre une expérience utilisateur sans y perdre de temps.

Les principes de conception d’un formulaire en ligne

Afin de concevoir un formulaire en ligne à la fois claire, efficace et navigable, il faut marier adéquatement architecture Web et rédaction Web.

Voici quelques principes importants :

• Déterminer le public cible du formulaire en ligne;
• Déterminer la fonction du formulaire en ligne;
• Énumérer les informations présentées à l’utilisateur;
• Catégoriser les informations et effectuer un tri;
• Rédiger de façon claire et compréhensible;
• Dessiner une architecture Web pour le formulaire en ligne.

L’ergonomie Web d’un formulaire en ligne

L’ergonomie Web est essentielle pour une conception efficace et navigable d’un formulaire en ligne. L’ergonomie Web permet notamment à l’utilisateur de remplir facilement les champs de saisies.

Voici quelques règles à retenir :

• Créer un visuel efficace pour le formulaire en ligne;
• Faciliter la saisie de données en adaptant la longueur de la ligne;
• Si le formulaire est long, le présenter en plusieurs étapes (pages);
• Soigner la présentation des libellés;
• Permettre de revenir en arrière pour modifier ses informations;
• Résumer les informations saisies lors de la dernière étape;
• Afficher un message de confirmation à la toute fin du formulaire en ligne;
• Envoyer une confirmation finale à l’utilisateur par courriel.

Des tests utilisateurs sont conseillés, et ce, qu’il s’agisse de l’architecture Web, de l’ergonomie Web ou de la rédaction Web. Les tests utilisateurs permettront d’améliorer notamment la gestion des erreurs. En bref, des tests utilisateurs permettront de se rapprocher d’une expérience utilisateur réussie.

Pour conclure

Le formulaire en ligne demande une conception minutieuse. Étant souvent présenté dans un contexte transactionnel, il doit susciter la confiance de l’utilisateur. Sa conception doit être effectuée dans le respect des normes imposées par l’architecture Web, l’ergonomie Web et la rédaction Web. Un savant mélange des 3 augmentera ses chances de succès.

Afin d’en apprendre plus sur la conception d’un formulaire en ligne, nous vous invitons à consulter les billets de Frédéric Cavazza, Luke Wroblewski (fichier .PDF) et Jean-Claude Grosjean.

Billet initialement publié sur Mikimya

Ne mettez pas de bouton ‘Reset’ dans vos formulaires !

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…

/!\ Billet initialement publié sur FredCavazza.net.

Connaissez-vous la simplexité ?

Je vous propose de découvrir un concept qui me tient à cœur : la simplexité (contraction de simplicité et complexité). Pour faire simple, la simplexité est un art qui consiste non pas à simplifier un produit complexe, mais plutôt à rendre à priori simple un produit qui ne peut pas être simplifié sous peine de ne pas remplir sa fonction.

La première fois que j’ai entendu parler de ce terme c’était chez Renault où un réel effort est déployé pour améliorer le confort d’utilisation et la lisibilité des tableaux de bord (SVP pas de troll dans les commentaires). Mais cette notion s’applique à de multiples domaines comme le design (exemple ici : Quand les constructeurs de l’EGP misent sur le design), l’art (notamment avec des artistes comme Constantin Brâncuşi) ou encore le managment (Manager soyez dans l’art de la simplexité).

C’est d’ailleurs de ce dernier article que je tire une première définition : “Art qui consiste àrendre simple les choses compliquées et à vulgariser le monde dans le but de le mettre à la portée de tous“.

Appliquée à la conception d’interfaces web, qu’est-ce que ça pourrait bien donner ? Voilà ce que je vous propose : “Une interface à la simplicité apparente pour un service à la complexité induite“.

Illustration avec Gmail et son interface de rédaction d’un email : les options sont nombreuses (car c’est comme ça que les systèmes de messagerie fonctionnent) mais les équipes de Google ont trouvé l’astuce en masquant un maximum de choses.

Regardez bien cette copie d’écran, à gauche la version initiale (à l’ouverture de la page) et à droite la version complète (avec toutes les options déployées) :

Gmail1.jpgGmail2.jpg

L’impression de simplicité à l’ouverture de la page est réelle, par contre en cliquant sur différents liens on s’aperçoit que toutes les options sont bien là. Et voilà : simplicité apparent pour un service à la complexité induite.

/!\ Billet initialement publié sur FredCavazza.net.