TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
According to Fred Jacobson:
Steve Hollander wrote:
> In documenting PC programs, I prefer
> File\Print
> and don't find users (May I use that word?) confused about this semi-logical
> extension of directory\subdirectory notation.
Here Steve gives us _his_ analogy. Backslash (or "backslant" in the
military community) means "descend the hierarchy" in the file system,
so why not in the menuing system. Very nice, although I haven't seen
it anywhere else. The product I document runs under Unix, so I could
use "/", but my audience does not necessarily use that notation to
access files.
Meanwhile, Sue Gallagher had *this* to say:
At work, we use a ZaphDingbat arrow (ascii 0228) that's
reminiscent of (but not the same as) the arrow you see on
cascading menus.
In the stuff I do on my own, I've chosen a diamond-shaped
bullet (to avoid arguments between home and work).
Both seem to do well. I think that and device that leads
the eye from one menu selection to another works well.
**Users** make the connection readily and appreciate not
having to read the extra word it takes to say "select ...
from the ... menu" (which is also backward from the way they
select the options, so has always bothered me).
I say:
Our window-menu-icon thingbee is Motif-based. So, cascading down menus
looks like this:
We'd write this as Choice1->Submenu3->SubSub2->Command2. We use the right
arrow found in the "Symbol B" font.
When using the software, the user quickly learns that wherever there's an
arrow, there's a submenu. They seem to do this without help of *any*
documentation. Similarly, they seem to immediately understand x->y->z without
having to read any explanation because it looks so much like what's on the
screen.
We shamelessly stole this idea from Interleaf 5's (voluminous) documentation.
This is where I first saw this done, and I liked that I didn't have to flip
to the section on document conventions to understand it.
So now I get around to my point. Whenever the docs can mimic the software
like this, so much the better for the user. He then has one less document
convention to look up, especially when he just wants to get in and get right
out of the manual in the first place.
jim grey
jwg -at- acd4 -dot- acd -dot- com
Terre Haute, IN - The Silicon Cornfield
