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.
Poll: How do you differentiate commands, etc. in text? (Take II)
Subject:Poll: How do you differentiate commands, etc. in text? (Take II) From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>, Tom Johnson <TJohnson -at- starcutter -dot- com> Date:Wed, 28 Jun 2006 20:32:56 -0400
Tom Johnson noted: <<I would argue against inline icons. Instead of
making the reader switch gears from text to graphic to text, I would
just put the icon as an anchored object in the margin (close to the
start of the step).>>
It's true that the reader has to "switch gears" (i.e., change mental
modes from "process text" to "process graphics"), but this additional
cognitive burden should be mitigated by the fact that the inline icon
matches what they'll be looking for on the screen. You lose a bit of
time making the switch, but since you'll have to make that switch
anyway when you look up at the screen, it probably comes out even. No
hard data on this, but my impression is that the switch between modes
has a lower "cost" than time wasted hunting for the icon on the screen.
Whether placing them in the margin is an improvement I can't say. It
doesn't eliminate the "process graphic" step--it just moves it to the
start of the sentence--and it distances the graphic from the text it
relates too. That strikes me as less efficient, though again, I have no
hard data on this. That being said:
<<You could think of them as a series of bullet icons. In my mind,
that's the fastest, cleanest way of absorbing the required steps. If
you're going to tell them to click a button, just show them the button
and save them the effort of picking it out from a sea of text.>>
That approach works very well for a visual lookup table that identifies
what the icons mean. I've used this many times in a visual glossary,
for instance. Presenting the icons horizontally (the way that they
appear in the toolbar) with callouts to define their function arguably
works better as an aid to finding the icons because the user knows
where in the toolbar to look. If you don't believe that this positional
memory is significant, and trumps visual recognition of the pictures,
try rearranging the icon positions in your favorite toolbar and see how
long it takes you to recover anything like proficiency with the
software. <g>
<<Every time I see inline icons, I think of the Little Red Hen story
where the kindergarten class all says, little red hen, butter, eggs,
flour, dog, cat, rat, or mouse as the teacher pauses for each icon. Oh,
I forgot the cow and the cake. Sorry 'bout that!>>
<g> It's also important to size the icons appropriately so that they
don't distort the line spacing unduly, the way it's distorted in those
kinds of picture books. And if there are tons of buttons in the
instructions, no amount of effort spent tweaking the page will
eliminate this problem.
This is why my favorite approach in documentation is to minimize the
use of the icons in the first place by referring almost exclusively to
the menu commands. My rationale is that in addition to avoiding the
kind of visual problem Tom described, I know that the menus will work
for all users of the software--whereas many people (me, for instance)
hate working with toolbars and icons. A well-designed menu system is
generally more logical than a toolbar, and also reveals the keyboard
shortcuts for power users (me, for instance) who hate taking their
hands off the keyboards.
The icons are necessary where (as is the case more often than I'd like)
a function is only available from a toolbar, even if the context of
using that icon is not "I'm already manipulating things with my mouse".
Where that is the context, the icons are often more appropriate than
keyboard or menu commands. That's true if you're using drawing
software, for instance, and are following a procedure that will be done
almost exclusively from the mouse.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList
