Users entering the wrong decimal separators for US$ amounts

Question

I have an application that accepts a dollar amount in $USD. Unfortunately, some people are foreign/visitors to the US and type in amounts with commas instead of periods: they format the number as XXX.XXX,00 instead of the US format of XXX,XXX.00. The different expected formats are causing issues. Even though the text input field is showing the "$" as a field prefix and I have a placeholder of "USD", people are still typing the wrong format.

Example:

Expected US: 345.60
User Enters: 345,6
accounting.js translates to: 3456.00

The user then pays $3456.00! This is obviously not good and a huge mistake. At this point, I'm thinking it's very bad for me to even try to modify the text entered. Instead, I should force the user to type in the format correctly (exact). I can easily add a format/error message below the text field which describes the correct format in more detail with examples.

If I force them to type the correct format:

• Should I allow commas?
• Should I remove commas automatically from input?
• Should I throw an error when a comma is used?
• Should I throw an error when a decimal is not used?

Note: I'm forced into the USD $ format only at this time. Decimals are 99% common, but not required for the transaction to take place. I'm looking at using a regular expression to give the warning, such as /^\d*(\.\d{2}$)?$/.

Answer 1

Let's talk for a minute about user expectations and magic.

A user comes to your tool with certain expectations, and not every user's expectations are the same. You're seeing this first-hand. Culture, up-bringing and life experience all shape how a user will interact with a tool, opening a vast array of expectations to potentially meet.

One expectation almost every user has, however, is that when an illusionist or magician does a trick -- say, picking a card from a card deck -- the illusionist is always going to guess their card correctly.

Put another way, if your tool is going to automate something, and going to guess what the user meant to type, it needs to get that guess correct, or the user will end up disappointed or frustrated.

As you stated as well, they may end up overcharged which, if your system changed what they entered without their express desire and increased the amount, could make you legally responsible for the overcharge and get you in trouble.

To guess or not to guess; that is the question. So, we have two courses of action to choose from:

Option 1: Analyze what's typed in and fix it

In this case, you may need to look for a solution that can better accommodate all of the edge cases you're seeing. If accounting.js isn't correctly reformatting the text, you may need to do something more custom.

Enter the regular expression.

What you'll need to do is figure out all of the patterns you might encounter, which are correct, and which need to be changed. When we start looking at common cases,

 - ###.###,## > ###,###.##?
 - ###,###,## > ###,###.##?
 - ######,## > ###,###.## or ##,###,###? 

It starts getting tricky pretty quick. To do this you'll need to do enough testing to know if your test and replacement patterns are getting it all right, and you'll need to watch out that new patterns don't emerge.

As well, if one of your patterns incorrectly changes the content, the user might not notice you've updated the amount (or, when you ask them to confirm the updated value is what they meant, they could miss an important change) and end up paying the wrong amount. What's more, if you did it for them, you might be legally on the hook.

Option 2: Guide them to the right formatting

This option will take a little less work and be safer from a number of standpoints. It's probably also more likely to end up in a pleasant user experience.

Here, still look for a strangely formatted string. Too many periods, too many digits between commas, a comma delimiting the final two strings of numbers, things like this.

What'd I'd suggest is using some implementation of live field validation to confirm that they're formatting their input correctly. When they type something strange, click out of the box, or try and submit the form, make sure to process the string to flag any of the tests you're looking for. If it fails a test, display a message next to or below the field (have a look at some of these images for ideas of how to display the messages) that explains specifically what looks strange.

Don't change anything automatically -- ask them to do that themselves.

Check again as soon as you can whether they've made correct changes. Ideally do this before they have to hit the submit button again, when they focus-off from the field for example. If it's all good, display a message (in a friendly success color like green or blue) that tells them they successfully fixed the error. If they need to try and fix it again, re-display an error message, and indicate that you checked and they still have more to do.

Oops, looks like it's still not quite right. <error mitigation message follows.>

This way, they know they still have work to do and the form is explicitly asking for follow-up action.

Edit: In conclusion...

Consider the use cases in front of you and which option (or mix of the two) you feel you can implement to make the experience predictable and understandable for the user.

An interesting option that combines the two is the masking that @jjwdesign brought up in the comments. The form could either guide the user from the beginning how do do the conventions, displaying a subtle ___,___.__ in the field, or it might add/convert the punctuation as the user types a value in. We just need to be careful not to do this in a confusing way; as some point out throughout the comments on the page here, overriding a user's inputs can be disorienting.

Good luck!

Answer 2

Another option would be for the text field to ignore all non-numeric characters, and display appropriate formatting automatically.

For example:

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'

Answer 3

Show the user what's expected visually and show how the machine interprets the user's input.

My contribution to the brainstorm would be:

• Use a reference to the cheque-form of the old days :)
• Let the computer ignore all comma's and periods that the user enters (for that matter: non-numerical characters)
• Show (if you're able to) an image in the background of your text-field, indicating the positions of the dollars, the cents and a period separating them.
• Use a mono-spaced font for the number
• Have the number right-aligned.

Now, as the user enters the amount, she'll see how the system interprets her input, automatically, with no script working (except maybe the script that rejects any comma's and dots):

-

Answer 4

You can do whatever you wish basically, as long as you provide a way to verify the input. I would personally dynamically display --next to the input field-- the amount at least partially written out, like

[ 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)

([] contains the input, () contains the verification. Note the usage of a non-ambiguous space as a thousands seperator.)

I don't say the method of interpreting the input I propose is the best one, but you provide an instant verification. To me (coming from a country with a decimal comma rather than decimal dot), it's intuitive to treat ,XX as cents, but to other people, ,XXX means units. Since an instant verification is provided, no harm should be caused.

Note: Just remember to submit both the user input (for later check what they actually wrote in case of doubt) and the verification (to be sure what the user saw and believed is thhe interpretation), and re-check that they are consistent when the form is submitted.

Answer 5

You could create two fields - 1 for dollars and 1 for cents. In this way you don't need any formatting logic and you can strip out any non-alphanumeric characters when you save to a database.

Answer 6

Locale is what this question is about. The fact that your users have to handle US dollars, does not mean they will do so in the locale of the 'owner' of this particular currency unit (USA). Date formats are another example of how different locales can render a value in ways that are ambiguous without knowledge of the locale the value was rendered in.

How a human expects to handle locale information depends on many factors which you cannot always predict as a programmer. What you can do, is give them enough information for them to know which locale they are experiencing the software in, or which aspects of that locale they have to deal with. In HTML, one way is to render localized placeholders that show the expected input format.

You have expressed your concern about people accidentally processing incorrect amounts of money. It may be good to request the user for final confirmation before processing the request. If you analyze the entered amount and it's in an unusual format, because it uses decimal and grouping separators that are different from those in en_US, you can always show a message that asks the user if they entered the correct amount.

Answer 7

The UX solution is to make it error free for the users no matter what format they're used to. Nothing more. Nothing Less.

I would recommend that you look into regex type solution:

1. make certain there are two digits after the comma (add a 0 if necessary)
2. then strip out all non-digits
3. then add the decimal point.

345,6 becomes 
345,60 becomes 
34560 becomes
345.60

Regardless of the process, or your back-end tools, make it easy for your users. If they expect to put in 345,6 (instead of 345.60) then let them.

Answer 8

The banking site I use in Belgium only allows you to input the decimal notation but not the thousands separator.

It accepts either a single comma or a single dot for the decimal notation, but nothing else can be input.

I've done some more testing of how they treat the input field.

1. You can only use , or a . once for the decimal notation, no thousands separator
2. If you type 4, then try to type 4,, nothing happens, same as 4,000. you can't add the .
3. You can type 4000.00 or 4000,00 and it converts both to 4000,00
4. Copying and pasting isn't allowed
5. 4,000 gets converted to 4,00 - this is an issue, certainly for a banking site, but it would only occur for people that type in thousand separators, not as with the case of the OP where people are using commas for decimal notation. As copying and pasting isn't allowed it would only be for people that want to type the thousand separator, which is typically only done for readability, but you might need to test how many people would do that.

Answer 9

In general try to avoid errors, they're the UI of last resort in my opinion. If there's anything that can be handled by system logic to avoid errors that should be the go to solution. Also avoid forcing them into a particular formatting. Try to anticipate the formatting they'll use, the microinteractions, and design your system around that.

A question for you...How often are people going to be entering decimal amounts into this field?

My suggestion would be to default format the number so it displays as by default, when the user first sees it, and any user entry goes between the dollar sign and the decimal point? If you implement it that way any user entry is interpreted as the dollar amount, and if users won't ever enter decimal amounts you can stop there.

However, if you need to account for decimal amounts, you could prevent any alteration of the decimal amount until the user types "." on their keyboard, at which point they enter the decimal section of the field. To solve your specific problem, you could treat "," the same way. When users key "," on their keyboard enter them into the decimal amount section.

So the user interaction would follow as such...

1. Enter dollar amount
2. Key "." or ","
3. Enter decimal amount
4. Finish

Answer 10

I had the problem with an app for German users in the past. I sticked to the dot notation (for computers) and wrote a js to transform all commas to dots (no need to type the 1000s delimiter, the js would display whitespaces for that). I wanted to make sure that no comma reaches the backend server.

There were different respones by the users. Some did not note anything (e.g. non-Germans). Some were surprised, but adapted to it (e.g. bloomberg users). Some were confused and asked about the comma (e.g. heavy excel-only users).

Warning: this is just what I did. I am not an UX person who can jugde if such an approach is a good thing.

Answer 11

I tend to use autoNumeric for number input fields, always I set it to accept both comma and dot/period/whatever you call it as decimal separator, without any thousands separator (seriously, who whould even use it in input?) Unfortunately even if you set it up to accept comma as decimal separator when you paste number using comma it just drops it (I'm currently writing issue)... But at least on keyboard input it behaves properly

Answer 12

Require the input to have a single dot followed by exactly two digits, with no commas. But allow the user to type multiple dots and commas into the field. If these requirements are not met when the user clicks outside the box, reject the input and show a text error so the user must manually remove stray commas and put a dot and the number of cents.

A note can be placed before the field: "Input must end in .XX, such as $XXXX.XX".

If the user types any commas but is forced to manually remove them, there is no possibility that the user assumes a comma was accepted. And since the dot and cent amount is required, the user is forced to see that the input includes cents.