Best way to validate modal dialog fields?
I often need to have modal dialogs to edit properties or configuration settings for an application, but I'm never very happy with how to validate them and present the validation results to the user.
Choices and tools are usually: -
-
Create an interface so that invalid options are simply not possible - that is, using "Masking", the range limits for spin-edits,
-
Try trap errors as they are found - immediate dialogs or feedback when the user has an invalid value entered somewhere (although, because it might be due to an incomplete entry, it might be visually distracting)
-
Error detection when changing control focus
-
Confirm the full dialog when OK and clicking the box showing what is wrong.
No.4 is generally the simplest and fastest code, but I am never very happy with it.
What good methods have you found for this?
While this question is fairly general, the ideal answer would be easily implemented in Delphi for Win32 ...
source to share
As with everything, it depends. :) I'm trying to look at some of them from a user perspective.
Number 1. I don't like masked changes personally, but things like spin edit range limits, pre-filled combo boxes, etc. make a lot of sense for a general sanity check, and it makes life easier for the user.
I think number 2 can make using the dialog painful for the user. They may not enter information in the order you think they are, or they may leave an incomplete field and return to it at the end.
I use a combination of 3 and 4 to test.
Depending on the field (like the value you want), I can check it on every key press and disable the OK button if it is invalid. You can get fancy and change the color of the bad box or use some other kind of validator control. This is obvious to the user and does not interrupt their "flow".
Things that are not easy to check on the fly (for example, calls to the server) are executed once, when the user clicks OK.
source to share
Just an observation, but I've seen many users populate dialog boxes (especially complex ones) and they DO NOT use the TAB key. They tend to click on / on the edit combos radio buttons when they “think through” the answers or read from the scattered documentation. This order will not be what you thought it would be! We as programmers hope logically (captain, Spock said), but users are good ...
One way that is good (but takes effort) is to have each editor check itself, either on change or on exit, and it just changes color if invalid. Your "OK" code routine is a simple matter of iterating through the control list and setting focus to the first one that reports itself as "invalid" until no one else does.
I work in the aviation industry with a special focus on credit card materials and I have TTicketNumberEdit, TCardNumberEdit, TExpiryDateEdit, TFormOfPaymentEdit, etc. works well because some of them are not easy to validate. As mentioned, you need to put in the effort in the beginning, but it pays off in difficult dialogues.
source to share
I think N ° 4 is the best way to do validation, in addition to being the easiest and fastest to code, you have all your validation logic in one place, so if you need to connect to a database compare 2 + inputs, etc ... everything is done only once,
While:
N ° 1: this can be an implementation nightmare in some cases and for update N ° 2/3: you should be aware of all UI events related to validation, input changes, focusing, .. -> heavy coding and difficult to debug
source to share
The JVCL offers a set of input validation components (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 similar functionality in dotNET, but I've never used it.)
While I like the concept and have actually used these components in several dialog boxes, I don't really like the implementation: it's CPU usage hang and the predefined validators that come with the JVCL aren't really useful. Of course, having access to the jvcl svn repository, I could just stop complaining and start improving the components ...
source to share
Don't forget to take a look at Jim's great session: Stop Annoying Your Users!
He has a verse about input validation ...
source to share
IMO option # 1 is of course not optional, and the interface is simplified as much as you can, while still allowing the user to enter the details required for the application. However, I don't like using masked changes. If I want the user to enter a number, for example, I just use a textbox and then try to parse the number as I go to store the value of the field.
For direct verification, I only use # 4 unless there is a special case that requires one of the other methods. I like to let my users change 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 is a mistake in their input. I help them if possible though (that is, if the form field is empty or invalid and they click OK, I will focus / select the offending field after the error message appears).
Run # 2 in a Windows Forms application is rarely removed on its own, so I would simply avoid it altogether as a primary validator. However, it could be effectively combined with # 4, but I think it would be overkill in most cases.
source to share