Les écueils du contrôle de saisie dynamique

Le contrôle de saisie dynamique permet d’informer l’utilisateur de la validité de ce qu’il tape au moment où il le tape. En théorie, il est plus facile de corriger des erreurs lorsqu’elles apparaissent plutôt que d’attendre l’envoi du formulaire. En réalité, le contrôle de saisie dynamique pose plusieurs problèmes :

1. Interrompre l’utilisateur, c’est agaçant !

Pour les champs de saisie nécessitant un certain nombre de caractères, la saisie du premier caractère provoque une erreur. L’utilisateur est donc interrompu rapidement et fréquemment.

Afficher l’image animée décorative numéro 1

Nous pourrions attendre que l’utilisateur ait entré un nombre de caractères suffisant. Mais, dans ce cas, il n’aurait de retour qu’après avoir rempli le champ correctement, ce serait donc inutile.

2. Afficher un message quand l’utilisateur vient de sortir du champ, ce n’est pas le bon moment !

Il serait possible d’afficher un message lorsque l’utilisateur quitte le champ (événement onblur), mais c’est trop tard. L’utilisateur a déjà commencé à se préparer mentalement à remplir le champ suivant.

Pour s’aider à remplir un formulaire, beaucoup d’utilisateurs changent de fenêtres ou se servent d’un gestionnaire de mots de passe. L’utilisateur quitte alors le champ même s’il n’a pas terminé sa saisie, l’affichage du message d’erreur est cette fois prématuré.

Afficher l’image animée décorative numéro 2

Tabuler vers le champ suivant provoque une erreur dans le premier champ. L’utilisateur quitte alors le second champ afin de corriger l’erreur affichée dans le premier. Cela provoque une erreur dans les deux champs. Ça craint !

3. Ajouter des effets visuels, c’est perturbant !

Lorsqu’un champ passe de l’état valide à invalide, l’erreur apparaît puis disparaît. L’affichage de la page change donc plusieurs fois en très peu de temps, ce qui peut désorienter et poser des problèmes aux utilisateurs de souris.

Afficher l’image animée décorative numéro 3

Dans l’idéal, les messages d’erreurs devraient être cachés lorsque l’utilisateur commence à corriger le problème, soit tant que le focus est actif (événement onfocus), soit à l’appui sur une touche du clavier (événement onkeypress). Cependant, cela aggrave le problème.

4. Contrôler la saisie pour un regroupement de champs, c’est complexe !

Les groupes de champs doivent être traités de façon holistique. Prenons par exemple un groupe de cases à cocher. L’utilisateur doit choisir au moins deux options. Si l’utilisateur clique sur jaune et sort du champ, est-ce une erreur ?

Ou considérons le champ de date ci-dessous. Lorsque l’utilisateur quitte la boîte du jour, le champ est instantanément marqué comme invalide. On pourrait valider lorsqu’il quitte la dernière liste de choix, mais qu’en est-il, si, par exemple, quelqu’un laisse la première liste déroulante vide et tabule ensuite vers le mois ?

Concevoir un élément en partant du principe que l’utilisateur réalisera les actions dans le bon ordre n’est pas idéal. On pourrait valider ces champs lors de l’envoi, mais cela donne un faux positif à l’utilisateur qui a pris l’habitude de voir des champs validés de façon dynamique.

5. La validation côté serveur rend l’expérience incohérente :

Certaines actions de validation ne peuvent être effectuées que par le serveur lors de l’envoi du formulaire. Par exemple, la vérification des informations de connexion d’un individu. Certains champs seront donc validés de façon dynamique et d’autres après soumission du formulaire. Cette incohérence dans le comportement est perturbante.

6. Les faux-positifs, c’est déstabilisant !

Certaines implémentations utilisent le contrôle de saisie dynamique pour afficher des coches vertes lorsque l’utilisateur renseigne un champ correctement. Cette méthode peut donner l’impression d’une progression et permettre aux utilisateurs de ne pas se dire qu’ils doivent vérifier leurs réponses plus tard.

Néanmoins, la validation en ligne vérifie généralement le format. Un champ correctement formaté peut tout de même se révéler être erroné une fois envoyé. L’expérience utilisateur est alors erratique et désagréable.

7. Traiter les champs pré-remplis, c’est délicat !

Les champs pré-remplis posent un autre problème. Doivent-ils être affichés comme validés par défaut ? Dans ce cas, le message de succès doit-il être caché jusqu’à ce que l’utilisateur quitte à nouveau le champ ?

8. Plusieurs types de contrôles de saisie différents, c’est incohérent !

Certains champs peuvent être validés ou invalidés au fur et à mesure de la saisie de l’utilisateur. Par exemple, lors de la saisie d’une lettre dans un champ numérique. Cela dit, ce n’est vrai que pour une minorité de champs, le reste nécessitant d’autres processus de validation.

9. Cela ne saute pas aux yeux !

Beaucoup d’utilisateurs regardent leur clavier et non leur écran lorsqu’ils tapent. Dans ce cas, ils ne verront pas du tout l’erreur ou la remarqueront plus tard.

10. Faire jongler l’utilisateur entre deux actions, c’est casser son rythme.

Dans son article, « eIs Inline Validation Out? », Jessica Enders écrit que l’utilisateur doit sans arrêt basculer entre deux modes mentaux très différents : le remplissage d’un formulaire et la correction d’erreurs. Cela ralentit l’utilisateur, augmente l’effort cognitif, et, en général, diminue la satisfaction de l’utilisateur.

11. Indiquer la réussite, c’est déstabilisant !

Les tests de Luke Wroblewski (en anglais) ont prouvé que l’utilisateur ne savait pas comment interpréter une coche verte. Dans ses publications, il explique : Les participants savaient que nous n’avions aucun moyen de connaître leur nom exact, ils savaient ainsi que la coche verte ne pouvait pas signifier « correct ». Mais ils n’en étaient pas certains et c’était bien là le problème.

12. Problèmes pour les utilisateurs de lecteurs d’écran :

Lorsque quelqu’un se sert d’un lecteur d’écran, il peut vouloir parcourir tous les champs de formulaire pour se faire une idée de ce qui l’attend avant d’essayer de remplir chaque champ. Ceci peut entraîner des erreurs dans tous les champs avant que l’utilisateur n’ait même commencé son parcours.

En résumé

Le contrôle de saisie dynamique pose de nombreux problèmes et oblige l’utilisateur à passer du remplissage du formulaire à sa correction.

Les designers apprécient ce système parce qu’il évite à l’utilisateur de découvrir de nombreuses erreurs après avoir rempli un long formulaire. Si l’on part de ce principe, on peut tout de même :

• Supprimer les champs inutiles ;
• S’assurer que les champs sont bien compris et qu’ils comportent des instructions claires ;
• Faire en sorte que les messages d’erreur soient bien présentés ;
• S’inspirer de la méthode « Une page = une idée » (en anglais) ;
• Utiliser une méthode ne soulignant que les erreurs (en anglais).

Quoiqu’il en soit, développer l’expérience parfaite de contrôle de saisie dynamique relève de l’impossible. Les problèmes engendrés l’emportent sur les éventuels bénéfices. Laissez plutôt le contrôle à l’utilisateur en affichant les erreurs lors de l’envoi du formulaire.