Best way of validating modal dialog fields?

Question

I often need to have modal dialogs for editing properties or application configuration settings, but I'm never really happy about how to validate these, and present the validation results to the user.

Choices and tools are typically:-

1. Design UI so that invalid choices are simply impossible - i.e. use "mask edits", range limits on spin-edits,

2. Try and trap errors as they're found - immediate dialogs or feedback when a user has an invalid value entered somewhere (although, because this may be due to an incomplete entry, this can be visually distracting)

3. Detect errors on change of control focus

4. Validate entire dialog when OK is pressed, and present message box(es) showing what's wrong.

No.4 is typically the easiest and quickest to code, but I'm never really happy with it.

What good techniques have you found to handle this?

While this question is fairly generic, an ideal answer would be easily implementable in Delphi for Win32...

Answer 1

I think N°4 is the best way to do the validation, in addition to being the easiest & quickest to code, you have all your validation logic in the same place, so if you need to connect to database, compare 2+ inputs, etc... everything is done only once,

While:

N°1: this may be a nightmare to implement for some cases & to update
N°2/3: you have to be aware of all UI events related to validation, input changes, focus, .. -> heavy coding & hard to debug

Answer 2

As with everything, it depends. :) I try to look at some of these from the user's perspective.

Number 1. I don't like mask edits personally, but things like range limits on spin edits, pre-populated combo boxes etc make a lot of sense for general sanity checking and it makes the user's life easier.

I think number 2 could make using the dialog painful for the user. They might not enter the information in the order you think they will, or might leave an incomplete field and come back to it at the end.

For validation, I use a combination of 3 and 4.

Depending on the field (e.g. required value), I might validate it on each key press and disable the OK button if it's invalid. You could get fancy and change the colour of the bad field or use some other kind of visible validator control. It's obvious to the user and doesn't interrupt their "flow".

Things that aren't as easy to check on the fly (e.g. calls to the server) are done once when the user hits OK.

Answer 3

The JVCL offers a component set for validating input (TJvValidators etc.). It marks fields that have no valid input and shows a hint to the user when he moves the mouse over that marker. (I think I read about a similar functionality in dotNET but I have never used it.)

While I like the concept and have actually used these components in a number of dialogs, I don't like the implementation much: It is a hog on cpu usage and the pre-defined validators that come with the JVCL are not really usefull. Of course, having access to the jvcl svn repository, I could just stop complaining and start improving the components...

Answer 4

Don't forget to give a look at Jim's great coderage session : Stop Annoying Your Users!

He has a verse on input validation...

Answer 5

IMO, option #1 should be done as a matter of course, not optional, and the interface simplified as far as you can take it while still allowing the user to input the detail needed for the application. I don't like using masked edits, though. If I want a user to enter a number, for example, I'll just use a textbox, then try to parse the number when I go to save the field value.

For direct validation, I use #4 exclusively, unless there's a special case that calls for using one of the other methods. I like to let my users modify their inputs if they change their mind, so they can make a mistake and go back and fix it on their own because they already know there's an error in their input. I do help them out if possible, though (i.e., if a form field is empty or invalid and they hit OK, I will focus/select the offending field after showing an error message).

Doing #2 in a Windows Forms application is rarely pulled off well on its own, so I would just avoid it altogether as a primary means of validation. It could, however, be combined with #4 effectively, but I think in most cases, that would be overkill.

Answer 6

Just an observation but I have watched a lot of users populate dialog boxes (especially complex ones) and they DO NOT use the TAB key. They tend to click in/on edits combos radio buttons as they "think through" the answers or read from disparate documentation. This order will not be the same that you thought it would be! We as programmers are hopefully logical (captain, said Spock) but users well...

One way that is nice (but requires effort) is to have each editor validate itself, either on change or on exit, and it simply changes colour if it is invalid. Your routine in the "OK button" code is then a simple matter of iterating through the control list and setting the focus to the first one that reports itself as "invalid" until none do.

I do work for the airline industry with focus on credit card stuff and I have TTicketNumberEdit, TCardNumberEdit, TExpiryDateEdit, TFormOfPaymentEdit etc. works well because in some of these the validation is not simple. As mentioned, you need to put effort in early on but it pays off in complex dialogs.