28

I have a numeric input box, as part of a form. I'm implementing delimited splitting, to make large numbers easier to read. ie, 1000000 would become 1,000,000.

Would it be a good idea to automatically update the input with commas as the number is typed? So that typing 1,000,000 would show:

1
10
100
1,000
10,000
100,000
1,000,000

As the number is being typed.

Initially I thought it would be a neat feature to have, but I'm concerned it may be confusing. Would it be better to format the number when focus on the input box is lost?

Edit:

A similar question. These input boxes also have a maximum value that can be entered. If the user types a value outside the valid range, should the input instantly auto correct to the max value, or only do so when input focus is lost? If waiting till focus is lost, should you 'silently' change to the max value, or highlight the box with some kind of error display?

| improve this question | |
  • 3
    I don't know about formatting, but instantly correcting to the max value screws me up every time when I'm trying to change an already entered value to a different one. – Random832 Apr 29 '13 at 20:53
  • I personally never mix input with output, by all means accept the comma separator for input (you should be flexible for input, I've seen some systems even allow you to type "10k" for 10,000), but never enforce a rigid input format. If you want to display the values in a rigid output format, that's great, but there should be no obstacles for input (just validation). I wouldn't wait until focus was lost either, I would wait for the form to be submitted. – Lee Kowalkowski Apr 30 '13 at 9:15
  • 1
    Never auto-correct the user's input for them, they might miss it. They might be entering a 'correct' value into the wrong field, so they need your error message, and what they have entered (unmodified), to realise their mistake. – Lee Kowalkowski Apr 30 '13 at 9:16
  • You could also live preview the formatting next to the input field. Similar as Stack Exchange sites preview the formatted question or answer. – danijar May 18 '13 at 13:09
39

Do not update what users enter when they're still typing. It fuddles up their ability to edit as they type, and it makes the field a moving target. If you were to type 25000 straight, no typo's, no backspacing, it might make sense to format it right when you're done. However, what happens when you enter a 0 between the 2 and the 5? Or when you hit backspace?

Also, research into feedback in forms has shown that people slow down when the feedback is instant on each update. They will hit a key, wait for the system to give feedback, then perhaps hit another key. I think the same thing may happen here: add a number, check how the formatting shifts, add another number, check again.

A text input is a simple control to interact with. Numbers are simple enough too. Keep it simple and give feedback (i.e. change formatting or give feedback on wether it's within bounds) after a user has finished. To quote A List Apart: "...give feedback after the user finishes providing an answer. Or in situations in which people need help sooner, give feedback while they work toward an answer, but use an appropriate delay so premature error messages don’t frustrate them."

| improve this answer | |
  • I like this questions where all the helpers agree on the answer. We should consider merging. – Gildas Frémont Apr 29 '13 at 17:01
  • 1
    Or put the feedback external to the box, like text that appears underneath saying "Please only use numbers and decimal points" but doesn't affect the form entry itself. – fluffy Apr 29 '13 at 21:14
  • 1
    +1 for highlighting destructive effects of task interruption on task performance. – uxzapper Apr 30 '13 at 2:17
14

Firstly, the thousands separator is not common among all regions of the world. When in doubt the recommended solution (SI/ISO 31-0 standard) is to use a non-breakable thin space as a separator.

You also have to take into account that not all countries group by thousands. From Wikipedia:

  • In China, comma and space are used to mark digit groups because dot is used as decimal mark. There is no universal convention on digit grouping, so both thousands grouping and no digit grouping can be found. However, grouping can also be done every four digits: 123,4567.89, since names for large numbers in Chinese are based on powers of 10,000 (e.g. the next new word is for 108). Japan is similar.

  • In India, due to a numeral system using lakhs (lacs) (1,23,456 equal to 123 456) and crores (1,23,45,678 equal to 12 345 678), comma is used at levels of thousand, lakh and crore, for example, 10 million (1 crore) would be written as 1,00,00,000.

If you know the system of grouping that your customers are likely to use, I would automatically add in the separators (as is commonly done on ATMs or cash machines), but I would use a non-breaking thin space as the separator. You are probably fine using a thousands separator most of the time and simply switching to an alternative version if in India or any other country that uses an alternate system.

| improve this answer | |
  • The localization handles the comma placement in lakhs vs millions and the , vs . – rk. Apr 29 '13 at 17:26
  • @rk. Only if you know what the localisation settings are, and that is not always the case. – JohnGB♦ Apr 29 '13 at 18:02
  • 1
    Well that is a bad implementation of localization then, wouldn't you say? ;) – rk. Apr 29 '13 at 19:05
11

We had the same question and after a lot of heated discussion we decided to not format while the user was editing.

While the user type he can add grouping or decimal separators if he would like and as soon as he blurs we add them if the user didn't.

so the user can type

100000
100,000
100,000.00
100000.00

but as soon as he blurs we format it as

100,000.00

obviously without the decimal point for integers

As @Gildas wrote, you should consider culture settings as well.

| improve this answer | |
4

Be careful that this notation is not common for all users.

Simplified table of numbers formatting :

1000000   < nobody that cares about readability
1 000 000 < Sweden, France
1,000,000 < UE
1.000.000 < Germany

Is it going to be an amount of money ? Because if its so I would recommend you to input right to left (have a look to currency formatted cells in excel).

As a general rule the input has to be expected. If your user is not typing a [,] or a [ ] you should not display it in editing mode.

In the other hand you can format the data when not in editing mode. A good example is phone numbers. (Check contact information in your Facebook account)

Same thing for the maximum value, let her write what she wants and give her some information about the system limitations when relevant (remember that it is always the system's fault never the user's).

mockup

download bmml source – Wireframes created with Balsamiq Mockups

| improve this answer | |
  • 1
    The delimiter (comma/period/space/blank) is setup as part of localisation, so that shouldn't be a problem. Some of the inputs are currency, some are not. – John Apr 29 '13 at 16:54
  • in France, dot is not a thousands separator, the separator is a space. – Benoit Apr 30 '13 at 7:01
  • @Benoit, you are right, I edited my answer. – Gildas Frémont Apr 30 '13 at 7:07
3

Even more than just applying formatting during input doing anything to actively change the input during an edit is extremely user hostile.

ex Your system limit is 1,000,000 and your user attempts to change a value from 230,015 to 330,015; begining by typing a 3 with the intend of following up with a delete to remove the 2. With an immediate force value to upper limit function instead the value of 3,230,015 would immediately be slammed to 1,000,000 forcing the user to reenter the entire value from scratch.

Doing it immediately on the termination of editing isn't much better. ex as a typo the user enters 3300015 and tabs to the next field only to have their input replaced with 1,000,000 instead of just being flagged as an error allowing them to edit out the extra zero.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.