Quand et comment valider les formulaires dans une perspective d'utilisabilité?
J'implémente une application métier et j'enroule quel est le meilleur moyen de valider les formulaires et quand.
Un exemple est un formulaire où trois champs de texte où un montant en devise est attendu. Une entrée valide est de la forme D.dd où d est un chiffre et D est un ou plusieurs chiffres.
Quand valider?
Lorsque l'utilisateur tape (par exemple, valider l'entrée après chaque caractère est tapé). Un problème se pose si l'entrée doit être dans un état non valide avant d'être valide.
Lorsque le focus du champ de texte est perdu.
Lorsque les utilisateurs appuient sur le bouton soumettre.
Comment valider?
Empêcher la saisie de caractères "invalides", par exemple lettres dans un champ numérique ou monétaire.
Afficher une indication d'erreur (par exemple une bordure rouge ou afficher la valeur d'entrée en couleur de texte rouge).
Empêchez l'utilisateur de déplacer le focus (il est important que la valeur par défaut soit valide dans ce cas) et affichez une indication d'erreur.
Ma solution actuelle consiste à avoir une valeur par défaut valide, par exemple 0.00 pour la devise et 1 pour la quantité. Et empêchez les lettres d'être tapées dans les champs de devise et de nombre. Parfois, l'entrée doit être dans un état non valide, donc je ne valide que lorsque le focus quitte le champ. Si la valeur n'est pas valide, je garde le focus et affiche une indication. Un champ vide sera rempli avec la valeur par défaut. Mais je ne sais pas si c'est une bonne pratique d'utilisation.
Une solution consiste à attendre un période d'inactivité dans ce champ de formulaire (disons 1 seconde) avant de le valider. Bien sûr, vous devez également valider dès que le focus est déplacé.
Empêcher la saisie de caractères invalides n'est pas une bonne idée si la personne qui tape n'a aucune indication claire pourquoi ce caractère ne fonctionnera pas. Montrez plutôt une erreur de validation pour le champ qui explique le problème. Quelque chose comme "Veuillez ne pas utiliser de chiffres". Une exception est quand c'est très clair. Quelque chose comme $ _ indique clairement que je recherche un nombre. Que vous en ayez besoin sous forme D.dd (comme vous le suggérez) est une autre histoire. Si je dis 1 $, 1,0 $ ou 1,00 $, vous pouvez raisonnablement supposer que je parle d'un dollar. Si c'est clair pour vous, ne forcez pas quelqu'un à remplir selon votre format juste parce que c'est comme ça que vous le souhaitez. Laissez les ordinateurs faire ce travail.
Il existe plusieurs façons d'indiquer des erreurs. L'une des plus courantes consiste à modifier le arrière-plan ou couleur de la bordure du champ, et un autre affiche une erreur icône à droite du champ. Seuls les tests permettront de déterminer ce qui convient le mieux à vos clients compte tenu de votre conception.
N'empêchez pas quelqu'un de se concentrer. Il est ennuyeux et a une très faible découvrabilité pour expliquer pourquoi le focus ne peut pas être déplacé. Laissez les gens remplir le formulaire dans l'ordre qu'ils souhaitent. Vous pouvez toujours empêcher le formulaire d'être soumis si quelque chose est omis.
Il y a un problème majeur avec la validation au niveau des caractères, ce qui n'est pas suffisant. Si vous faites cela en utilisant javascript, comme je le suppose, vous devez également valider lorsque les données sont présentées à l'arrière-plan du code, car l'utilisateur peut désactiver javascript.
Il est donc devenu plus courant de valider lors de la soumission - et de faire la même validation aux deux extrémités (à peu près). Cela a également l'avantage de prendre tout ce qu'ils ont entré et de le valider à la fois - afin que toutes les dépendances puissent être effectuées ensuite.
Et le valider seulement une fois qu'ils ont rempli un champ au moins, signifie que toutes les valeurs saisies peuvent être vérifiées pour savoir si elles sont éventuellement compatibles.
Je n'utiliserais pas seulement des commentaires sur des entrées incorrectes, mais montrerais également ce que fait l'entrée, le cas échéant. C'est un bon moyen d'éviter les problèmes d'internationalisation.
Donc, si vous avez des dates, ne vous contentez pas de rejeter certains formats, mais affichez la date analysée à côté. Si vous tapez 10/02/11 show 'Sun, October 2, 2011' à côté de lui, il n'y a donc absolument aucun moyen de le mal interpréter comme le 10 février. symboles de séparation.
Les moyens non invasifs de fournir une rétroaction doivent être utilisés en premier (indiquant les problèmes lors de la frappe ou lors de la suppression de la mise au point), mais ils ne doivent pas trop bloquer et ne pas empêcher de déplacer la mise au point.
La validation sur (ou avant) la soumission pourrait être plus bloquante: ne pas soumettre jusqu'à ce que les problèmes soient résolus. Je ne sais pas si les utilisateurs préfèrent un bouton d'envoi désactivé jusqu'à ce que le formulaire soit correctement rempli par rapport aux messages d'erreur lors de la soumission ou vice versa. Mais si vous désactivez le bouton d'envoi, vous devrez peut-être indiquer pourquoi près du bouton (et pas seulement près des champs incorrects), en particulier sur les formulaires plus longs.
Ensuite, validez également lors de l'acceptation, car la validation côté client n'est jamais sûre, et fournissez également des informations précises à l'utilisateur dans ce cas.