Best practice for desktop application input validation

Question

I've been reading through some of the other questions tagged with validation and similar. We have a Windows desktop application (WPF) that has many textboxes contained in a dialog that need to be validated, each one differently (needs to be a number, needs to be between 2 numbers, needs to be greater than zero, etc.).

We can't use the same UI that most website forms use when you try to Submit or move to another page, where some text is displayed (in red, for example) near the invalid fields, indicating both which fields are invalid and what is the expected input/what is wrong with the current input. In such cases, the height of the webpage is just extended to accommodate the additional text, if needed.

In our application's case, real estate is limited, so the controls and window cannot be easily resized. The question is, what are some rules/no-no's on validating the input during user interaction?

Do we change the values from incorrect ones to a default correct one? If so, when — on field exit, on dialog OK, or…? Tooltips seems to be a viable communication method.

Answer 1

To your main question...

Big No-No's around validation:

Automatically changing a value You should be notifying a user that a potential issue / mistake was made and suggest the right answer if you are able to do so.

In a case where there is a dependency between fields and if changing the value forces another field to update, again notify the user about the change to a previous field they filled out.

Not covering all use cases or misleading content/labels

If you are validating a field, make sure all use cases are covered. I've seen a lot of websites where field labels / notes ask for one thing but validation is very limited. Example: "Enter your email address", but validation only expects email addresses that end with ".com", ".net" and ".org"

Or... "Provide your IP address" but only allow IPv4 address and not IPv6

Not helpful tooltips

Visually change the styling of the field and not displaying any helpful text. Main issue here is with accessibility as some people may not even notice a color change.

Other common mistake is ... displaying the text "invalid value" or similar. This will keep the user guessing what they did wrong and that could get very frustrating.

Clearing values on error (Not saving form state)

Let me say that the larger the form it the less your conversion rate will be, forms should be small / short and only capture additional information you have not captured yet. Users are most likely to provide short pieces of the info.

Now, I've seen some older websites that don't save form state after an error occurs and forcing the user to re-enter information again. Save form state to help your form conversion.

Disabling action buttons

I've seen cases where "Submit" button is disabled until all fields pass validation. It may sound like a good idea at first, but you don't want your user to keep guessing why the button does not work and what they may be missing. It's ok to disable the button after initial submit and while the errors are shown (assumption that field validation happens on "keyup" so as soon as the last field passes validation - the button reactivates instantly).

Answer 2

Look this tutorial for validation rules: http://wpftutorial.net/DataValidation.html

The error message is inside the tooltip, but you can put the error message in a storyboard and animate it. Like showing up only, if an error occured. This is how inline validation is used at websites. Don't ask me how I did it. It's some years ago, but feasible. I think something like start animation if string box isn't empty. Hope it helps.

I miss the time, working with Sketchflow and Expression Blend - it's a great toolset..

Answer 3

WPF has a great Validation framework. I find it to be intuitive with many options. And it conserves screen space. It uses borders and optional tool tips.

Programming is not that easy but it is nice for programmers as it enforces rules at the data layer. The business / data layers does not have to care how enforcement of those rules bubble to the UI layer.

Many users are used to it. To me anything Microsoft does is a standard.

Validation

If you bind an Integer property to TextBox you automatically get integer validation.
In fact you need a converter for an empty TextBox to not send string.empty.

As for when do you coerce the value to a valid one?

• Start with a valid / default values
• Cannot do it on key down as > 10 would fail before they hit the second key
• Lost focus - when they leave the TextBox
• Lost focus or enter key
• When you click a submit / process button
• Don't coerce. Give the user feedback as to what is wrong / acceptable and make them enter a valid value.

They all have plus and minus

If you coerce a value that is based on other values you can get into a loop problem if you set it on lost focus.

Answer 4

WPF validation can be set up to highlight/tooltip-explain bad fields when they lose focus; that way the user's complete input is available. You can leave OK/Save disabled until all fields validate successfully, but a better approach (in cases where most/all fields start out blank and a user might forget to fill in one that's required) is to have the button enabled, but to validate all blank fields when it's clicked and only close if they pass, putting up the highlight on those that fail as normal. This way, you don't have the problem of displaying an irritating highlight on fields the user hasn't gotten to.

Alternatively, of course, leave the OK button disabled until all required fields are valid and non-blank, but only put up the validation highlight/tooltip once they've been focused at least once.

Silently correcting user input is not a best practice in most cases, as it tends to keep users from correctly entering what they wanted. And if you start with a reasonable default in the field, any changes should be assumed to be intentional, and so if invalid need correcting by the user. An exception to this, though, would be cases where an empty field is invalid by itself, but can be extrapolated to a reasonable default, in which case faded-out and/or italicized text within to indicate the default is useful. For example, a number of network-dependent applications like IM or torrent clients use stunserver.org as their default STUN/TURN server, and indicate this in configuration with a blank textbox that can be set if desired, but that falls back to the default when blank, and which displays the default as an example setting as noted.