Best way to add an amount multiplier

Question

I'm working on a financial web-application, and in some pages, the user has to fill an amount. We are dealing here with large amounts, and they are generally thousands or millions of $ / €.

In previous versions of the application, the pages contained a text field, where the user filled the amount value, and a radio button to choose the unit (K, M or B, where M was selected by default), like that:

^{download bmml source – Wireframes created with Balsamiq Mockups}

But now, we decided to remove the radio buttons. The text field now accepts values such as 120 M for 120,000,000. However, we faced some situations where the user simply filled the text field with 120, and did not define the unit, which makes the amount to be 120 and not 120,000,000.

One solution we may develop is to have a client validation that forces the user to put a K, M or B in the field, so he will have to input 120 M and not 120. However, what I don't like with this solution, is that the user will not be able to fill a precise amount (such as 120,250,500, or he will have to write 120.250500 M or 120250.5K which is not really great I think).

Another idea is to have something like an auto-suggestion in this field that selects the M by default (a little like in the Google search field, when you start to type something). This way, if the user does not fill any amount, and just type tabulation, the field will automatically add the M to the amount.

I prefer the second solution, but maybe there is a better way to implement this feature...

So, what are your suggestions?

---

Edit, regarding the current answers

Here is another idea: I let the user inputs a value, using eventually the K, M or B suffix. I add a visual indication of the real amount just below, so the user can double check if the input is correct.

If the user does not add any suffix, I display the value in red, with a little warning icon (and a tooltip that explains what happens). Something like that:

^{download bmml source}

What do you think of that?

Answer 1

This is very dangerous ground.

The radio buttons not only make the input easier, they also serve as a sanity check for the user who gets a visual confirmation of the sum he typed in. I would bring them back. The new functionality you developed is excellent and it should stay. Of course, it should interact with the radio buttons, and once the user had typed M, the radio button should reflect that, and vice versa.

To be on the cautious side, I'd also provide an explicit read-only indication of the sum. It would also help to clarify that having K both in the input and the radio button doesn't mean that it's 120KxK, but it's the same K.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 2

How about showing a live preview of the inserted value under the input box along with help information about the available multipliers?

Answer 3

I'd use the full number in the text field, but place thousands (or ten-thousands for Japan) separators as a visual indicator, plus a way to type large groups of zeros effectively, for example by pressing k or m:

User presses      Widget shows
1                 1
0                 10
k                 10,000
5                 10,005

If the cursor is repositioned or the widget loses focus, it should revert back to regular text edit (you can either remove the thousands separators then until the control is blurred, or hack something that skips them during cursor movement and edits); "quick entry" mode is (re)entered when the widget is focused while empty or when the entire contents of the field are marked and will be overwritten by the first keystroke.

Answer 4

Instead of having to clik on a radio button and then in the field why not mutualize these 2 actions in the selection of a case in a matrix. User clik on the correct field (K, M, B ... ) and enter his number as wanted. enter 36 in the M field = 36,000,000 enter 5123 in the B field = 5,123,000,000,000

Example below :

Answer 5

I have seen this feature on numerous systems and typically the field will change to display the actual number to be entered when the user navigates away from the field. For example, entering 120k would cause the field to show 120,000 once the field has been tabbed or clicked away from. This way, there is no ambiguity as to what value is being entered (assuming that the field is not the last one to be entered, or there is a way for the user to review their input before committing it).

Note that some financial systems such as Bloomberg take M for thousands (as in Millennium) and MM for millions (i.e. a thousand thousands). Is there a danger that your users could enter M for a thousand and get a million instead? Do you need agreement on the abbreviations to use, or maybe have a user setting for this??

Finally, make sure it can support negative numbers used with the abbreviations, and I would suggest still supporting decimals as some users will expect this, e.g. -120.5K would give -120,500.

Edit: One thing to remember is that the K, M and B are optional shortcuts for big round numbers, to save the user having to type a load of repeating zeroes and to avoid the risk of typing too many or too few. If the number to be entered is not nice and round or is a decimal, the easiest thing for the user is to type it in exactly as it is, without having to negotiate with an over engineered abbreviation system. Plus they might want to just paste a number into the field exactly as it is anyway.