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

Hi Kellie,

I have read this thread with some amusement. You are getting a plethora of
worthless advice and opinion, interspersed with a sprinkling of actual
nuggets.

As the Doc observed, the advice is worth twice what you paid for it. (That
particular piece was valuable).

Opinion presented as fact is still opinion.

It is gratifying to see that you think for yourself and, in the final
analysis, I think you will do whatever you want to.

Personally, I like your tooltip balloon idea and I don't think it is
gimmicky in a modern envoronment.

(If users can accept advice from a bloody talking paperclip, why not
floating Pooh Bear balloons that gently point out their errors?)

Continue to seek imaginative solutions, and continue to expect them to be
scorned by people of limited imagination.
(The most dangerous phrase in the English Language is: "We've always done it
that way." - Grace Hopper)

I'm making this single post here because you raised a point that I have some
experience with and it might be of some use to you.

See below...

"Kellie Fitton" <KELLIEFITTON@xxxxxxxxx> wrote in message
news:1114813666.325616.188440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Jimmy,
>
> Like I said many times before ---- sophisticated COBOL programmers like
> Kellie
> Fitton only uses bourgeois concepts and techniques, especially when it
> comes to
> designing a complex software system for business applications. :---)
>
> using a messsageBox to alert the user of a missing data or improper
> characters
> in an editBox is a bad programming idea ---- simply because it will
> pause the
> process of the dataEntry cycle, and forces the end-user to click on the
> button
> to confirm the message, before allowing him or her to continue to
> correct the error.
>
> The format of the Date that you have described above (yyyymmdd) is
> really passe
> and cannot be used in the graphical world application ---- the sign of
> the time right
> now is: "Date-And-Time-Picker" control window, it is very elegant and
> easy-to-use
> visual calendar, that allows the end-user to simply click and select
> the desired date
> or time, in a straightforward fashion without typing any thing. Very
> cool, you know.
>

About 7 years ago I was developing a windows application in London. The
system would be used by people from many European countries, some of whom
did not speak great English. They had trouble spelling English names so I
implemented Soundex searches and this was very popular and solved the
problem. (They could enter a name the way it sounded and the system found
the person immediately). I was pretty pleased with myself for coming up with
that solution (Soundex was not in common use on windows systems at that
time, and I actually researched and modified the opriginal algorithm before
implementing it.).

Flushed with success, I then decided (after discussion with a couple of
users) that a pop-up calendar for date entry would be just the thing...
These girls were used to dates in different formats and months and days were
always getting mixed up. Sometimes the month number would be wrong also.
(One girl used to count the months with her tongue on her teeth to arrive at
a number... I was stunned; never seen that one before...)

I started looking at date formats and realized almost immediately that the
old style mainframe formats were simply useless in this environment.
('passe' was the word I think you used, and I agree completely.)

Around this time I was starting to get into using ActiveX controls and the
thought occurred to me that MS provided a perfectly good calendar control
with Office. So I used that.

That meant that Office had to be licensed on every machine. Bad idea. So I
got a third party control ($100) that had no such limitation. Tied it to the
'gained focus' event on each date entry field and Presto! it popped up, user
clicked, OO COBOL accessed the day, month, century, and year properties of
the control, formatted them to 'dd-mmm-ccyy' (we were well aware that Y2K
was looming on the horizon), and placed the resulting string into the date
entry field. The control automatically validated the date and the whole
thing was pretty sexy. No more invalid dates.

I then needed something to handle date formats internally. I remembered an
old IBM mainframe sub-program I had written about 15 years earlier - I keep
copies of every 'utility' routine I write on every platform.( The earliest
one I have goes back to 1970 for an ICL 1900...:-) It deals with printing on
lineflow.) Located the old code, revamped it to take dates in any format and
convert them to any one of 8 other formats. It could also do date arithmetic
on two dates in any format. I used it to convert the dd-mmm-yyyy format from
the screen to something I could use internally and store easily on a
database. It was a simple matter to port it to the PC, rewrap it as a
component, and add it to the developing system.(There is an advantage in
keeping your code transportable as you have been advised before,
here...Sometimes you don't even know at the time you write it, what lies in
its future...)

I then made a few contextual additions to the popup and presented it to the
users.

Everyone under 25 loved it. But there were a few older ladies who hated it.
They were used to using the numeric keypad to enter dates and could do it
with their eyes shut.

What to do?

It needed both options to be viable. So, I produced another small form (the
same size as the popup calendar) that allowed entry of day, month, and year.
It could be keyed wihout looking at the screen as the entry fields
autoskipped. I added date validation using the internal component described
above, and wrapped the whole thing as a COM component. I now had two date
entry components. Placed them both onto a single form and used F2 to switch
between GUI (the calendar control) or text interface. So, a user who liked
numeric keypad would press F2 the first time a date field was entered and
the calendar popped up. The calendar instantly became text entry fields, and
from then on, whenever a date entry field was entered, the text version was
presented. The entry methods could be swapped at any tme using F2.

It was a big success and I have used this approach in all subsequent systems
that need date entry.

I have related this story to reinforce some of what the Doc and others said
about interface requirements being totally dependent on users. Sometimes you
think you have it right, then someone comes along and points out there is an
alternative that wasn't considered. Using your imagination is an essential
part of designing any user interface, and it looks as if you are not lacking
in that department.

Build your balloons, sell them to the users, but be prepared to have other
methods of error notification as well. (Maybe the status bar OR the balloon,
depending on user preference...?)

Good Luck!

Pete.



.

Quantcast