And this also argues in favor of database software (like VFP) that has
unique date data types that can't be confused with anything else.
I have news for you. VFP date types can be entered without having
to enter the punctuation. For example, today can be entered as
20130215
Huh? Try this:
CREATE TABLE foobar FREE (somedate D)
INSERT INTO foobar (somedate) VALUES (20130215)
You'll get a data type mismatch error.
I said "enter". We were discussing data entry. You are moving the
goalposts.
One possibility would be to use a date picker.
But if I use a textbox in VFP whose initial value is {} then the automatic
VFP "bad date" validation goes into effect. That excludes some errors.
There is also business-object-level validation. Mine for dates does various
things in various situations, such as not allowing future dates, not
allowing dates too far in the past, not allowing end dates that are earlier
than corresponding start dates, etc.
In any case, having a unique data type for dates precludes the value from
being treated as anything other than a date. One can't do math on a VFP
date value and get a result that can be interpreted as currency, unless one
is completely clueless as a programmer. And as I understand it, some of the
big-iron database systems are beginning to offer unique date data types now.
Meanwhile, in the situation described, a user entered a date value into a
control that was intended to accept medical service co-payment dollar
values. Based on how much this ended up costing, I would guess the user did
it over and over and over, and the values were added up over time. If so,
it strongly implies that the user interface was poorly designed, since
users typically don't make the same mistake hundreds of times in a row.
I think some obvious points to make would be these:
1. A strict date value requires 10 digits. Even a loose date value with a
two-digit year requires 6 digits. Typical medical service co-payment values
in the United States are less than $100.00. Let's be generous and assume
that a single co-pay could be as much as $999. Let's also assume you need
the decimal places (although most co-pays are rounded to dollars, I've seen
some weird co-pay quotes from Medicare), So at the very most you need 5
digits to enter a single co-pay amount. So mask the control to 5 digits
including two decimal places. It would then be impossible to enter a
complete date value into the control. In the USA, we do dates MM/DD/YYYY.
If an oblivious user starts to type a date value into the control the worst
that could happen would be to record a value of $123.12.
2. Co-payments are not typically randomly variable; there are various set
amounts, and these are tied into the particular medical insurance coverage
plan the patient has. Medicaid being fairly uniform within a single state,
it would not be too difficult to establish a lookup table of acceptable
values and require users to choose one from a list instead of free-hand
typing digits. The available choices could be limited by the service being
billed for, providing even more security. But even without a picklist you
could still use business object code to test the value entered against
allowable co-pay values so that if $123.12 wasn't a valid amount it
wouldn't get entered into the database.
>Some bug reports turn out to be the end user doing something wrong.
Yes, that is always the case. When I trace a report to this cause, the
first thing I ask myself is, "Is there some other way to do this that will
be less confusing for the user?" Often there is. Sometimes there isn't.
It's a maxim among writers that if the intended audience didn't understand
what was written, it's the writer's fault, not the readers'. The whole
point of writing is to communicate effectively. If one's writing is not
understood, one has failed to communicate.
The whole point of computerizing the collection of data is to save time and
improve accuracy. If a computerized system for collecting data permits
simple-to-prevent data entry errors, regardless of whether better users
could also prevent them, it has failed in its mission.
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
