Re: Are you as polite and diplomatic as COBOL?...

Kellie Fitton wrote: 
Hello EveryOne,

I am plopping a dialogBox on the screen for the endUser's data
entry processing --- however, if he or she enters the wrong
informations, or perhaps some illegal characters into the
editControl box for example, then I would like to bring their
attention to that fact and process some kind of alert message
appropriately, until the dialogBox captures all the Correct data.

However, I would like to handle this situation as diplomatically
and politely as possible, and without annoying or embarrassing
the endUser, especially if I want my softWare to be userFriendly.
traditionally, I can think of seven methods that can deal with
this dataEntry processing redFlags, which they can be listed as
follows --- and executed without any particular order:

1). FilterOut and parse the illegal data on-the-fly while
    maintaining the silent treatment (Not Recommended).

2). Display an error message at the bottom of the dialogBox
    in a readOnly field withOut interrupting the process.

3). Play a .WAV audio file to sound a beep or a musical tune.

4). Use colourCode and change the colour in the editBox to
    highlihgt the improper or missing data.

5). Flash the colour of the titleBar of the dialogBox.

6). Display a messageBox (will interrupt the process).

7). Show an exotic belly dancing video (Highly Recommended).

I would greatly appreciate your thoughts and comments.

Regards, Kellie.

As the Doc said, people get paid money for this stuff. Ain't your instructor covered GIGO ? Validity checking - BIG TOPIC - and a very general outline follows.

Forget your list above, except for some combination of 2 and 6.
Don't get gimmicky, go easy on font styles and colour. It might look 'cute' to you but could drive your user mad ! Colours, if you use them, play it soft, go for pastel colours - that means using RGB rather than the same sixteen colour-names you can use with Screen Section.

Remember, at arm's length you are communicating with another human being whom you may NEVER meet. You are drawing a picture (Window/Dialog) which is supposed to communicate to them what your program is doing, or in the case of entryfields, what you want them to enter.

Bear in mind you have the ability to set properties to ONLY accept what you want :-

- UPPERCASE only
- UPPER and LOWERCASE
- numeric - latter will not accept the 'dot/period' for decimals

Think of some of the sign-on screens you've seen where mandatory fields are marked with perhaps a red asterisk.

Prompts on fields - so user knows what you want, e.g you might convey you want date enter as "dd/mm/yy" or just "ddmmyy", whatever.

Don't be 'picky' about Telephone or SINs - accept with or without intervening spaces or hyphens - programatically you sort out you've got what you want.

Prompt for errors as they occur, or store them - it depends largely on what you are doing - back to 'YOUR DESIGN' - not that of somebody else.
Example - i filled in a 'personal ***' for Microsoft 'something' - just lets you plug through with your entries. Hit OK and it spews out a message box itemizing each error. Actually I left it blank so it spewed out the whole screen !

One important thing to remember. Using a particular piece of software on a regular basis, say, like entering A/P invoices, end-users can become quite savvy what your software is asking for. So somewhat parroting old key-punchers, they can get into a steady document flow, very often not looking at you screen. They hit Pushbutton-OK and rely on you telling they have made an error somewhere.

Because of that input cycle, generally, but not always, it pays to accept the lot and then verify, rather than stopping and BEEPing at them for every mistake. So you point out Error 12 say, that makes them pause before hitting the OK-Button again, to see if they can spot any others before you do further feedback.

Didn't have too much choice in the old Screen Section days really, but one style used to be :-

Line 24 - Instructional messages
Line 25 - Error Messages - perhaps White on Red and even BLINKing

You could emulate that approach - but it's no big deal to display a traditional Windows Messagebox - it's all there for you with APIs - take a gander at my Messagebox class that I gave you in my \copylib. Just translate the GUI invokes to Win API functions. Naturally this is a case where you would CALL KelliesMessagebox using parameters returning xxxxx. Note : Regardless of whether or not I need confirmation I always get back a Pushbutton value from my Messagebox for consistency in the invoke using and returning xxxx

So much more one could write on this Kellie - hopefully above gives some clues. Let me reiterate. You are COMMUNICATING with an end-user; be objective and try and think how you would view the screen you designed, if you were on the receiving end.

Jimmy
.

Quantcast