Re: Opinion wanted

Tech-Archive recommends: Speed Up your PC by fixing your registry

I guess we're going to have to agree to disagree. Because most people don't
agree with you, and you're not going to change your mind.

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).

This is not a ridiculous assertion. I wouldn't use a product that did this
unless I was forced to by my management. The fact that *you* don't agree
with this doesn't mean it's not true.

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.

ROFL. Not very user-friendly, are you?

By the way, I did a poll of 15 of my users, and they said if I implemented
something like this, they would vote me off the island.

Robin S.
-----------------------------------------
"Jack White" <no_spam@xxxxxxxxxxx> wrote in message
news:uq4MjRMYHHA.688@xxxxxxxxxxxxxxxxxxxxxxx
If I had the time I'd provide a laundary list of issues that you likely
haven't considered but I'm sure everyone will still be attending the
same church next week.

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.



.

Quantcast