Format d'entrée de carte de crédit
Quelque part, dans l'un des livres sur l'utilisabilité que j'ai lus (probablement Donald Norman), il y avait une suggestion que le format normal pour entrer les cartes de crédit était mauvais. Le format habituel est de 16 caractères dans une longue chaîne. Cependant, la façon dont nous lisons alors et ils sont imprimés sur la carte est de 4 groupes de 4. L'argument est - et je suis entièrement d'accord avec cela - qu'entrer la carte en 4 lots de 4 serait beaucoup plus facile, à la fois pour entrer et pour vérifier pour l'utilisateur.
Cela n'a besoin que d'un peu de codage pour inclure les tirets dans les données saisies et les ignorer dans la validation. Ou pour avoir 4 cases en mettant l'accent sur la suivante. Ce n'est pas un problème de codage complexe. Alors pourquoi personne ne semble le faire? Pourquoi le format de boîte standard est-il toujours aussi répandu?
Cela vient du fait que je viens d'essayer d'utiliser ma carte de crédit et de commettre une erreur, puis que j'ai dû parcourir tout le lot pour identifier les erreurs - fastidieuses, et quelque chose qui serait beaucoup plus facile si elle était correctement divisée.
Modifier: pour ajouter quelques points à partir des commentaires. Je pense que la bonne mise en œuvre devrait être élaborée - 4 boîtes de tirets auto-insérés peuvent ne pas fonctionner, ou peuvent avoir besoin d'être modifiées. Il ne s'agit donc pas de dire que xxx est la bonne approche, mais que l'approche actuelle a son propre ensemble de problèmes.
Acceptez tous les formats tapés dans une seule case.
Comme indiqué par Don Norman :
"Conformité: comment Microsoft Outlook fait les choses correctement
Microsoft Office Outlook a fait un excellent travail de gestion des numéros de téléphone, des dates, des heures et des adresses. Surprise: c'est un produit que les gens ciblent généralement avec des plaintes, mais j'ai l'intention de les féliciter. Lorsque le carnet d'adresses ou les formulaires de contact d'Outlook demandent un numéro de téléphone, il accepte tout format que la personne souhaite utiliser , détermine à quel pays il appartient, et le reformate sous une forme standard. Démarrez un numéro de téléphone avec +358 et il sait que vous tapez un numéro finlandais, il n'essaie donc pas de le formater de la même manière que pour les numéros américains. S'il s'agit d'un nombre américain, vous pouvez utiliser presque tous les caractères d'espacement que vous souhaitez, tant que le nombre comporte les 7, 10 ou 11 chiffres habituels. Par conséquent, vous pouvez saisir l'un de ces numéros de téléphone américains:
5551212
555.1212
847 555-1212
(847) 555-1212
847.555.1212
8475551212
+18475551212
Et ils se transforment tous en 555-1212, (847) 555-1212, ou dans le dernier cas, +1 (847) 555-1212.
La plupart des systèmes sont aussi mauvais avec les dates qu'avec les numéros de téléphone. Nous disons les dates de toutes sortes de façons: la plupart des systèmes nous grondent si nous ne le faisons pas comme ils le souhaitent, encore une fois, souvent sans nous dire ce qu'ils aiment.
Voici quelques façons d'écrire la date du 20 janvier 2009:
20/01/09
20/01/2009
20/1/2009
20 janv.09
2009.01.20
20 janvier 09
Vive Outlook! Il montre une énorme conformité, une énorme tolérance pour notre variabilité. Il prend tous ces formats et les transforme en la spécification cible qu'il préfère: Mar 1/20/2009. Mais encore mieux, la spécification cible est définie par la personne utilisant l'ordinateur et est stockée dans le système d'exploitation, de sorte que tous les programmes peuvent utiliser les mêmes formats. "
Certes, nous sommes assez nombreux UXers à nous plaindre d'une entrée de carte de crédit intolérante. En plus de Norman 2009 :
Ajoutez plus aux commentaires, si vous le souhaitez.
Il est viable d'insérer automatiquement des délimiteurs tels que des tirets ou des espaces dans un seul champ de texte au fur et à mesure que l'utilisateur tape. Presque aussi bon et plus simple sur le plan du programme est de laisser les utilisateurs entrer les délimiteurs qu'ils veulent où ils veulent. Il y a de fortes chances qu'ils le saisissent comme ils le souhaitent. Dans les coulisses, supprimez tous les non-nombres pour la validation, la somme de contrôle et les transactions financières réelles.
Pourquoi tant de sites Web insistent-ils sur l'absence de délimiteurs? Je devine l'ignorance. Et la paresse. Et la résistance au changement. Tout le monde le fait, alors où est la concurrence à craindre? Et la dureté. Au moment où les utilisateurs entrent leurs numéros de carte de crédit respectifs, ils ne vont pas abandonner un achat et perdre tout leur travail en raison d'une erreur, peu importe combien cela les fait chier, alors qui s'en soucie?
D'accord avec vous en principe, mais toutes les cartes de crédit n'ont pas 16 chiffres. J'ai une carte American Express en face de moi qui a 15 chiffres (divisés en 4-6-5) - voir plus de longueurs sur numéro de carte bancaire Wikipedia page - Il semble que 12-19 chiffres puissent être possible.
Cela rend une tâche complexe et dépendante du fournisseur de cartes de fournir un formulaire qui divise le numéro de carte en un nombre correct/approprié de champs. Les tests seraient une tâche assez importante et pourraient ne pas être à l'épreuve du temps non plus.
Voici une opinion contraire:
Forcer l'utilisateur à entrer sans espaces ni tirets oblige l'utilisateur à saisir les données plus attentivement.
Cela dit, je pense que cette raison est superflue. Je sais que les API backend des processeurs de cartes courants nécessitent un flux de chiffres: lorsque j'ai créé des formulaires de carte de crédit, je supprime simplement les espaces et les tirets ("s/[-] // g") et j'écris une note dans les espaces de l'utilisateur vont bien'.
La raison d'utiliser une seule zone de texte est qu'il est beaucoup plus facile pour un utilisateur d'entrer simplement les chiffres. La tabulation entre les champs de texte tous les 4 caractères est une douleur absolue. Et la mise au point automatique est très ennuyeuse, surtout si vous devez revenir en arrière et apporter des modifications. L'implémentation pour faire fonctionner cela provoque presque toujours des problèmes lors de la tentative de modification.
Roger a également raison de dire que toutes les cartes de crédit n'ont pas le même format et que, par conséquent, vous ne pouvez pas forcer un format spécifique. Vous devriez avoir des champs différents pour chaque format, ce qui ne ferait qu'ajouter à la complexité de votre application.
L'utilisation d'une sorte de masquage pour mettre en place des séparateurs lorsque l'utilisateur quitte le champ peut fonctionner correctement, mais encore une fois, cela peut ne pas fonctionner comme prévu en fonction du type de carte.
C'est la même logique pour d'autres domaines similaires comme le numéro de téléphone et le numéro de sécurité sociale. Nous avons discuté des champs de formulaire de numéro de téléphone dans le passé également.
Quatre cases nécessitent une tabulation. Une chaîne de 16 caractères est plus difficile à obtenir correctement. Il me semble que la solution ici est une zone de texte qui accepte les espaces (vous pouvez donc entrer 19 caractères et être résilient aux autres formats numériques). Corrigez-le lors de l'analyse, pas en surchargeant l'utilisateur. Si vous voulez aussi accepter les tirets, c'est ok, mais comme les tirets ne sont pas sur la carte, vous ne devriez pas en avoir besoin (les utilisateurs ne s'y attendront pas).