1. catch 22
I have onLostFocus set in order to edit an input field when tab'ed away from
or mous'ed away from. I also have an 'abort' button if the user gives up on
the screen. The problem is that the onLostFocus event gets processed before
the button press and my program tries to edit the left field. So I guess i'd
like to get the button press event before any other events. Is this
possible? Or how can I handle this?
...george
2. Re: catch 22
On Thursday 16 August 2001 10:53, George Walters wrote:
>
> I have onLostFocus set in order to edit an input field when tab'ed away
> from or mous'ed away from. I also have an 'abort' button if the user gives
> up on the screen. The problem is that the onLostFocus event gets processed
> before the button press and my program tries to edit the left field. So I
> guess i'd like to get the button press event before any other events. Is
> this possible? Or how can I handle this?
I think Derek mentioned this earlier, but I'll put it in my own words:
Since in Windows (or other GUI) the user can enter data in whatever
order they like, validating an entry at the time of entry is a bad idea.
Validation and/or rollback should be done on completion of the entire form
(screen) at the time the user clicks the "OK" or "Cancel" button.
Trying to validate one field when the contents of the other fields can
be changed is fruitless.
In addition, it is generally a poor idea to have much validation going on,
anyway. The normal "windows way" is to, whenever possible, limit the
user to only those options that are valid, thru drop-down menus,
checkboxes, radio button choices, calendars, etc.
Regards,
Irv.
3. Re: catch 22
Irv, I understand what you are saying but I basically disagree with that
approach (that was the way it was back in 1960 with IBM 3270 stuff). For
example on a customer entry screen you don't know what the valid entries
could be until you know who the customer is(i.e some demand PO's others are
only COD, and so on). I would also think it would be irritating to a user to
enter an entire form and not fuss at them at the point of entry but have a
bunch of edit errors blown back at him.
Never the less, I'm getting the drift...
thanks...
...george
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Thursday, August 16, 2001 12:23 PM
Subject: Re: catch 22
> >
> On Thursday 16 August 2001 10:53, George Walters wrote:
> >
> > I have onLostFocus set in order to edit an input field when tab'ed away
> > from or mous'ed away from. I also have an 'abort' button if the user
gives
> > up on the screen. The problem is that the onLostFocus event gets
processed
> > before the button press and my program tries to edit the left field. So
I
> > guess i'd like to get the button press event before any other events. Is
> > this possible? Or how can I handle this?
>
> I think Derek mentioned this earlier, but I'll put it in my own words:
>
> Since in Windows (or other GUI) the user can enter data in whatever
> order they like, validating an entry at the time of entry is a bad idea.
> Validation and/or rollback should be done on completion of the entire form
> (screen) at the time the user clicks the "OK" or "Cancel" button.
>
> Trying to validate one field when the contents of the other fields can
> be changed is fruitless.
>
> In addition, it is generally a poor idea to have much validation going on,
> anyway. The normal "windows way" is to, whenever possible, limit the
> user to only those options that are valid, thru drop-down menus,
> checkboxes, radio button choices, calendars, etc.
>
> Regards,
> Irv.
>
> >
> >
>
>
4. Re: catch 22
On Thursday 16 August 2001 14:18, George Walters wrote:
>
> Irv, I understand what you are saying but I basically disagree with that
> approach (that was the way it was back in 1960 with IBM 3270 stuff). For
> example on a customer entry screen you don't know what the valid entries
> could be until you know who the customer is(i.e some demand PO's others are
> only COD, and so on). I would also think it would be irritating to a user
> to enter an entire form and not fuss at them at the point of entry but have
> a bunch of edit errors blown back at him.
Then the "Windows way" - which isn't all that bad, after all - would
be to not even SHOW the other possibilities until the customer had been
selected. Somewhat along the lines of the tabbed control sample I sent
you some time back.
For example, you create a new order, and select a customer.
Based on that selection (actually, on what options are stored for
that customer) you either open the COD screen (no chance for
error there) or the P.O. screen, or whatever.
Since there are likely to be several differences in the types of info
you'll need for a COD order, compared to an open account order, it's
nice not to have to wade thru non-applicable questions. You cut down
on mistakes that way, as well as speed up the work. Someone who's
new to the system finds it easier to know what to do.
There's a lot to be said for simplification.
Regards,
Irv
5. Re: catch 22
Hi George,
welcome to the world of GUI! The experts in the field of User Interface
design (eg. Alan Cooper) have come up with an answer for this situation.
Basically the principles applied are ...
1) Let the user drive the application (and not the other way round)
2) Prevent the possible entry of bad data
3) Be accepting as possible until the last possible moment
In your situation, this usually means that either you do all the validation
at the press of the "OK" button rather than field-by-field, or if you do
validating field-by-field, you do not stop the user from leaving a field -
even if it has errors in it.
Try this method:
In the onLostFocus() routine, validate the field. If it has an error,
mention this to the user and record an error count ( or similar). When
telling the user about the error, do not use an interrupting style, such as
a message box, but instead do it quietly. Maybe a message in a special
message area on screen, or make visible a "You have errors!" button, that
when pressed will display the errors, (this can be a single button per
screen or one tiny button next to each field). The important thing is to NOT
interrupt the user's flow. Then when the user finally presses the OK button,
you either revalidated all the fields again, or just those that you recorded
as having errors. Now, if there are still any errors you can choose to stop
the program continuing on (a message box for example) until they are
corrected. Some people even argue that you should allow the errors to be
saved away on the data base and only interrupt the user when the data is
going to be used for something later on.
In conjunction with this method, set things up so that only "good" data is
possible anyway. In the situation of a customer id field, you might think
about providing a list of known customer's to pick from (if there isn't too
many) or a simple search feature that the user can elect to use at data
entry time.
Good GUI is hard to create if we have come from character terminal and
client-server backgrounds. But studies have found that there are some
techniques that are better than others.
The situation is becoming more blurred too as the Web based interfaces
become popular because a lot of the validation code is run on a server
machine and not the machine that the GUI resides on. Meaning that the
entered data needs to be sent to the server machine even if it is bad.
-------
Derek.
----- Original Message -----
From: "George Walters" <gwalters at sc.rr.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, August 17, 2001 12:53 AM
Subject: catch 22
>
> I have onLostFocus set in order to edit an input field when tab'ed away
from
> or mous'ed away from. I also have an 'abort' button if the user gives up
on
> the screen. The problem is that the onLostFocus event gets processed
before
> the button press and my program tries to edit the left field. So I guess
i'd
> like to get the button press event before any other events. Is this
> possible? Or how can I handle this?
>
> ...george
>
>
>
>
>
