If I had the time I'd provide a laundary list of issues that you likely
I'd be very interested to see this list. Certainly you've presented
nothing compelling so far to support this technique.
That's because I didn't come here for that reason. To adequately explain the
details including the nature of my own app (which you mischaraterized
earlier) would take more keystrokes than I have the time for. Nevertheless,
here's a short dissertation on the subject and I hope I'm not wasting my
time. First, you seem to be hung up on the notion that users are going to be
hopelessly locked into some field which will annoy them to the point that
they're going to uninstall the program (a ridiculous assertion). Nobody's
talking about locking people into fields unless the data is currently
invalid. That doesn't mean they can't click the form's Cancel button nor
press the Esc key to restore the field to its previous value. Nor does it
mean that they can't use any menu item or hotkey so long as it's viable at
the time. Nor does it mean that you lock them in if a field contains valid
data but it fails cross-validation with one or more other fields (since
users may need to correct the other field to fix the problem). What it does
mean is they can't proceed to the next control on the form or use any
impacted menu item (or hokey) until they correct the current control
(provided that control is invalid but invalid in isolation). Why should
users be surprised by this (contrary to your assertion). If the data is
invalid then a message to that effect surprises no one. It's not
unreasonable to ask them to fix it before moving on and they shouldn't be
annoyed because the app is preventing them from inputting erroneous data.
That's their fault. In fact, how does your own proposal save them from this
"tyranniy" of four-legged tables that bark. It doesn't. It only defers the
"annoyance" until later on. In fact, waiting until later is even more
annoying if you're flooded with multiple errors (or even just one error)
that should have been identified earlier. It's disruptive to the input
process which naturally proceeds from control to control. If no error is
displayed when you leave a field then you can safely assume it's correct and
move on. This is the thinking pattern of most people in spite of your
claims. When you look at the screen you instantly know that all fields
contain valid data (assuming no cross-validation errors) except (possibly)
the current field. The user's mental picture of what's going on is therefore
clearer because the info they're looking at is error-free. This is
especially true for data-input programs where users are entering large
volumes of information and constantly checking things on screen.
Nevertheless, for all users in general, it assists in your ability to input
subsequent fields where decisions may be dependent on previous fields which
you now know are in good working order. This is sound and ergonomically
correct. Doing things the way you suggest only confuses users if they move
through a bunch of fields without issue only to find problems when they
eventually press OK. I'd be asking myself (and have many times) why it
wasn't caught when I first entered it. I'd also be irritated (and have been
many times) if I kept pressing OK after correcting an error only to find
more errors (something that happens on a lot of web pages these days). Or to
suddenly see my screen lit up with error indicators as someone else
suggested (turning a simple error-handling process into a complicated one).
Depending on the nature of the control that's in error, the type of form
involved, and possibly timing issues (when and how the data was entered),
you may even have to track down the original info again (to fix your
errors - I've seen this) or re-enter other fields all over again, possibly
throwing the entire form away itself (since the error may force you to
re-evaluate what you've entered into other fields and possibly discard the
entire form). If trapped immediately however then you wouldn't have these
problems. It's also simpler and cleaner in code to trap errors as they
happen rather than iterating through all controls at once later on. This
approach isn't optimal for several reasons, not the least of which is that
you typically wind up calling the same loop multiple times in the presence
of multiple errors (where the user corrects only one error at a time before
pressing OK again, causing you to start your loop all over). This causes you
to validate controls that have already been validated.(potentially expensive
but unecessary in any case) unless you plan on introducing overhead like a
flag for each control (even if you set it at the time the field loses
focus). You also have to store the error itself (assuming this isn't
doubling for the flag) and possibly other info. Regerdless of what system
you come up with, it usually means more overhead, more work, more code, more
complexity, more (expensive) mainteance, more (potential) bugs and so on.
Replicate this for many forms and compounds the problems. The issues run
even deeper than what I've had the time to discuss so it's really a
no-brainer as far as I'm conerned. It's also one that I've found most users
do in fact prefer in spite of your contention. Lastly, in spite of some
inconsistency in the framework for handling errors, MSFT nevertheless
introduced "Control.Validating" and cousins for a reason (have you read
this) so it's also more consistent with their own general approach
regardless of what they do in their own apps (which is not always consistent
either but they do in fact handle things both ways). The only point credible
point I've actually heard from you is that people sometimes get stuck in a
field that currently has invalid data. Yes it's annoying but it's also a
trivial issue that's easily corrected by using the Esc key to back out. It's
a tiny but necessary evil however (more of a minor nuisance really) and it
hardly restricts navigation if handled correctly. It certainly doesn't trump
the many reasons for it.
.