Les utilisateurs saisissent les mauvais séparateurs décimaux pour les montants en US $
J'ai une application qui accepte un montant en $ USD. Malheureusement, certaines personnes sont étrangères/visiteurs aux États-Unis et tapent des montants avec des virgules au lieu de points: ils mettent en forme le nombre comme XXX.XXX, 00 au lieu du format américain de XXX, XXX.00. Les différents formats attendus sont à l'origine de problèmes. Même si le champ de saisie de texte affiche le "$" comme préfixe de champ et que j'ai un espace réservé de "USD", les gens tapent toujours le mauvais format.
Exemple:
Expected US: 345.60
User Enters: 345,6
accounting.js translates to: 3456.00
L'utilisateur paie alors 3456,00 $! Ce n'est évidemment pas bon et c'est une énorme erreur. À ce stade, je pense qu'il est très mauvais pour moi d'essayer même de modifier le texte entré. Au lieu de cela, je devrais forcer l'utilisateur à taper correctement le format (exact). Je peux facilement ajouter un format/message d'erreur sous le champ de texte qui décrit le format correct plus en détail avec des exemples.
Si je les force à taper le format correct:
- Dois-je autoriser les virgules?
- Dois-je supprimer automatiquement les virgules de la saisie?
- Dois-je lancer une erreur lorsqu'une virgule est utilisée?
- Dois-je lancer une erreur lorsqu'une décimale n'est pas utilisée?
Remarque: je ne suis forcé au format USD $ qu'en ce moment. Les décimales sont courantes à 99%, mais ne sont pas nécessaires pour que la transaction ait lieu. Je cherche à utiliser une expression régulière pour donner l'avertissement, comme /^\d*(\.\d{2}$)?$/.
Parlons un instant des attentes des utilisateurs et de la magie.
Un utilisateur vient à votre outil avec certaines attentes, et les attentes de tous les utilisateurs ne sont pas les mêmes. Vous voyez cela de première main. La culture, l'élévation et l'expérience de vie façonnent toutes la façon dont un utilisateur interagira avec un outil, ouvrant un large éventail d'attentes à potentiellement répondre.
Cependant, presque tous les utilisateurs s'attendent à ce que lorsqu'un illusionniste ou un magicien fait un tour - par exemple, choisir une carte dans un jeu de cartes - l'illusionniste va toujours deviner sa carte correctement.
Autrement dit, si votre outil va automatiser quelque chose, et va deviner ce que l’utilisateur voulait taper, il doit obtenir cette supposition correcte , ou l'utilisateur finira déçu ou frustré.
Comme vous l'avez également indiqué, ils peuvent finir par être surchargés, ce qui, si votre système change ce qu'ils ont entré sans leur désir exprès et augmente le montant, pourrait vous rendre légalement responsable de la surcharge et vous causer des ennuis.
Deviner ou ne pas deviner; telle est la question. Nous avons donc deux choix d’action:
Option 1: Analysez ce qui est tapé et corrigez-le
Dans ce cas, vous devrez peut-être rechercher une solution qui peut mieux s'adapter à tous les cas Edge que vous voyez. Si accounting.js ne reformate pas correctement le texte, vous devrez peut-être faire quelque chose de plus personnalisé.
Saisissez l'expression régulière.
Ce que vous devrez faire est de comprendre tous les modèles que vous pourriez rencontrer, qui sont corrects et qui doivent être modifiés. Lorsque nous commençons à examiner des cas courants,
- ###.###,## > ###,###.##?
- ###,###,## > ###,###.##?
- ######,## > ###,###.## or ##,###,###?
Cela commence à devenir délicat assez rapidement. Pour ce faire, vous devrez effectuer suffisamment de tests pour savoir si vos modèles de test et de remplacement fonctionnent correctement, et vous devrez faire attention à ce que de nouveaux modèles n'apparaissent pas.
De plus, si l'un de vos modèles modifie le contenu de manière incorrecte, l'utilisateur peut ne pas remarquer que vous avez mis à jour le montant (ou, lorsque vous lui demandez de confirmer que la valeur mise à jour correspond à ce qu'il voulait dire, il pourrait manquer un changement important) et terminer jusqu'à payer le mauvais montant. De plus, si vous le faisiez pour eux, vous pourriez être légalement accroché.
Option 2: Guidez-les vers le bon formatage
Cette option demandera un peu moins de travail et sera plus sûre d'un certain nombre de points de vue. Il est également plus susceptible de se retrouver dans une expérience utilisateur agréable.
Ici, recherchez toujours une chaîne au format étrange. Trop de périodes, trop de chiffres entre virgules, une virgule délimitant les deux dernières chaînes de nombres, des choses comme ça.
Je suggérerais d'utiliser une implémentation de la validation de champ en direct pour confirmer qu'ils formatent correctement leur entrée. Quand ils tapent quelque chose d'étrange, cliquez hors de la boîte ou essayez de soumettre le formulaire, assurez-vous de traiter la chaîne pour marquer l'un des tests que vous recherchez. S'il échoue à un test, affichez un message à côté ou en dessous du champ (regardez certaines de ces images pour des idées sur la façon d'afficher les messages) qui explique spécifiquement ce qui semble étrange.
Ne changez rien automatiquement - demandez-leur de le faire eux-mêmes.
Vérifiez à nouveau dès que possible s'ils ont apporté des modifications correctes. Idéalement, faites-le avant d'avoir à appuyer à nouveau sur le bouton Soumettre, lorsqu'ils se concentrent sur le champ par exemple. Si tout va bien, affichez un message (dans une couleur de succès amicale comme le vert ou le bleu) qui leur dit qu'ils ont réussi à corriger l'erreur. S'ils doivent essayer de le réparer à nouveau, réafficher un message d'erreur et indiquer que vous avez vérifié et qu'ils ont encore plus à faire.
Oops, looks like it's still not quite right. <error mitigation message follows.>
De cette façon, ils savent qu'ils ont encore du travail à faire et le formulaire demande explicitement une action de suivi.
Edit: En conclusion ...
Considérez les cas d'utilisation devant vous et quelle option (ou mélange des deux) vous pensez que vous pouvez mettre en œuvre pour rendre l'expérience prévisible et compréhensible pour l'utilisateur.
Une option intéressante qui combine les deux est le masquage que @jjwdesign a évoqué dans les commentaires. Le formulaire pourrait soit guider l'utilisateur depuis le début, comment faire les conventions, en affichant un subtil ___,___.__ dans le champ, ou cela pourrait ajouter/convertir la ponctuation lorsque l'utilisateur tape une valeur. Nous devons juste faire attention à ne pas le faire de manière confuse; comme certains le soulignent dans les commentaires de la page ici, remplacer les entrées d'un utilisateur peut être désorientant.
Bonne chance!
Une autre option serait que le champ de texte ignore tous les caractères non numériques et affiche automatiquement la mise en forme appropriée.
Par exemple:
User enters '3' -> Text field displays '0.03'
User enters '4' -> Text field displays '0.34'
User enters ',' -> Text field displays '0.34' (no change)
User enters '5' -> Text field displays '3.45'
User enters '6' -> Text field displays '34.56'
Montrer à l'utilisateur ce qui est attendu visuellement et montrer comment la machine interprète l'utilisateur contribution.
Ma contribution au brainstorming serait:
- Utilisez une référence au formulaire de contrôle de l'ancien temps :)
- Laissez l'ordinateur ignorer toutes les virgules et toutes les périodes entrées par l'utilisateur (d'ailleurs: caractères non numériques)
- Affichez (si vous le pouvez) une image en arrière-plan de votre champ de texte, indiquant les positions des dollars, des cents et une période les séparant.
- Utilisez une police à interligne simple pour le nombre
- Faites aligner le nombre à droite.
Maintenant, lorsque l'utilisateur saisira le montant, elle verra comment le système interprète automatiquement sa saisie, sans aucun script fonctionnant (sauf peut-être le script qui rejette les virgules et les points):
-
Vous pouvez faire tout ce que vous souhaitez, à condition de fournir un moyen de vérifier l'entrée. Je voudrais personnellement afficher dynamiquement - à côté du champ de saisie - le montant au moins partiellement écrit, comme
[ 123.45 ] (123 US dollars, 45 cents) [ 123,45 ] (123 US dollars, 45 cents) [ 123,456.78 ] (123 456 US dollars, 78 cents) [ 123,456 ] (123 456 US dollars, 0 cents)
([] contient l'entrée, () contient la vérification. Notez l'utilisation d'un espace non ambigu comme séparateur de milliers.)
Je ne dis pas que la méthode d'interprétation de l'entrée que je propose est la meilleure, mais vous fournissez une vérification instantanée. Pour moi (venant d'un pays avec une virgule décimale plutôt qu'un point décimal), il est intuitif de traiter ,XX en cents, mais à d'autres personnes, ,XXX signifie unités. Puisqu'une vérification instantanée est fournie, aucun dommage ne devrait être causé.
Remarque: N'oubliez pas de soumettre à la fois la saisie de l'utilisateur (pour vérifier ultérieurement ce qu'il a réellement écrit en cas de doute) et la vérification (pour être sûr de ce que l'utilisateur a vu et cru est l'interprétation), et vérifiez à nouveau qu'ils sont cohérents lorsque le formulaire est soumis.
Vous pouvez créer deux champs - 1 pour les dollars et 1 pour les cents. De cette façon, vous n'avez pas besoin de logique de formatage et vous pouvez supprimer tous les caractères non alphanumériques lorsque vous enregistrez dans une base de données.
Locale est le sujet de cette question. Le fait que vos utilisateurs doivent gérer les dollars américains ne signifie pas qu'ils le feront dans les paramètres régionaux du "propriétaire" de cette unité monétaire particulière (États-Unis). Les formats de date sont un autre exemple de la façon dont différents paramètres régionaux peuvent rendre une valeur de manière ambiguë sans connaître les paramètres régionaux dans lesquels la valeur a été rendue.
La manière dont un humain s'attend à gérer les informations locales dépend de nombreux facteurs que vous ne pouvez pas toujours prévoir en tant que programmeur. Ce que vous pouvez faire, c'est leur donner suffisamment d'informations pour qu'ils sachent dans quel environnement local ils utilisent le logiciel, ou dans quels aspects de cet environnement local ils doivent traiter avec. En HTML, une façon consiste à rendre localisés espaces réservés qui montrent le format d'entrée attendu.
Vous avez exprimé votre inquiétude à propos de personnes qui traitent accidentellement des sommes d'argent incorrectes. Il peut être judicieux de demander à l'utilisateur une confirmation finale avant de traiter la demande. Si vous analysez le montant saisi et que son format est inhabituel, car il utilise des séparateurs décimaux et de regroupement différents de ceux de en_US, vous pouvez toujours afficher un message demandant à l'utilisateur s'il a saisi le montant correct.
La solution UX consiste à le rendre sans erreur pour les utilisateurs, quel que soit le format auquel ils sont habitués. Rien de plus. Rien de moins.
Je recommanderais que vous examiniez la solution de type regex:
- assurez-vous qu'il y a deux chiffres après la virgule (ajoutez un 0 si nécessaire)
- puis enlevez tous les non-chiffres
- puis ajoutez le point décimal.
345,6 becomes
345,60 becomes
34560 becomes
345.60
Quel que soit le processus ou vos outils principaux, facilitez la tâche de vos utilisateurs. S'ils s'attendent à mettre 345,6 (au lieu de 345,60), laissez-les.
Le site bancaire que j'utilise en Belgique vous permet uniquement de saisir la notation décimale mais pas le séparateur des milliers.
Il accepte soit une virgule nique ou un point nique pour la notation décimale, mais rien d'autre ne peut être entré.
J'ai fait quelques tests supplémentaires sur la façon dont ils traitent le champ de saisie.
- Vous ne pouvez utiliser que
,ou un.une fois pour la notation décimale, pas de séparateur de milliers - Si vous tapez
4,puis essayez de taper4,,rien ne se passe, comme4,000.vous ne pouvez pas ajouter le. - Vous pouvez taper
4000.00ou4000,00et il convertit les deux en4000,00 - Copier et coller n'est pas autorisé
4,000est converti en4,00- c'est un problème, certainement pour un site bancaire, mais cela ne se produirait que pour les personnes qui tapent des milliers de séparateurs, pas comme dans le cas de l'OP où les gens utilisent des virgules pour la notation décimale. Comme le copier-coller n'est pas autorisé, ce ne serait que pour les personnes qui veulent taper le séparateur de milliers, ce qui n'est généralement effectué que pour la lisibilité, mais vous devrez peut-être tester combien de personnes le feraient.
En général, essayez d'éviter les erreurs, c'est l'interface utilisateur de dernier recours à mon avis. S'il y a quelque chose qui peut être géré par la logique du système pour éviter les erreurs, cela devrait être la solution. Évitez également de les forcer dans un formatage particulier. Essayez d'anticiper la mise en forme qu'ils utiliseront, les micro-interactions et concevez votre système autour de cela.
Une question pour vous ... À quelle fréquence les gens vont-ils entrer des décimales dans ce champ?
Ma suggestion serait de formater le nombre par défaut afin qu'il s'affiche comme par défaut, lorsque l'utilisateur le voit pour la première fois, et toute entrée utilisateur va entre le signe dollar et le point décimal? Si vous l'implémentez de cette façon, toute entrée d'utilisateur est interprétée comme le montant en dollars, et si les utilisateurs ne saisissent jamais de montants décimaux, vous pouvez vous arrêter là.
Cependant, si vous devez tenir compte des montants décimaux, vous pouvez empêcher toute modification du montant décimal jusqu'à ce que l'utilisateur tape "." sur leur clavier, à quel point ils entrent dans la section décimale du champ. Pour résoudre votre problème spécifique, vous pouvez traiter "," de la même manière. Lorsque les utilisateurs saisissent "," sur leur clavier, saisissez-les dans la section du montant décimal.
L'interaction utilisateur suivrait donc comme telle ...
- Entrez le montant en dollars
- Clé "." ou ","
- Entrez le montant décimal
- Terminer
J'ai eu le problème avec une application pour les utilisateurs allemands dans le passé. Je m'en suis tenu à la notation par points (pour les ordinateurs) et j'ai écrit un js pour transformer toutes les virgules en points (pas besoin de taper le délimiteur des 1000, les j afficheraient des espaces pour cela). Je voulais m'assurer qu'aucune virgule n'atteint le serveur principal.
Les utilisateurs ont répondu différemment. Certains n'ont rien noté (par exemple, des non-Allemands). Certains ont été surpris, mais s'y sont adaptés (par exemple les utilisateurs de Bloomberg). Certains étaient confus et interrogés sur la virgule (par exemple, les gros utilisateurs d'Excel uniquement).
Attention: c'est exactement ce que j'ai fait. Je ne suis pas une personne UX qui peut juger si une telle approche est une bonne chose.
J'ai tendance à utiliser autoNumeric pour les champs de saisie de nombres, je le configure toujours pour accepter à la fois la virgule et le point/point/tout ce que vous appelez comme séparateur décimal, sans séparateur de milliers (sérieusement, qui devrait même l'utiliser dans entrée?) Malheureusement, même si vous le configurez pour accepter la virgule comme séparateur décimal lorsque vous collez un nombre à l'aide d'une virgule, il le supprime (j'écris actuellement un problème) ... Mais au moins sur la saisie au clavier, il se comporte correctement
Exigez que l'entrée ait un seul point suivi d'exactement deux chiffres, sans virgule. Mais permettez à l'utilisateur de taper plusieurs points et virgules dans le champ. Si ces exigences ne sont pas remplies lorsque l'utilisateur clique en dehors de la zone, rejetez l'entrée et affichez une erreur de texte afin que l'utilisateur doive supprimer manuellement les virgules parasites et mettre un point et le nombre de cents.
Une note peut être placée avant le champ: "L'entrée doit se terminer par .XX, comme $ XXXX.XX".
Si l'utilisateur tape des virgules mais est obligé de les supprimer manuellement, il n'y a aucune possibilité que l'utilisateur suppose qu'une virgule a été acceptée. Et comme le nombre de points et de cent est requis, l'utilisateur est obligé de voir que l'entrée comprend des cents.