Quelle est la meilleure expérience utilisateur: mettre en évidence les erreurs ou bloquer les frappes erronées?
J'ai quelques informations à saisir dans une zone de texte. Les données sont structurées et seules certaines séquences sont valides. Pour un numéro de téléphone, par exemple, une lettre telle que A n'est pas valide.
Alors, dois-je intercepter les événements du clavier et empêcher les lettres tapées d'atteindre la zone de texte, ou dois-je dessiner des lignes rouges ondulées (ou un autre signal visuel) pour faire savoir à mon utilisateur que la lettre n'est pas acceptable? Quelle est la meilleure expérience utilisateur?
Remplacer le contrôle d'un utilisateur sur son ordinateur sera toujours une interruption, et souvent perçu comme une invasion, du flux de travail de cet utilisateur. Le site Web "n'est pas censé" avoir le contrôle de nos ordinateurs, donc exercer un tel contrôle sera au moins un peu alarmant.
Cela dit, vous abordez un sujet très important, à savoir faire savoir à un utilisateur que son entrée n'est pas valide avant de remplir un ensemble complet de champs et de les soumettre.
L'approche que j'ai trouvée la moins intrusive mais qui fournit la réponse la plus rapide est le flux ci-dessous.
Essentiellement, attendez qu'ils remplissent leur premier champ, puis lorsqu'ils cliquent/tabulent autour d'un nouveau champ (ou d'un champ qui a été invalidé), vérifiez le champ qui vient d'être rempli. Si le champ qui vient d'être rempli est valide, imprimez une icône discrète "bonne" à côté de lui (vert, coche, visage heureux, vous avez l'idée). S'il échoue aux règles de validation, imprimez discrètement une icône "mauvaise" (rouge, "X", etc.) et une courte ligne sur ce qui a échoué.
Mais n'oubliez pas, n'interrompez pas leur workflow:
- Pas de pop-ups
- pas de superpositions
Une fois qu'ils ont terminé avec le champ vers lequel ils ont déménagé, ils vont soit revenir au champ invalide, soit continuer et revenir plus tard. Dans tous les cas, ils verront qu'ils ont une modification à faire mais peuvent le faire à leur guise.
En fin de compte, ils auront un formulaire complètement valide avant de le soumettre, ce qui signifie
- Ils n'auront à soumettre qu'une seule fois
- Ils ne passent pas de temps à devenir fous ou frustrés lorsque leur soumission "échoue"
- Ils aimeront davantage votre site
- Tout le monde aura du gâteau
Étant aux deux extrémités de l'utilisation d'un formulaire, voici quelques lignes directrices que je préfère:
- Les contributions des utilisateurs ne devraient presque jamais être empêchées. Ce qui signifie que si je tape la lettre "A" dans un champ de numéro de téléphone, je m'attendrais à voir "A".
- Je commence ma validation de champ de texte sur un événement
onBlur(), et au plus tôt. Cela donne à l'utilisateur la possibilité de corriger ce "A" mal tapé avant d'afficher un message d'erreur. Permettre à l'utilisateur de corriger une erreur tout en restant dans le champ de saisie offre une chance de moins pour un type de message intrusif "hey, you messed up, mec".
Si vous empêchez les caractères non valides pendant leur saisie, ils pourraient potentiellement penser que leur clavier fonctionne mal. Les utilisateurs aiment que les choses fonctionnent comme ils le souhaitent. Si vous voulez empêcher certains caractères d'appuyer sur une touche, vous devez au moins afficher un message d'erreur près de l'entrée en même temps. De cette façon, ils savent pourquoi il ne tape pas.
Une autre chose qui peut devenir agaçante est lorsque vous venez de terminer de remplir un long formulaire et que le site utilise la validation côté serveur, vous devez donc parcourir le formulaire pour trouver ce qui ne va pas. J'aime utiliser la validation côté client principalement mais je me rabat sur le côté serveur. Je vais afficher une erreur soit lors de la frappe, soit lorsque l'entrée perd le focus. De cette façon, l'utilisateur sait immédiatement qu'il y a un problème et sait exactement quel est le problème.
Je trouve qu'empêcher les utilisateurs de faire des erreurs est toujours 10 fois plus difficile que je ne le pensais à l'origine. Exemple: le numéro de téléphone de quelqu'un peut avoir une extension, comme x2333. J'ai utilisé le plugin de masque de saisie jQuery pour les cartes de crédit et cela a bien fonctionné. J'utilise la suggestion automatique autant que possible.
Dans tout système complexe, vous aurez des circonstances coûteuses à détecter en ligne et vous devrez les informer après coup. Pour moi, la réponse est au cas par cas et assurez-vous de couvrir tous les cas Edge.
Je suggérerais un hybride des deux approches, mais uniquement pour les champs strictement validés comme les numéros de téléphone (SSN, codes postaux, etc ... tout ce qui doit être numérique par définition).
Suivez chaque frappe et, lorsque l'utilisateur tape un caractère non valide, affichez-le ... mais signalez immédiatement que quelque chose ne va pas. Tournez peut-être le champ de saisie en rouge et affichez un "Veuillez saisir uniquement des caractères numériques" à droite du champ.
Le blocage de l'entrée est un non-non car il peut être mal interprété par l'utilisateur. Ils pourraient supposer un problème avec leur machine ou périphérique d'entrée, non pas qu'ils n'étaient pas censés taper une lettre dans une zone de saisie numérique.
Valider après la saisie est terminée peut être ennuyeux. Notamment avec des champs comme ceux utilisés dans la création de mots de passe. Certains sites nécessitent des mots de passe à 6 caractères avec uniquement des caractères alphanumériques. D'autres nécessitent des mots de passe à 9 caractères et autorisent n'importe quel caractère (y compris! @ # $% Et autres). Taper un mot de passe et ne le découvrir qu'après avoir tapé c'est le type de formulaire le plus ennuyeux que j'ai trouvé et m'a en fait détourné de plusieurs services .
Fournir des commentaires dynamiques lorsque l'utilisateur saisit des données les aide
- Savoir quel champ avait l'erreur alors qu'ils sont encore sur le terrain
- Corrigez de manière proactive les erreurs de saisie avant de soumettre des données
- Apprenez de l'expérience au fur et à mesure
Le blocage de l'entrée échoue sur les 3 comptes. La mise en évidence des erreurs de validation une fois la zone de texte remplie échoue également sur les 3.
Cela dépend du cas. Si possible, utilisez la suggestion automatique. Si vous interceptez les commentaires de l'utilisateur, un retour immédiat est crucial. L'une des solutions possibles est la "boîte à indices" qui apparaît immédiatement après l'interception de la clé. Vous pouvez le voir sur l'écran de connexion de Windows, il apparaît si vous appuyez sur $ signe par exemple.
Comme pour la plupart des choses ... dépend du contexte. J'ai une vision plus spécialisée du sujet. La plupart des applications sur lesquelles je travaille, ou mon groupe, sont de nature technique et ne sont utilisées que par des personnes raisonnablement formées. En tant que tel, nous pouvons placer plus de responsabilité et de liberté entre les mains des utilisateurs que vous ne le pourriez avec le grand public. En bref, certaines des lignes directrices que nous utilisons ...
- Ignorez toute entrée invalide .... bloquez les frappes invalides.
- Indiquez les champs invalides, un état qui devrait être presque impossible, par contraste et couleur *.
- La mise au point est toujours sous le contrôle de l'utilisateur. Ne pas piéger l'utilisateur ou empêcher un changement de focus.
- Ne lancez jamais de boîte modale d'avertissement/d'erreur. Déjà.
- Ne posez jamais de questions à l'utilisateur. Le logiciel est un outil et non une personne. Oui je suis sûr.
- Les touches Entrée/Retour signifient toujours: Acceptez les modifications et continuez. Ne modifiez pas cela en utilisant le focus sur un bouton d'annulation/sortie comme valeur par défaut sur Entrée.
- La touche Échap signifie toujours: Supprimer et quitter.
- Fournissez l'auto-complétion chaque fois que possible.
- Fournissez une entrée de raccourci pour les chiffres qui ont une limite min/max. par exemple. Si une valeur valide se situe entre 0,12 et 100,387, les entrées supérieures à 100,387, comme 999, sont considérées comme 100,387, etc.
- Établissez des règles très claires en noir et blanc sur le comportement ... des règles que l'utilisateur peut comprendre. Si cela devient trop complexe ... repensez-le.
Presque tous les exemples sont demandés par les utilisateurs et, oui ... la mise en œuvre est parfois un vrai ours/cauchemar/tueur mais rarement impossible.
Mise en garde: Encore une fois, ces exemples sont donnés dans le contexte d'un système vertical avec une base d'utilisateurs techniques .... pas un formulaire grand public Web, etc. Votre kilométrage peut varier.
* Sauf rouge. Dans notre entreprise, le rouge signifie: vous pourriez être tué ... ou pire.