# Dealing with dozen digit number inputs

I am building a game that involves money. Users have money. Interactions can be as large as a trillion (1,000,000,000,000) or as small as a few thousand. Basically, users set the price of land they own, but I don't want them typing out large numbers and being frustrated when leaving out a zero. What's the right way to handle a number input that can be both enormous and rather small?

I thought about doing it in units of millions, and users can set 10 (million) or 0.2 (million). Not sure how users would react to that interface.

To clarify, I am not seeking how to implement a value multiplier. Many of these answers do not involve a value multiplier.

## 5 Answers

Using words isn't a bad idea at all. It's the most 'easy to understand' way for everyone.

You can make a dropdown list after the input, containing:

• No unit
• Thousand
• Million
• Milliard

The "no unit" option is for small amounts. Plus you can give people the chance to manually type all the zeroes if they want (or even the mathematical abbreviations, like 2x10^6).

I made a quick example:

Before making this, I thought about a +000 button or auto-complete, but that's more complicated. Please let me know your thoughts, I hope this helped :-)

• A little complicated, but intuitive, optional, and not unenjoyable to use. Upvote, but will wait a day or two for other ideas before accepting. Dec 28, 2015 at 5:06
• Nice and clean. Up. Dec 28, 2015 at 5:44
• For those culturally inept like myself, "Millard" is the Traditional European long scale equivalent of the American "Billion". Dec 28, 2015 at 13:48
• And I thought Millard was some sort of lame joke on long number names. Dec 28, 2015 at 14:10
• Sorry for the confusion about milliard and billion. In Europe, a billion is bigger than a milliard (which is bigger than a million). But in America, everything is big, so they skipped the milliard ;-) Dec 28, 2015 at 16:56

Basically you want the user to avoid manually counting the zeroes one by one as occasionally they'll make a mistake.

From research: Double entry. As long as you disable cut'n'paste between the two fields, and hide the first value as they are typing the second so they don't manually copy an error either. This works for keystroke level errors, if the error's in their head it won't work, i.e. they think a billion is a million. https://faculty.unlv.edu/barchard/doubleentry/Better%20Data%20Entry%20APA%202008.pdf

This might be perceived as long-winded though.

From a paper by Thimbleby (http://www.chi-med.ac.uk/publicdocs/WP052.pdf) --> "Although the SI/ISO 31-0/ISO/IEC 80000 standards specify that numbers “can be made more readable by separating them into groups, preferably groups of three, separated by a small space” few interactive systems do this" - i.e. visually chunk the counting process, and could be done on the number input given a suitably adapted input widget

My own thought is to combine the above "grouping input" with a "wordy" version displayed underneath the current input value, so typing in 6800000 would print "6 point 8 million" underneath (avoiding using a '.' as that can cause readability problems itself) which the user could eyeball as a sanity check. This of course would need some i18n for different languages.

You can use edit field along with a slider to increase the money value, As its a game the user won't be putting an exact value and slider should work. You can also give multiple tap points in slider for fast selection.

Tap-able inbetween states and a custom entry filed along with a slider like below.

Also, limit the avlue as per the agem and if at one point the user can not put more money than a certain value, disable the rest (visibly as well as...)

EDIT: Just saw your question again and chances are your slider can become long so use something similar to the example below You can give a dropdown/tabs with Millions, Billions as options and slider adjusting vlaue accordingly

One approach is to allow users to type in the numbers, but as they do echo their numerical entry with a textual equivalent. This is similar to Max de Mooij's answer, except the user doesn't select the "billion" (or "milliard" :-), but the system generates it for them.

Thus, if the user types in the number on the left, the system generates the text on the right (in realtime):

• 1 => (nothing is generated)
• 1000 => "one thousand"
• 97000000 => "97 million"

Tricky case, but might be fine:

• 97000123 => "97 million, one hundred twenty-three"

A simpler version of the above approach would be to just state the highest value, and show the rest formatted. For example:

• 1 => (nothing is generated)
• 1000 => "thousands: 1,000"
• 97000000 => "millions: 97,000,000"
• 97000123 => "millions: 97,000,123"
• Interesting approach. I'd love to see this in action and test user's accuracy with and without it. Dec 30, 2015 at 0:12
• I do like the second part. Perhaps millions, 10 millions, 100 millions, billions, ect. Dec 30, 2015 at 1:18
• Obligatory JsFiddle: jsfiddle.net/60v7c58w/1 Jan 11, 2016 at 12:48
• Nice job @Knossos! Jan 11, 2016 at 17:01

I would recommend using a confirmation dialog after the user enters in their value.

Rather than make the user enter the value twice or interact with a drop down menu (I'm just not fond of that control in this scenario), you could simply display a confirmation dialog to the user after entering the value. This could be done every time or my preference would be if the value is over a specified threshold. This confirmation dialog could frame the value in terms like "You entered 2.5 Million, is that correct?". Using this language was suggested in previous answers and I agree with them that phrasing the value this way can improve clarity.

As a side thought, I would consider increasing the value of each unit of currency. This will lower the range of inputs the user will need to enter. For example, if the lowest currency cost is 3,000 units then perhaps it could cost 300 (or even 30). By increasing the value of each unit of currency, you help to lessen the issue that you are bringing up.

In my opinion this approach allows the user a quick entry, especially when performing small purchases but also gives reassurance to the user of the value entered. My last thought would be sure to insert commas or spaces as the user enters the value since this helps the value to be more clearly understood at the time of entering it in.

• Although this is a late answer and the other one has very many votes and useful images, this is a very simple and intuitive solution, and in the context of quick forms. For a slower pace form, Max is probably the correct answer. I'm very torn between the two, and may change my mind. Jan 2, 2016 at 22:11
• This is a good answer for low-volume, high value (importance) transactions... things people will do rarely but really care about. It's no good if you're going to be doing this 100 times a day (in which case you'll just get in the habit of clicking OK), or if it's only high value sometimes and is usually low value (same problem, people won't bother reading the confirmation). If you do it, though, try saying "Are you sure you want to sell this for 3 million (3,000,000)?" rather than "Are you sure you want to sell this for 3,000,000". Words are easier than counting digits Jan 4, 2016 at 16:40
• I see your point Jon. I agree that if the prompt is shown too often the user will quickly learn to ignore it. However that is the reason I recommended a threshold value so that the user would not be prompted for confirmation every time they enter a value. An appropriate threshold value would be one where values above it are used on a relatively rare occasion. In this scenario, I imagine they would not be selling or buying things valued at 3 million very often. Jan 4, 2016 at 18:06
• I have to change my answer, because in my particular situation, as well as many other potential situation, it will be frequent and users may ignore the confirmation. I still hope it gets some upvotes because some users that find this question may need this answer. Thank you SWHandyMan. Jan 4, 2016 at 19:49