Fractionnement des champs de numéro de carte de crédit en quatre entrées différentes
J'utilisais auparavant 4 champs pour le numéro de carte de crédit, divisant chaque ensemble de 4 numéros pour le rendre plus facile à saisir.
Je pense maintenant à avoir un champ, qui insère des espaces après chaque ensemble de nombres à la place:
Pour celui avec 4 champs, le curseur passe automatiquement au champ suivant.
Quel format est préféré? Ou existe-t-il d'autres meilleures alternatives?
J'accepte uniquement les cartes Visa, Mastercard et Discovery, avec 16 et 17 chiffres.
J'opterais généralement pour la solution la plus simple. Dans ce cas, un seul champ que l'utilisateur doit saisir .
Avec des champs divisés, comme celui à 4 cases que vous proposez, il ajoute une charge cognitive supplémentaire à l'utilisateur.
- "Dois-je passer manuellement à chaque champ?"
- "Le système le fera-t-il pour moi?"
- "Que se passe-t-il si je tape
tabmoi-même mais que le formulaire saute automatiquement - aura-t-il plutôt sauté dans le 3e champ ...?"
Toutes ces questions supplémentaires - peut-être inconsciemment, peut-être plus à l'avant-garde dans leur esprit - ne sont pas des questions qui seraient même envisagées sous une seule forme de champ.
Bien sûr, les options à 4 champs facilitent la lisibilité - donc si l'utilisateur a mal entré son numéro, il est plus facile pour lui de relire son entrée pour voir quelle zone il a mal fait. Mais cela peut encore être atténué dans un seul domaine. Tout comme vous l'avez montré ci-dessus, vous pouvez rendre l'entrée utilisateur avec des espaces dans le champ unique.
Une autre considération concerne les utilisateurs mobiles . Bien que cela puisse être simple sur un ordinateur de bureau, un mobile possède un clavier qu'il doit ouvrir et fermer à l'entrée du champ. Différents appareils et systèmes d'exploitation se comportent différemment, mais il est fort probable que lors du saut du champ 1 au champ 2, le clavier se fermera et s'ouvrira automatiquement, provoquant un flash discordant à l'écran, l'utilisateur essayant peut-être de cliquer sur le 5e chiffre au moment où le clavier se ferme , déplaçant ainsi le curseur dans une autre zone de l'écran, ou manquant tout simplement ce chiffre de l'entrée.
Ce problème mobile est bien illustré sur blog Baymard , où ils soulignent également que les utilisateurs mobiles ont tendance à appuyer manuellement dans chaque champ - ce que les utilisateurs de bureau ne font pas aussi souvent.
Votre proposition est une bonne idée, mais je pense qu'elle entre dans la catégorie de la "suringénierie". À moins que vous ne remarquiez d'importantes erreurs de saisie utilisateur sur un seul champ, je ne pense pas que vous ayez besoin d'introduire une alternative. Vous pourriez risquer de réduire la convivialité au lieu de l'améliorer.
Cette réponse et cette réponse couvrent bien certains points mais pour une raison quelconque, personne ne discute du support de remplissage automatique.
N'utilisez pas 4 champs séparés.
- Tout d'abord, c'est ennuyeux, beaucoup de ces raisons sont traitées dans les autres réponses.
De plus, un numéro CC n'est pas quatre nombres à 4 chiffres, c'est un seul numéro long. Certaines cartes de crédit n'ont même pas de groupes de quatre, auquel cas votre saisie sur quatre champs n'a même pas de sens, par exemple:
![enter image description here]()
Le vrai que je veux ajouter est que certains navigateurs donnent la possibilité de remplir des informations de carte de crédit pour vous. Chrome, par exemple a cette fonctionnalité, et Safari sur iOS 8 ajoutera automatiquement un bouton "scanner la carte de crédit" à ces appareils si vous les créez correctement (voir cet article). Et donc le champ réel "parfait" du point de vue UX est un champ unique avec le nom de champ approprié (comme "Numéro de carte de crédit") et les attributs de déclencheur spécifiques au navigateur appropriés (comme
autocomplete="cc-number"etid="cc_number").
N'essayez pas d'inventer votre propre méthode de saisie "pratique" pour cela. Respectez les mêmes méthodes de saisie de numéro de carte de crédit standard qui sont déjà couramment utilisées (champ unique, nom et attributs appropriés), car les développeurs de navigateurs sont déjà en faisant un effort pour améliorer l'UX de ces types de champs, donc vous le laissez être géré du côté du navigateur et donnez aux utilisateurs quelque chose qu'ils connaissent bien au lieu de quelque chose d'inconvénient qui exécute également le risque de casser toutes les fonctionnalités de Nice que leur offre normalement leur navigateur préféré.
En tant que personne qui utilise des cartes de crédit virtuelles, je suis fortement en faveur d'un seul domaine. Chaque fois que je veux payer, un nouveau numéro de carte est généré pour moi par l'application bancaire, et c'est très fastidieux de devoir copier-coller quatre fois au lieu d'une. Je suppose ici que votre formulaire ne remplira pas les 4 champs si je colle 16 chiffres dans le premier. Est-ce que cela va?
De plus, j'ai vu plusieurs conceptions à 4 champs qui étaient incroyablement difficiles à utiliser. Parfois en appuyant Backspace a dû revenir à un champ avec une faute de frappe, dans d'autres cas Shift+Tab Était demandé. Parfois, le champ dans lequel vous avez sauté avait son texte présélectionné ou effacé, il était donc fondamentalement impossible de prédire comment le formulaire se comporterait sans l'observer après chaque pression de touche.
Donnez-moi simplement un champ dans lequel je peux coller un numéro de carte et laissez-moi utiliser Backspace pour corriger les fautes de frappe s'il m'arrive de taper le numéro manuellement. Ici quelque chose qui semble acceptable:
$('#test_form').on('keyup', function(e){
var val = $(this).val();
var newval = '';
val = val.replace(/\s/g, '');
for(var i=0; i < val.length; i++) {
if(i%4 == 0 && i > 0) newval = newval.concat(' ');
newval = newval.concat(val[i]);
}
$(this).val(newval);
})
La solution la plus simple, sinon nécessairement la meilleure, est un seul champ de carte de crédit qui permet à un utilisateur de saisir n'importe quelle chaîne de chiffres et espaces. Il devrait être trivial pour la logique côté serveur de supprimer les espaces de la chaîne soumise avant de vérifier si la chaîne de chiffres résultante est ou non un numéro de carte de crédit valide. Si l'utilisateur choisit d'entrer des espaces de début ou de fin ou de casser les chiffres à différents endroits de ce qui est sur la carte, alors quoi?
L'insertion automatique des espaces pour l'utilisateur peut être légèrement plus conviviale mais représente beaucoup plus de travail.
Plusieurs champs avec tabulation automatique de l'un au suivant sont OK, mais si vous prenez des cartes autres que Mastercard/Visa, alors il faut beaucoup de travail pour ajuster la longueur des champs pour le type de carte (par exemple 4,6,5,0 pour Amex) à la volée (c'est-à-dire dans un script côté navigateur). Sur un site Web de société de cartes qui, par définition, ne prend qu'une seule sorte de carte, c'est clair et facile. [Modifier: OK-ish. D'autres réponses indiquent pourquoi c'est un désavantage pour certains utilisateurs]
Refuser de laisser l'utilisateur entrer des espaces est hostile à l'utilisateur. Permettre à l'utilisateur d'entrer des espaces puis rejeter le numéro de carte (correct!) Comme invalide après la soumission est vraiment abominable, dans la mesure où je pourrais refuser à ce détaillant ma coutume à ce moment-là et acheter à la place de celui qui était auparavant mon deuxième choix.
Luke Wroblewski, un expert UX avec de grandes connaissances sur la création de formulaires efficaces, a répondu à cette question: tilisez un seul champ de saisie numérique (voici ne vidéo de la façon dont cela fonctionne ).
Comme vous pouvez le voir dans la vidéo ci-dessus de la démo de Zachary, un seul champ de saisie est utilisé pour capturer le numéro de carte de crédit en premier. Si le numéro de carte de crédit n'est pas valide, une erreur s'affiche qui empêche l'utilisateur d'avancer. Si le numéro de carte de crédit est valide, l'icône générique de carte de crédit change pour refléter le type de carte entré. Cela élimine le besoin d'un menu déroulant ou d'un sélecteur de "type" de carte de crédit distinct et rassure quelqu'un sur le fait que son entrée a été comprise.
Une fois le numéro de carte de crédit validé, il glisse vers la gauche en ne laissant que les quatre derniers chiffres de fin pour référence et le prochain ensemble d'entrées apparaît dans le masque: date d'expiration, code CVV (sécurité) et code postal. Comme ce sont toutes des entrées numériques, un jeu de touches programmables de 0 à 9 est tout ce qui est nécessaire pour garder les gens en mouvement sur le clavier.
Étant donné que la date d'expiration d'une carte de crédit ne peut pas se situer dans le passé ou dans un avenir lointain, le masque de saisie permet à nouveau d'éviter les erreurs. Les mois ou années non valides ne seront tout simplement pas acceptés. Après l'ajout d'une date d'expiration valide, la conception de Square présente une autre excellente amélioration. L'icône de la carte de crédit change pour révéler où se trouve le code CVV sur la carte spécifique utilisée pour payer. Ce petit détail aide les gens à savoir quelles informations sont ensuite nécessaires.
Étant donné que CVV et Zip sont également des entrées numériques, il n'y a aucune raison de ne jamais quitter le clavier pendant le processus de saisie du paiement: aucun saut entre plusieurs champs de formulaire n'est requis. Zachary a également veillé à ce que les gens puissent utiliser leur clavier (onglet et onglet Maj) et leur souris pour se déplacer entre les différentes parties de ce masque de saisie de paiement.
Veuillez suivre les conseils des autres et n'essayez pas de réinventer la roue. Non, sauf si vous avez lu et compris la norme ISO ISO/IEC 7812 qui régit les numéros de cartes de paiement, qui, en passant, varient de 13 à 19 chiffres et généralement (mais pas toujours - lisez les spécifications) inclure un chiffre de contrôle que vous pouvez utiliser pour valider l'entrée.
Insérer des espaces là où il n'y en a pas est presque toujours une mauvaise idée. Pensez à toutes les combinaisons possibles auxquelles vous devrez faire face; rempli automatiquement, utilisé pour remplir le remplissage automatique. Collé sans espaces, collé avec espaces, coupé pour être utilisé ailleurs (la coupe doit-il inclure les espaces?), Tapé, édité et à la fin de la journée, quel est le problème que vous essayez de résoudre?
Je pense que Card.js est mon expérience utilisateur préférée quand il s'agit d'ajouter des cartes. Non seulement cela vous permet de taper très rapidement (champs uniques, etc.), mais ils vous montrent également où se trouvent ces champs sur vos cartes particulières, vous n'avez donc pas à vous demander où est la date d'expiration ou le CVV. Je vous recommande de le vérifier.
Un point supplémentaire mineur, je ne pense pas, est abordé ailleurs: une seule boîte est plus accessible, en particulier sur les systèmes sans une suite complète d'outils d'accessibilité:
- Il évolue si la fenêtre est agrandie (un simple zoom sur une fenêtre de navigateur laisse toujours au curseur une fine ligne qui peut être difficile à trouver - un pixel si je teste sur cette page dans firefox/windows)
La tabulation entre les champs se comporte raisonnablement (n'oubliez pas shift-tab).
Ce n'est peut-être plus vrai, mais certains lecteurs d'écran se débattaient avec des boîtes de saisie non étiquetées - cela peut toujours être le cas pour les technologies de saisie vocale, mais je ne les ai pas utilisées.
Je ne dis pas que vous ne pouvez pas faire une entrée accessible (et conforme aux normes) avec des boîtes séparées, mais une seule boîte est plus facile pour vous et les utilisateurs qui ont besoin (ou veulent) d'interfaces atypiques.
S'il vous plaît, pour l'amour de Dieu, ne faites pas la deuxième option.
une énorme faille UX est (ce que la majorité des sites font lors de la mise en œuvre de cette obturateur) vous ne pouvez pas revenir en arrière pour modifier les numéros précédemment, car cela vous oblige automatiquement à passer au champ suivant depuis que vous avez rempli les données.
N'oublions pas que la création de plusieurs champs donne l'impression que vous remplissez différents bits d'informations. Dans votre conception, cela donne l'impression que le dernier champ sera potentiellement le "code de sécurité".
En faire un champ implique un bloc de nombres (mais veuillez faire ce que vous avez fait dans la première option: indentation car cela montre exactement le même format que votre carte).
Lorsque vous remplissez les détails de la carte de crédit, vous souhaitez vous rapprocher de la conception de la carte physique réelle, car les utilisateurs pourront ensuite numériser la carte et rechercher pour ajouter les informations qu'ils viennent de numériser. Brouiller quoi que ce soit provoquera de la confusion et de la frustration (d'après mon expérience de travail dans le monde du commerce électronique pendant des années).