web-dev-qa-db-fra.com

Quel est le comportement préféré de la validation de formulaire?

Quel est vraiment le comportement préféré de la validation de formulaire? Quand la validation doit-elle avoir lieu?

  • Lorsque l'utilisateur clique sur "enregistrer"
  • Lorsque le champ de saisie n'est pas net
  • Au fur et à mesure que l'utilisateur tape

La méthode préférée est-elle la même pour les formulaires longs et courts, les assistants, etc.? Qu'est-ce que tu penses?

(Le formulaire sera sur la plate-forme de bureau uniquement)

36
efrethe

Généralement,

La manière dont la validation doit être implémentée varie en fonction des besoins uniques du formulaire. Cependant, en général, si la saisie de l'utilisateur est incorrecte, le système doit informer l'utilisateur en fournissant un message identifiable et clair qui aide à corriger l'erreur.

de https://www.nngroup.com/articles/indicators-validations-notifications/

Plus précisément,

Le bon moment pour informer sur le succès/l'échec des données fournies est juste après que l'utilisateur a soumis les informations. La validation de formulaire en ligne qui informe immédiatement les utilisateurs de l'exactitude des données fournies entraîne une augmentation du taux de conversion.

de https://designmodo.com/ux-form-validation/

Travaillant beaucoup avec les formulaires, je pense que le moyen le moins ennuyeux est de le faire lorsque le champ de saisie est flou jusqu'à ce que l'utilisateur corrige l'erreur .

  • Lorsque l'utilisateur clique sur "enregistrer" => Il est un peu trop tard pour la validation
  • Lorsque le champ de saisie n'est pas net => C'est juste le bon moment
  • Comme l'utilisateur tape => il est un peu trop tôt pour la validation

Twitter a tout à fait raison

Twitter

37
Dimitra Miha

La validation doit être effectuée par champ de saisie:

  • lorsque l'utilisateur a fini d'entrer sa réponse : lorsque le champ est focalisé ou après un délai spécifique que vous considérez que l'utilisateur a fini de taper (comme suggéré - ici )
  • tandis que sur le focus, les informations saisies ne sont pas validées et les caractères supplémentaires ne feront pas avancer la validation : par exemple, l'utilisateur entre un caractère invalide qui a gagné pas faire la validation de la passe de champ
4
Alvaro

Éditer:

Pour les formulaires critiques tels que Connexion, Transactions en ligne, fournissant tout type d'informations , il est nécessaire d'utiliser des validations de serveur via https qui s'exécuteront lorsque les utilisateurs cliqueront sur Envoyer. bouton.

Pour les validations au niveau du champ telles que le courrier électronique, le tél, le numéro , nous pouvons tirer parti des validations côté client, mais avec un repli pour les navigateurs qui ont désactivé JavaScript;


validations côté client natif a lieu lorsque la condition est remplie/comme le type d'utilisateur.

Examen des nouvelles valeurs dans l'attribut de type <input type="email" />,

et le meilleur implémenté dans presque tous les navigateurs Attribut Pattern <input type="tel" pattern="^\d{4}-\d{3}-\d{4}$" >

Nous rencontrons des validations de formulaire lorsque les types/conditions utilisateur sont remplis [ Validations de formulaire côté client HTML5 ]. Le programme/code n'envoie pas de demande au serveur pour valider les informations, les navigateurs s'en chargent .

Exemples:

enter image description here

enter image description here

enter image description here

4
DPS

L'utilisateur doit être informé d'une erreur le plus tôt possible, dans tous les types de formulaires (assistants, formulaires longs, etc.).

S'il est possible de donner un retour d'erreur pendant que l'utilisateur tape, alors faites-le. Cela permettra à l'utilisateur de corriger son erreur plus efficacement, car le curseur et son esprit se trouvent sur le sujet de l'erreur.

Je dois souligner la différence entre informer l'utilisateur d'une erreur et arrêter l'utilisateur. L'utilisateur peut être informé d'une erreur pendant qu'il tape, mais il ne sera pas arrêté jusqu'à ce que le formulaire soit soumis ou que le champ soit flou. Le moment où arrêter l'utilisateur dépend de la gravité de l'erreur, du cas d'utilisation du formulaire, du type du formulaire et de nombreux autres facteurs.

Tout d'abord, vous devez essayer de éviter les erreurs, c'est-à-dire en utilisant des zones de liste.

3
DesignerAnalyst

Donnez votre avis pendant que vous restez concentré

Il s'agit d'un équilibre délicat, comme l'indiquent les réponses ici. Informer l'utilisateur après avoir rempli le formulaire (comme certaines applications/sites le font encore) interrompt le flux.

Évitez de briser leur concentration

Vous créerez moins de frustration et réduirez la charge cognitive si vous suivez un principe "juste à temps" consistant à informer progressivement tout au long du formulaire. Ceci est généralement appelé validation en ligne.

Vous souhaitez les informer:

  • Alors que le domaine est toujours au centre
  • Après qu'ils pensent ils ont quelque chose de significatif entré
  • Avant de se concentrer, la prochaine chose

Devinez et testez

Le hic avec des informations juste à temps est que vous ne pouvez pas être entièrement certain lorsque l'utilisateur a fini de taper/penser.

Trop tôt et vous cassez leur concentration sur le terrain en question.
Trop tard et ils sont déjà sur le suivant. Focus brisé à nouveau.

Faites une supposition éclairée sur le focus + typing + pause délai, puis testez-le en action. Testez avec un prototype et continuez à surveiller vos métriques (abandon de formulaire, erreur de saisie) en production. Affinez lorsque vous atteignez le juste milieu.

2
plainclothes

Aie. Au début, j'étais convaincu d'une option. Mais en réfléchissant plus attentivement, la réponse, à mon avis, est dépend, et tous les.

1. Dépend du champ de saisie

une. En tant que types d'utilisateurs

Il existe différents types d'entrées et certaines entrées nécessitent une validation différente.

  • Un mot de passe peut être validé en tant que type d'utilisateur. Si votre site n'accepte pas par exemple de simples mots de passe comme "123" qui pourraient être validés à la volée. Vous voyez cela dans les évaluateurs "mot de passe direct".

  • Le choix d'un nom d'utilisateur peut également être validé à la volée en tant que types d'utilisateurs.

  • La saisie d'un numéro de téléphone avec des caractères non numériques, tels que des lettres, des barres obliques ou des espaces peut afficher un avertissement lors de sa détection.

b. Lorsque l'utilisateur quitte le champ

Cela devrait signaler certaines erreurs de frappe possibles, par exemple, un e-mail non valide, un nom avec une seule lettre ou un code postal non valide.

c. Envoyer ou étape suivante

Voici un peu évident qu'un bouton "Envoyer ou Étape suivante" devrait marquer les champs obligatoires vides.


2. Aide supplémentaire

Certains champs pourraient avoir une aide supplémentaire comme la saisie semi-automatique lors de la saisie de choses courantes comme les lieux, le comté, probablement les États.


3. Avertissements de validation d'intensité différente

Ce que je veux explorer ici, c'est que certaines validations peuvent être par exemple plus subtiles, par exemple, lorsque vous tapez un e-mail, le champ peut être de couleur gris clair comme arrière-plan, et lorsque l'e-mail est valide (après avoir un @ et un final .) changez en blanc.

Mais lors de la validation des champs vides, ce même champ peut virer au rouge intense et en colère.


4. Choisissez le bon schéma de couleurs dès le départ

Je dois constamment utiliser la page d'un fournisseur de téléphone portable pour ajouter de l'argent à mon téléphone.

Mais le schéma de couleurs "moderne et élégant" qu'ils ont fait une case à cocher pour un "j'accepte les termes et conditions" presque totalement invisible. Je vous assure que je le marquerais si je pouvais le voir depuis le début.

0
Rafael