Validation de champ de texte vs prévention
J'ai eu un débat (principalement avec moi-même) sur la meilleure approche pour traiter les entrées non valides dans les champs de texte - validation contre prévention.
En prenant un champ de texte numérique comme exemple, est-il préférable d'empêcher la saisie de caractères non numériques (permettant des cas spéciaux tels que signe, pt décimal, etc.) ou d'autoriser la saisie de quoi que ce soit, puis d'indiquer un message d'erreur (généralement lorsque le focus est laissé) si le résultat n'est pas valide?
La première approche est "ne permettez pas à l'utilisateur de faire quelque chose que vous savez être mauvais", mais présente l'inconvénient qu'il n'est pas du tout évident de savoir ce qui se passe si une touche du clavier est tapée et que rien ne se produit. Cela brise également l'attente selon laquelle, si vous tapez quelque chose dans un champ de texte, vous vous attendez à voir ce que vous avez tapé.
Dans le passé, je me suis généralement penché vers l'approche de prévention, mais en général, mais je pense peut-être qu'au niveau de l'entrée sur le terrain, l'approche de validation offre une meilleure expérience utilisateur. Quelqu'un connaît-il une meilleure pratique ici?
La prévention frustrera probablement un utilisateur lors de son entrée et cela ne fonctionne pas. Bien sûr, cela peut être corrigé avec une messagerie adéquate qui leur permet de savoir pourquoi certains caractères ont été rejetés.
Certains utilisateurs peuvent également taper tête baissée et ne pas voir quand certains caractères sont rejetés. S'ils tapent 10 caractères mais que seuls quelques-uns de ces raccourcis sont rejetés, ils ne le sauront peut-être jamais puisque leur tête est baissée.
En général, j'ai préféré la validation car elle permettait à l'utilisateur de voir son erreur. À mesure que vous obtenez des entrées plus complexes, il peut devenir plus difficile pour les utilisateurs de comprendre pourquoi certains caractères sont rejetés.
Empêcher l'utilisateur de faire quelque chose que vous savez être mauvais est jamais d'empêcher les frappes de touches dans une zone de texte. Il s'agit de supprimer la nécessité de taper complètement si possible pour cette entrée particulière.
Par exemple:
- Ne validez pas les dates dans une zone de texte, supprimez l'entrée de texte et utilisez un contrôle de sélecteur de date.
- Vous avez un nombre défini d'options standard où l'utilisateur en choisit une? Laissez l'utilisateur les sélectionner dans une liste déroulante/liste au lieu de taper. Si vous devez donner une entrée de texte libre en plus de cette liste, utilisez une option "autre" et autorisez seulement la saisie de texte.
Il existe de nombreux contrôles d'entrée de données différents qui ne sont pas des zones de texte. Assurez-vous de considérer toutes vos options avant de repasser pour la saisie de texte.
Il existe 3 solutions courantes à ce problème, et selon votre cas d'utilisation spécifique, un équilibre de 2 ou 3 d'entre elles est probablement le meilleur.
En règle générale ... donnez des commentaires tôt et souvent
Vous pouvez fournir à l'utilisateur des commentaires:
Avant la saisie
Écrire une copie succincte et communicative est une étape solide avant. Des info-bulles, des flux d'intégration pour les nouveaux utilisateurs et d'autres outils sont également à votre disposition.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Pendant la saisie
La vérification dynamique du contenu pendant saisie et la fourniture de commentaires sont également utiles. Dans votre cas, si vous préférez accepter les frappes, avertissez immédiatement l'utilisateur. De plus, comme avec le numéro de sécurité sociale ou une carte de crédit, vous pouvez automatiquement faire avancer les utilisateurs vers le champ suivant (en les aidant à se regrouper). Avec des entrées plus "compliquées", comme un e-mail, vérifiez la sémantique pour une correspondance dès que possible.
Après saisie
Valider le contenu après une soumission est généralement la plus frustrante pour les utilisateurs car ils ont dépensé le plus d'efforts. S'ils ont eu la difficulté de remplir un formulaire de manière incorrecte, ils répètent des actions triviales qui n'apportent pas de valeur. Dire aux utilisateurs qu'ils ont fait quelque chose de mal est préjudiciable au sentiment envers un produit, et cela est amplifié par la quantité d'efforts déployés.
Dans l'exemple ci-dessous, la notification que le formulaire n'a pas été rempli correctement aurait pu se produire avant ou pendant la saisie, plutôt qu'à la fin d'une série d'actions.
Je vous découragerais de ne pas autoriser certaines frappes, mais si la copie et les commentaires sont clairs, vous pouvez éviter le mal de tête dans la grande majorité des cas.
Ne pas empêcher (certaines) frappes car cela pourrait facilement dérouter et frustrer l'utilisateur.
Do fournissez une étiquette claire pour indiquer à l'utilisateur à l'avance quel type d'entrée serait valide.
Do fournir des commentaires de validation au fur et à mesure pour guider l'utilisateur s'il a entré une valeur non valide.
D'autres ont suggéré de ne pas autoriser les frappes du tout pour les dates et les champs numériques. Cela peut être approprié dans certaines situations, mais dans de nombreuses situations (la plupart?), Il est souvent plus rapide pour les utilisateurs de pouvoir naviguer dans un formulaire/une interface en utilisant uniquement le clavier, surtout si c'est quelque chose qu'ils utilisent régulièrement. Donc, si vous suivez cette voie, gardez cela à l'esprit et incluez peut-être la navigation au clavier dans l'interface que vous fournissez. Cependant, il peut être plus simple de simplement autoriser la saisie normale du clavier avec les suggestions ci-dessus, puis d'envisager d'offrir un moyen supplémentaire de sélectionner des valeurs (par exemple, sélecteur de date, liste déroulante, etc.) comme "raccourci" pour ceux qui préfèrent utiliser une interface souris/pointeur/tactile.