How to deal with superfluous numbers in input text fields?

Question

I'm working on input textfields for lab assistants, e.g. a textfield to enter a temperature value (in a custom designed UI, not a web-site). Users don't have to enter the Celsius or Fahrenheit unit, just the value. There is a lower and an upper bound, but as recommended in Text Field Validation vs Prevention, these are handled through validation, not prevention. If the user has entered a valid value (i.e. a value between lower and upper bound), he/she can press a kind of submit button, in order to acknowledge the new value.

My problem is that I don't know how my UI should deal with superflous input. E.g., when one of my users enters "0015" for a temperature, this needs to be changed to 15.0 in my system. And how about superflous decimal precision? If I don't prevent a user from entering more decimal places than I have precision, is it okay if the system automatically rounds the decimals up or down (e.g. 37.48 becomes 37.5 after input acknowledgement)?

I'm racking my brain if users might feel uncomfortable when the system does this kind of automatic changes after input acknowledgement, even if they are logical and consistent.

Edit: Does anybody know what HCI researchers recommend on this matter?

Answer 1

I would tend to be of the opinion that a user who enters 0015 would not be surprised if the input automatically changes it to 15.

They will likely also not be too surprised to see 15 be changed to 15.00. That said, they may then be aware the required number can be input to 2dp after the fact, which isnt best practice in the strictest sense.

Although users are also likely to realise when rounding is happening, such a change to the underlying value (and not just the format) should be accompanied with a clear explanation this is going to happen, before any rule is applied.

With this in mind, wherever there is an input format requirement it is generally a good idea to either provide the input field with an initial place-holder value in this format, or a note next to the field to inform users what the format is, or both.

Answer 2

Generally, it creates the fewest problems (collision with user input) to wait until a field loses focus. Then format the data - provided it's valid - to your specifications. Specifically, remove any leading zeros and round the values to two decimal places, given this example. I wouldn't worry at all about imposing this on users as long as it is consistent. Most people will quickly get the hang of it.

If you are going to constrain a value within a range, it would be great in your labeling to indicate this, e.g. "-20 to 100". Nothing is more frustrating than having some warning pop up after the fact when it could easily be handled up front. If the user persists in entering invalid data, it's okay of course to escalate the warnings with more intrusive UI.

Answer 3

I'd look closely at the time when the user is informed about changes to the value entered: If you can follow the advice suggested in another answer to do validation when leaving the input field (not when pushing SUBMIT), the focus is still on the field.

Formatting changes are uncritical, I think.

Rounding, however, might be accompanied by a warning "14.35 rounded to 14.4" immediately below (or besides) the input field (such as a "passwords do not match" message you sometimes see in password change dialogs on the second password field). For this, you would need to reserve the space for the message in the form - I don't whether space is at a premium in your case (don't make the form layout flicker).

Answer 4

There are three different areas that you can try to address the problem. The core principle here is to make sure that the result matches as closely with the user's expectation as possible. So here is what I would propose:

1. Before user provides an input, show what the result might look like. You can do this as a grayed out example value in the input field, or as a label below or about the input field.

2. During the value input process, show a clear transitioning or notification/messaging to show that the conversion is taking place (at least the first time). That way the user can see the change taking place as it happens, thereby minimizing the chance of realizing it later or not being able to make the correct adjustments.

3. After the input, provide confirmation for the user input and the resultant system output so that the process has been captured in its entirety (at least the first time). That way the user understands the change from the beginning to the end, and can opt to make adjustments to their behaviour in the future.

Which combination of these strategies you apply depends on the exact design of the interface and the interaction, but the principle of catering for user behaviour and helping them to use the system better by matching their expectation is the same.