Documenting a ridiculous user-interface?

[Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA>]

Kathryn Northcut reports on data-entry software in which
users <<... have to have NumLock on to use the keypad
to enter numbers into the fields, BUT with NumLock on, the
keyboard shortcuts for access to the menus are disabled (i.e.,
the ALT key doesn't work).>>

<rant> I thought about it for a while, and I really can't think
of any valid reason for requiring your audience to go through
such contortions simply to enter data; the only times I've ever
used an application that required this--and I've been working
with computers for more than 20 years now--was with
mainframe applications in which the keypad is being used for
preprogrammed functions. Is that the case? (If the keypad
isn't serving two discrete functions, this kind of interface is
simply inexcusable in the modern world.) In effect, I suspect
you're being asked to document an unreasonable solution
implemented by programmers too lazy or stubborn to
implement it right. Speaking as a user, this would annoy me
even more than my current pet peeve, being forced to double-
click in a cell in Excel before I can edit what's in it.

<<I must... [tell users to toggle NumLock off and on if they
want to use both they keyboard shortcuts to menus AND the
keypad for numeric entries.>>

If you really can't sit down with the appropriate people and
convince them just how awkward this interface is, then there's
not a helluva lot you can do about the situation. Simply insert
a note with a big [!] icon beside it that says something like
"you can either enter data, by ensuring the num lock light is
on, or access the menus from the keyboard, if the num lock
light is off, or switch to a product produced by a company
that actually cares about how you work". </rant>

Speaking a little more seriously now that I've gotten that off
my chest, my last suggestion probably is the way to go, albeit
phrased a lot more helpfully and with considerably less
sarcasm. You should also include this information in the
"getting started" guide or tutorial to ensure that users
understand the problems they'll be facing. If you can gently
help your audience to absorb this manner of working with the
software, then they'll grumble and learn to deal with it.

--Geoff Hart @8^{)}     Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"If pro is opposite of con, then what is the opposite of progress?"--Anon. (possibly Richard Lederer
)

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=