"Ne ressemble pas à un valide ..." contre "... n'est pas valide"
Je ne conçois rien pour le moment mais cette pensée m'est venue à l'esprit plus tôt. À votre avis, quels seraient les avantages et les inconvénients des erreurs de validation du libellé:
"Cela ne ressemble pas à un numéro de téléphone valide"
contre
"Le numéro de téléphone n'est pas valide"
Le premier message doit être donné comme un avertissement, pas comme une erreur. Dans certains cas, vous voudrez peut-être accepter quelque chose qui est probablement faux, mais très probablement pas. Par exemple, les préfixes de protocoles personnalisés pour les URL (comme chrome: //), les numéros de téléphone internes (qui n'ont pas 10 chiffres), les adresses e-mail qui ont exploré les profondeur complète des spécifications (y compris chaînes entre guillemets par exemple.)
Dans tous ces cas, je pense qu'il est juste de les avertir avec le premier message, mais permettez-leur de dire "je sais que ça a l'air faux mais croyez-moi sur ce."
Si vous refusez une entrée, il est préférable de préciser pourquoi, afin que les gens puissent la corriger.
Ce qui est mieux? Cela dépend de la rigueur des règles de validation . S'il y a des numéros de téléphone de cas Edge qui ne correspondent pas à un modèle général, et que l'utilisateur peut en fait envoyer avec succès le formulaire avec "c'est un numéro de téléphone mais ne ressemble pas à un", alors vous devez en tenir compte examen de la messagerie à fournir.
En supposant que vous n'avez pas réellement d'exigences restrictives pour l'entrée, les deux exemples de messages sont plus conviviaux.
Mieux encore, les messages d'erreur de validation fournissent une aide exploitable. Autrement dit, le message d'erreur fournit des instructions pour la validation au lieu de simplement signaler que quelque chose n'est pas valide.
Une des heuristiques d'utilisation de Jakob Nielsen s'applique ici:
Aidez les utilisateurs à reconnaître, diagnostiquer et récupérer des erreurs Les messages d'erreur doivent être exprimés en langage clair (pas de codes), indiquer précisément le problème et suggérer de manière constructive un Solution.
Par exemple: "Phone number: should be 10 digits and include the area code. Punctuation is allowed." (variez le message selon vos paramètres régionaux et vos exigences, bien sûr).
En outre, vous souhaitez mettre le nom du champ en erreur au début du message d'erreur pour mieux prendre en charge les lecteurs d'écran, etc.
Je pense que vous devez regarder ce que vous voulez que le personnage de votre application soit, puis déterminer comment les erreurs doivent être affichées.
Beaucoup d'équipes UX créent des personas pour leurs utilisateurs, mais ne prennent pas le temps de faire un persona pour l'application - est-ce convivial et informel, ou est-ce strict et professionnel? Penser à ces choses permet de déterminer quelle devrait être la bonne copie.
Ni l'un ni l'autre - dites à l'utilisateur ce qui ne va pas, comme l'a dit Erics. Si vous spécifiez le problème dans une version anglaise de ce pour quoi vous validez, cela indique clairement quel est le problème et n'est donc pas péjoratif à propos de l'entrée des utilisateurs.
"Le numéro de téléphone n'est pas valide" peut être incorrect - le numéro de téléphone peut être valide, mais pas acceptable dans cet environnement.
"Cela ne ressemble pas à un numéro de téléphone valide" - encore une fois, c'est subjectif. Je la préfère à la première, car elle implique au moins qu'elle peut être correcte, mais, comme l'a souligné Roger Atrill, l'implication est que l'utilisateur doit la vérifier, mais le système l'acceptera quand même.
"Le numéro de téléphone doit être composé de 10 à 12 chiffres, sans espaces, sans le code de numérotation international" ou similaire indique clairement à l'utilisateur dans quel format il doit saisir ce numéro.
Rendez-le simple , rendez-le stupide simple et rapide pour comprendre et récupérer à partir de l'erreur.
Je crois que l'option avec le moins charge cognitive (le moins de temps de traitement pour comprendre la phrase) serait la meilleure.
Ce dernier - "X n'est pas valide" - ne doit être utilisé que lorsque vous êtes sûr à 100% que les données sont erronées. Cela s'applique généralement aux restrictions "internes", par exemple si les noms d'utilisateur doivent comporter de 4 à 20 caractères alphanumériques. Vous pouvez dire en toute confiance lorsque l'utilisateur entre "mon! Nom d'utilisateur" qu'il n'est pas valide (contre vos restrictions; si vous devez autoriser les noms d'utilisateur avec des caractères alternatifs est une autre discussion).
Pour les données les plus courantes comme les noms, les adresses ou les numéros de téléphone, il y a toujours un cas Edge dont vous n'avez pas tenu compte. Ici, vous devez accepter n'importe quel format, mais il est utile d'afficher des avertissements aux utilisateurs en cas de faute de frappe.