validating input widgets

Question

[This may be a well-worn old question -- apologies if so, but I have no idea how to search for it.]

First, the background. (This is not the question yet.) Suppose I've got a GUI with an input widget where the user can input a number. And suppose I am allowing the user to type on the keyboard; I'm not constraining things utterly with a prescribed selection list, or +/- buttons to merely adjust an existing value.

Among other things, I'll probably want to validate the user's input, to ensure it's in the appropriate range. For example, perhaps the user is entering the desired speed for a motor, which is limited to the range 0 - 1500 RPM.

Now, there are sort of two general approaches to implementing the validation:

1. Let the user type more or less anything, but after clicking OK, if the input is not valid, pop up a warning dialog to that effect, forcing the user to cancel or try again.

2. Contrive to not even let the user type an invalid input in the first place.

And I suppose it's possible to do various combinations, like only allowing digit keys to be typed, but waiting until OK is clicked before checking the actual value.

In the first case, that warning dialog is arguably a nuisance. It's additional work for the programmer to code it up, and it's an interruption for the user, who has to stop and think and figure out what to do next. (OK? Cancel? Or what?)

But in the second case, there's a subtle potential problem, too. Suppose the current value is, say, 160 (which is well within range). Suppose the user wants to change it to 170. Suppose the user chooses to do this by clicking to set the text cursor between the 1 and the 6, and typing 7 and then the forward-delete key to delete the 6.

But of course this means that for a moment the dialog will say 1760, which is out of range, so this input sequence is disallowed.

So in the second case, which seems generally friendlier in many respects, there's this sort of bizarre hidden constraint on what the user is allowed to type. Occasionally when using such input methods (I wish I could remember a better example), it's been like a miniature impromptu brainteaser puzzle, to figure out a reasonably minimal sequence of keystrokes sufficient to change the value I have into the value I want, without ever passing through any intermediate states where the instantaneous displayed value is disallowed.

So, now, the questions: (1) Do these two rather different styles of input validation have names? (2) Are there other tradeoffs between them, beyond the two I've mentioned? And, (3) if the second method is preferred, is the problem of having to solve occasional little puzzles as I've described something that isn't expected to come up very often, or that users will just have to put up with, or what?

Answer 1

Even though most of the literature and articles on validation is in the context of form input, I think that you can pretty much handle most of them in the same way on widgets.

For example, here is an article from the NNg group withe some guidelines on How to Report Errors in Forms that applies some of the concepts that you have described.

The example where you provide instant feedback to the users as they are entering the value (either by preventing it or prompting that it is invalidate) would be considered inline validation, where the interactions occur at the point of input. Before graphical user interfaces many of the input controls were physical devices, so the act of preventing you from entering values seems to mimic the physical behaviour (e.g. volume control that you can turn any further indicates maximum or minimum level).

Password setting is a common design pattern where the user experience is improved by allowing users to see what the criteria for a strong password is, or indicating the relative strength of a password while the user is entering it into the input field. It covers the case where the user is in the process of entering information, but not preventing them from completing the task as they have not indicated that they have finished (and may not have a way to do so other than to click the submit button).

I think depending on the complexity of your widget (and if it is a widget I assume it shouldn't be), there might be reasons why you want to validate at the end rather than the typical inline validation. If you have lots of input fields and you want the user to get through them quickly, having them address issues one at a time when there are dependencies on other input fields can create a rather confusing experience. For example, if the input of one field depended on another field, and when you make an error in one field you have to go back and correct another field. This can be confusing for the user because in their mind they have already completed one field, and now they have to go back and redo it again (i.e. the completion status is not final).

Hopefully this has answered your first couple of points. I think the best solution is to really understand the data that you are working with and test it out thoroughly with the users. That way you have a much better chance of coming up with something that the user is not going to hate (and maybe they will like). You never really know what the user is willing to put up with, and hopefully you don't have to design based around those requirements.

Answer 2

I recommend either to show the allowed range for the input from the beginning or do real time validation. It is bad UX to verify inputs only after ok is being pressed. For the second part you can let the use input a value that is not widthin range like 1760 or even 17000 but mark the input red and disable the ok button. This is where the shown allowed range will come in handy for the user to be informed in realtime and correct the input to respect the requirements.

Another option would be to make the input autodelete when the user returns to modify it to avoid incorrect input but it wouldnt work if the values are somewhat incremential like im testing 160 and 165 and 170 and so on.

Answer 3

I agree with Cristian. It would be better to show the input range of the text field at the beginning. Another way could be to specify the input range in the "Placeholder Text". Still, if the user enters invalid numbers, I would recommend highlighting the box with a red color. It's one of the Usability Heuristics to inform the user about the error clearly and at the right time. Imagine how frustrating it would be for you to fill the text box and realising that the text is invalid only after clicking the OK button.

I can understand that it would be challenging for the programmer but there are a lot of modules available for JS that helps in making this feature easy in implementation.