# When is it a good idea to force a format in a text box for currency?

Is this a good idea to format a text box if it's only for currency? It makes sure the user does not enter unwanted characters, including the decimal character.

What I have now is this. For example, if the user wants to enter 50.25, it goes like this:

So whether they type "5025", "50.25", "50,25" doesn't matter. If you want to enter 50\$, you have to type "5000" or "50.00", etc.

Is this user-friendly / intuitive enough?

If I understand correctly, they have to enter the digits one by one from left to right. This is bad interaction design for the following reasons:

• It violates the principle of least surprise. Users see a text boxe, they expect it to behave like a textbox. The conventions may not be ideal, but you have to take them into account.
• There's a lot of work between what users have in their head and what they have to do before they see that on the screen. They have to scan the digits from left to right in their head and add them one by one.
• The state of the system doesn't correspond to what the users wants. In three of your wireframes (ie. three states in the flow) the price is completely different from what the user wants to achieve. The first has 5 cents, then 50 cents, then 5 dollars. If the five went into the dollar column immediately, that would be close to the target. If the user has to make 50 first, then 50.20 and then 50.25, that's a logical plan: it focuses on the big stuff first and then lets you finetune the details. Going from five cents, to 5 bucks and two cents to 50.25 is a roundabout way of getting to the target.

The problem is the fixed decimal point. It means that however you start everything in between is a valid (and often strange) value. If people fill in the decimal point themselves, they can type the vakue that they have in their head however they like.

My preferred solution in these cases is to have a smart interpreter that can handle most inputs, and to give immediate feedback on how you're interpreting the value:

download bmml source – Wireframes created with Balsamiq Mockups

The feedback should appear when the text box loses focus, and disappear when the user changes the value in the textbox. It uses green text for values that are understood, red for values that can't be parsed and orange for values that are technically legal but far from the expected value.

This also allows you to start simple: just force people to use a certain format and interpret it rigidly (and show them instructions), and enrich the interpreter if the field turns out to be important in the user's flow. You could even let it do currency conversion automatically.

If you want to enter 50\$, you have to type "5000" or "50.00", etc.

I think this question speaks for itself. There will no added value when you implement formatting behaviour like this and it can break users flow.

The expected currency-formatted output of 50\$ is basically when you type '50'. Let the users place the decimal separator where they want to - which is more natural and widely used solution to this kind of formatting.

currency input is a pain because everyone has different locales and expectations. (This is actually true for any kind of input). A solution I like (my liking this is not a good base for any usability standard) is the following setup:

Present 2 boxes with a decimal separator in between

``````   +---------+     +-------+
\$  |     0 0 |     | 0 0   |
+---------+  .  +-------+
``````

Users can type in 50 in the first box, and they get \$50. alternatively they can type in an additional 25 to get \$50.25. Because the input is now simply reduced to entering two integer values, this is very easy for validators and javascript code to handle.

The point is users don't have to worry about currency symbols, decimal separators, and even if their locale is different (for example, use a comma instead of a dot or place the currency symbol after the amount) the users will still be able to understand what they are supposed to enter.