Re: Opinion wanted

"Jack White" <no_spam@xxxxxxxxxxx> wrote in message
news:uq4MjRMYHHA.688@xxxxxxxxxxxxxxxxxxxxxxx
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.

You have still provided nothing special about your app that would show this
approach is more suited than others (as you claimed to have). In answer to
your other points

- "Users prefer your model". This is simply not true, users dislike your
approach with a passion. The fact that others have replied the same here,
saying they would uninstall such an app, shows that. It is not rediculous to
think a user would uninstall, I have done it before, especially as this is a
big problem when you're first getting to know the app. Your approach is also
largely discreditted for good reason and has very little use these days.

- "It is more coding work". It is not, you need to validate at some time and
it's pretty much the same amount of work. So does not lead to more bugs etc
etc. You're stretching on this one quite a lot I think, I'd just validate
multiple times and deal with it on the extremely rare chance it was
expensive to do so. Generally when it's expensive it's better to do it all
at once anyway to reduce database round trips (database lookups are likely
to be the reason something is expensive). And if it is a database trip that
is required then you have to do it when they push ok anyway because the data
might have changed in the mean time. So even if you validate at the time of
input you'll need to validate again anyway.

- "It is annoying for users to get multiple error messages when pushing ok."
This is true but it is not a valid reason to go with your approach. Just
give them all the errors in the ok message or show an indicator next to the
field to indicate an error. Problem solved. This is pretty much the same as
your approach but with the most annoying part of it removed. It has all the
advantages of your method with none of the disadvantages.

- "You have only heard one valid point from me". Well, you are not
listening. :-)

- "MS introduced Control.Validating for a reason". They introduce lots of
features for a reason. That reason is they need to provide a fully featured
language that caters to all tastes. They have provided other methods also,
presumable for no reason :-)

Using some sort of indication next to the field and giving all the error
messages when pushing ok would be the best approach imo.

Michael


.