Quel événement déclencher la validation et la mise en forme du champ de formulaire Javascript?

Question

Permettez-moi d’abord de dire que nous validons tous les champs côté serveur. C’est donc une question. sur la convivialité côté client.

Quelle est la sagesse habituelle en ce qui concerne le moment exact de valider et de formater les champs de saisie de formulaire HTML à l'aide de javascript?

Par exemple, nous avons un champ de numéro de téléphone. Nous autorisons les nombres, les espaces, les parenthèses et les traits d'union. Nous voulons que le champ ait dix chiffres. De plus, nous voulons que le champ ressemble à (123) 456-7890, même si l'utilisateur ne le tape pas de cette façon.

Il semble que nous puissions

• Validez et formatez-le lorsque l'utilisateur quitte le champ.
• Valider et formater sur chaque caractère saisi.
• Intercepter les frappes au clavier et empêcher la l’utilisateur de saisir des caractères incorrects.
• Une combinaison des éléments ci-dessus (par exemple format à l'entrée et valider à la sortie, empêcher à l'entrée et formater à la sortie, etc.)
• [ Ajouté ] Attendez et effectuez toute la validation et le formatage lorsque l'utilisateur clique sur Soumettre.

Je l'ai vu faire toutes ces choses, mais je ne trouve pas d'informations sur ce que est préférable (ou même généralement accepté) du point de vue de la convivialité, et plus important encore, pourquoi.

[ Modifier : quelques éclaircissements]

Nous n’appliquons absolument aucune norme de format. Quand je parle de format, je veux dire que nous utiliserons javascript pour réécrire les choses afin qu'elles soient belles. Si l'utilisateur tape 1234567890, nous le changerons en (123) 456-7890. Il n'y a pas de " règles de formatage " cela peut échouer.

Je distingue cela de la validation parce que s'ils ne tapent pas assez de nombres, nous devons les faire corriger.

Je suppose que je devrais reformuler la question comme suit: "quelle est la sagesse classique en ce qui concerne le moment exact pour valider et le moment exact pour formater ...?

Bonne information dans les réponses jusqu'à présent!

MODIFIER : j'accepte ma propre réponse ci-dessous dans l'espoir que d'autres personnes trouveront le lien aussi utile que moi.

Answer 1

Jusqu'à présent, la meilleure réponse n'était pas une réponse, mais un commentaire (voir ci-dessus.) J'ajoute cette réponse au cas où quelqu'un l'aurait manquée dans le commentaire.

Voir l'article suivant sur A List Apart.

Validation en ligne dans les formulaires Web par Luke Wroblewski

Answer 2

  

Validez et formatez-le lorsque l'utilisateur quitte le champ.

Oui. Fournissez à l'utilisateur des commentaires non invasifs en cas d'échec des règles de validation ou de formatage. Par non invasif, je veux dire ne pas afficher une boîte de dialogue d'alerte ou modale, ce qui obligerait l'utilisateur à cliquer sur quelque chose. Affichez plutôt de manière dynamique un message adjacent ou situé sous le champ où la validation ou le formatage a échoué.

  

Validez et formatez chaque caractère saisi.

Non. Je pense que cela empêche la facilité d'utilisation. Au lieu de cela, fournissez à l'utilisateur une info-bulle ou un autre indice indiquant les règles de formatage ou les règles de validation. Par exemple. pour un " requis " saisissez l'astérisque pratiquement omniprésent, et pour les champs avec formatage, indiquez à l'utilisateur le format attendu.

  

Intercepter les frappes au clavier et empêcher l'utilisateur de saisir des caractères incorrects.

Si vous souhaitez empêcher l'utilisateur de saisir des caractères non valides, expliquez-lui pourquoi vous venez de bloquer leur saisie, de manière non invasive. Aussi, ne volez pas le focus du champ.

Donc pour moi les principes généraux sont les suivants:

1. Informez l'utilisateur dès le départ de vos règles de validation et de formatage.
2. Ne présumez pas que l'utilisateur est malvoyant. Pensez donc à l'accès au Web et aux lecteurs d'écran. (Sauf si vous développez un site Web dont le public cible est limité, tel qu'un intranet.)
3. Fournissez à l'utilisateur des informations non invasives, ce qui signifie qu'il ne faut pas que l'utilisateur clique sur une boîte d'alerte ou sur une boîte de dialogue modale à chaque échec.
4. Indiquez clairement les règles de validation ou de formatage dont la zone de saisie a échoué et expliquez à l'utilisateur la raison de l'échec de la saisie.
5. Ne volez pas le focus de la souris / du pointeur lorsque vous fournissez des commentaires.
6. Ne perdez pas de vue l'ordre des tabulations afin que, lorsque les utilisateurs orientés clavier remplissent un champ, ils puissent appuyer sur tab et passer au champ de sélection / entrée logique suivant.

Answer 3

J'allais décrire diverses options, mais il peut être intéressant d'utiliser simplement un framework js existant pour gérer les masques de saisie. Voici un bon aperçu des différentes options

Answer 4

bmb indique qu'ils acceptent n'importe quel format et le modifie au format souhaité (xxx) nnn-xxxx. C'est très bien. La question est le moment de A) le changement de format et B) la validation.

A) Le changement de format doit être effectué lorsque l'utilisateur quitte le champ. Tôt est agaçant et annule plus tard le but d’afficher le changement.

B) La validation s’effectue de manière plus appropriée en quittant le champ ou en soumettant le formulaire. Plus tôt, c'est frustrant et déroutant pour l'utilisateur. Sous une forme longue et complexe comportant plusieurs écrans, je préférerais effectuer une validation à la sortie du contrôle pour faciliter les corrections. Sur un formulaire abrégé, je le ferais sur présentation pour éviter de briser le flux de remplissage du formulaire. C'est vraiment un jugement, alors testez-le si possible avec de vrais utilisateurs.

De préférence, vous testez toujours votre travail avec de vrais utilisateurs, mais si vous n'avez pas de budget ou d'accès pour cela, utilisez un "utilisateur" rapide et sale. test peut aider avec des décisions comme celle-ci. Vous pouvez capturer une poignée de personnes qui n'ont pas travaillé sur le logiciel (aussi proches que possible de vos utilisateurs finaux) et leur demander de remplir le formulaire. Demandez-leur de saisir les choses de manière spécifique pour obtenir une erreur, puis regardez-les corriger. Demandez-leur de parler à voix haute de ce qu'ils font pour ne pas avoir à deviner leur processus de pensée. Cherchez où ils ont des problèmes et ce qui semble les troubler / les agacer le plus.

Answer 5

Cela dépend par champ. Mais pour quelque chose comme un numéro de téléphone, il est généralement assez agréable d'empêcher quelqu'un d'entrer même des chiffres non numériques.

Ainsi, en tapant, vous remarquerez que votre numéro de téléphone 1-800-HELLOWORLD ne s'affiche pas correctement et vous vous rendrez compte que le champ accepte uniquement des chiffres (que vous pouvez également mettre en surbrillance avec une sorte de champ d'information à côté de l'entrée). champ).

Cela me semble beaucoup plus intuitif et convivial qu'un dialogue modal gênant, un champ d'erreur contextuel ou un message généré par le serveur affichant après que vous ayez fini de le remplir.

Bien entendu, vous devez toujours trouver un équilibre entre la validation ultime côté client et les exigences techniques ultimes pour la construire. Si vous commencez par exemple à valider le téléchargement d’images avec Ajax avant que la page ne soit soumise, la route peut être longue.

Modifier: tenez également compte de votre public. Les plus avisés sur le plan technique accepteront davantage le terme "dynamique". formes que, par exemple, les gens qui sont plus habitués à l’approche non-Ajax d’Internet.

Answer 6

Personnellement, je pense que le formatage et la validation à la sortie sont les moins gênants pour l’utilisateur. Laissez-les entrer le numéro dans le format de leur choix (et il y en a beaucoup pour un numéro de téléphone), puis modifiez-le au format de votre choix. Ne forcez pas l'utilisateur à se conformer à vos préférences lorsque vous pouvez gérer les données dans leur format préféré.

De plus, les messages de validation lorsque je n'ai pas fini de taper sont ennuyeux, et ne pas pouvoir mettre un certain caractère dans un champ de texte est super gênant.

La seule exception à laquelle je peux penser est "cette valeur est-elle disponible" situations (telles que la création d’un nom d’utilisateur unique) - dans ce cas, un retour immédiat est vraiment pratique.

Answer 7

Je trouve les trois premières options très ennuyantes. Il n'y a rien de pire que d'être interrompu en train de taper quelque chose.

Le principal objectif de vos utilisateurs est de traiter le formulaire aussi rapidement que possible et tout ce que vous faites qui le ralentit n'est qu'une raison de plus pour qu'ils l'abandonnent complètement.

Je déteste aussi être obligé de taper quelque chose comme un numéro de carte de crédit ou un numéro de téléphone est exactement le bon format pour satisfaire le formulaire. Autant que possible, donnez simplement à l'utilisateur une boîte dans laquelle taper des éléments et ne lui faites pas traiter le formatage.

Dans le cas de votre numéro de téléphone, laissez-le y entrer comme bon vous semble, supprimez tout ce que vous n'aimez pas, essayez de le reconstituer dans le format de votre choix ((124) 567-8901) et lancez un erreur si vous ne pouvez pas.

Si vous devez absolument valider quelque chose dans un format spécifique, faites-le lorsqu'ils soumettent le formulaire, puis mettez en surbrillance les champs posant problème.

Answer 8

La validation la plus conviviale que je connaisse consiste à avoir un indicateur qui apparaît à côté du champ de saisie pour indiquer que la valeur est invalide. De cette façon, vous n'interrompez pas l'utilisateur au cours de la frappe et pourtant, il peut toujours voir s'il a saisi ou non une entrée valide. Je n'aime pas devoir taper des informations dans un formulaire long uniquement pour que la chose me dise à la fin "Oh, vous devez revenir en arrière et corriger le champ 1".

Vous pouvez afficher ou masquer l'indicateur en tant que type d'utilisateur. J'utilise une icône d'avertissement lorsque la valeur est invalide et je place une info-bulle sur l'icône qui explique pourquoi la valeur est invalide.

Si vous avez l'écran immobilier, vous pouvez simplement mettre un texte tel que "Valide". ou "Doit être au format XXX-YYY-XXXX".

N'oubliez pas que lorsque vous effectuez une validation par frappe, vous devez également capturer le texte collé.

De plus, vous devez également éviter que des frappes au clavier non valides ne soient introduites en premier lieu.

Answer 9

Pour les meilleures pratiques en matière de convivialité, je suggère de lire How To Concevoir la forme parfaite (plus précisément Contexte et assistance ) et Beautiful Forms .

Pour un cadre de validation de formulaire, consultez les fValidator et iMask , ils sont complémentaires et fonctionnent donc parfaitement ensemble.