Identical commands with multiple titles?

Subject: Identical commands with multiple titles?
From: "Geoff Hart" <geoff-h -at- mtl -dot- feric -dot- ca>
To: TECHWR-L -at- lists -dot- raycomm -dot- com
Date: Mon, 20 Dec 1999 09:58:57 -0500

Jane Post describes an application with <<...a toolbar plus pull-
down and shortcut menus. A command might occur on any or all of
these, but do not always appear with the identical title. For
instance, STATS appears on the toolbar but appears as POOL
STATISTICS in the menus.>>

Generally a really bad idea. Why should users learn two or more
names for a single command? Call Fred the programmer "Ferd"
and see how he likes it... "but you're still the same person; it's just
a different version of your name. I don't understand why you
consider this a problem. Everyone will know whom I'm talking
about." <g>

<<The developers must use the brief name on the toolbar as a
longer name can't be displayed.>>

If you mean a name that appears on the icon itself, then the usual
solution is to remove the name from icon and place it in a tool tip or
"what's this?" type of help. (The name appears when the cursor
hovers over the icon.) An alternative solution is to use an
abbreviation, since the abbreviation should be short enough to fit on
the icon, while still being recognizable as the longer form of the
name (e.g., "pool stat." = pool statistics). Using a proportional font,
in upper and lower case (rather than all caps) will fit a lot more text
onto the icon, particularly if you run the text on two lines rather
than one. My readings of the literature on icons, supplemented by
anecdotal evidence, suggest that people tend to memorize the
positions of the icons rather than examining them carefully and
figuring out what the miniscule drawing is supposed to represent.
That being the case, you could probably replace a cryptic graphical
icon with a textual button and get better results.

If you mean that the problem is with the tool tip itself, I'm surprised;
Word, for example, has tool tips for menu bar commands that give
at least a dozen characters worth of space. You didn't mention
whether they're using Windows or not, but even if they're not, it's
hard to believe that they can't type "pool statistics" into the toolbar
popup. Maybe they're just misreading how these popup tips work?

<<I list the commands for each window with a popup providing an
explanation of the command.>>

That's a good workaround, but it doesn't address the real problem:
providing a confusing interface that the programmers expect you to
solve for them. Don't forget that as the techwhirler, you're also a
user advocate, and you can often demonstrate to the programmers
how important your advice is. For example, if you're working on a
large project, take a programmer responsible for module A and ask
him to decipher the cryptic comments for module Z (which he's
never seen); when he can't do it, he'll suddenly understand why
you're all upset about what he's doing in his own module. I've done
this numerous times with our three newbie programmers, and
though I haven't won every battle, I've gotten some fairly major
interface changes implemented by helping the programmer to
understand the problem viscerally.

<<I've recommended that only 1 title be used for a command....but
that fell on deaf ears.>>

Well, if that's really the situation, then you're pretty much stuck
with using both the short form and the long form. But "fallen on deaf
ears" always leads me to wonder how you've approached the
programmers. Have you _discussed_ this with them, or just sent a
message requesting a change? Have you asked them how they'd
feel if they had to memorize 2-3 different names for each command
in their programming language? Have you asked them to talk to a
real user of the product to find out why multiple names are
confusing? Each of these may be impossible (e.g., they may really
be boneheads who exists solely within their own skulls), but
sometimes you can really go far by picking the right approach to
discussing an issue.

<<There are instances... where a command having only 1 title
performs differently depending on where it was accessed.>>

Many programs have a modal approach in which the same
command functions differently depending on the mode you're in. I
don't like this approach at all, but have learned to deal with it. My
favorite bad example: have you ever inadvertently hit the "insert"
key in Word (while reaching for delete) and then typed happily
away for half a line before you realized you were overwriting text
instead of inserting what you were typing? Me too, and it bothered
me enough that I've seriously considered remapping this key so
that it inserts a space. (I've read about other users who were
convinced their keyboard broke or that they'd picked up a virus, and
called tech. support.) Maybe if you tried this trick on your
programmers (e.g., "turn around while I do something on your
computer to prove my point... OK, now let's see you start typing")
they'd get an idea of how users feel when commands suddenly
change their behavior.

In defense of your programmers, there are many cases when
having a single command perform differently in different contexts
can be very useful; think, for example, of graphics packages that
let you use the shift key to constrain a line-drawing tool to draw
only horizontally or vertically, or that change the manner in which
you select objects if you hold down the control (command) key. I
find such things confusing mostly when I don't use the software
often enough to have internalized the variations in behavior, yet
many graphic artists (for example) love the power these changes
offer them. So is this really an interface problem, or just something
unfamiliar to you but that the users of the product will embrace? To
me, a good (useful) change in behavior provides additional power to
the user, is logical for the context, and announces itself in such a
way that the change is easily perceived by the user.

--Geoff Hart @8^{)} geoff-h -at- mtl -dot- feric -dot- ca (Pointe-Claire, Quebec)
"If you can't explain it to an 8-year-old, you don't understand it"--Albert Einstein




Previous by Author: Basic skillset for techwhirlers?
Next by Author: Terminology: much disagreement?
Previous by Thread: RE: HUMOR: Baseline Skills Set and something else
Next by Thread: creating GUI for WinHelp


What this post helpful? Share it with friends and colleagues:


Sponsored Ads