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.
Tom Johnson wondered: <<I am wondering which style is more
advantageous: Choose Format > Background > More Colors. OR On the
Format menu, point to Background and click More Colors.>>
Angle brackets are inherently unintuitive, and replacing them with
actual arrow characters is no more obvious: With angle brackets, the
reader requires two leaps of logic (angle to arrow, arrow to menu
opening) to associate this style with the use of menus.
Even with the arrow, it's a fairly large single leap of logic for a
naive user (of whom there are many) to associate something pointing to
the right (or presumably to the left, when you localize this into a
right-to-left language) with the act of opening a menu and selecting
something from it, particularly when there's no cascading menu with a
little arrow to make the connection clearer. Even then, wouldn't the
logical choice be a downward-pointing arrow for the first step, since
menus open downwards, followed by a right-pointing arrow for cascading
menus and an "Enter" key or mouse button for selecting the highlighted
menu choice?
Granted, this approach is familiar to _us_ and to most power users and
computer geeks. If that's your audience, then there are clear
advantages to this format: it's concise, it communicates efficiently,
and it stands out on the page (the > form a clear visual pattern),
facilitating scanning. Like any learned convention, it is a skill
readers can rely upon--and thus, we can use it, confident in the
knowledge that our readers will understand. The problem comes when the
convention has not yet been learned.
<<Some Adobe products use the angle brackets, while Microsoft avoids
them.>>
Different audiences. Most Adobe software is destined for experienced
computer users who are often power users compared with a typical
computer user, so it's safe to assume these readers will be familiar
with the style convention, or at least willing to learn it. Microsoft,
on the other hand, targets a general audience with a wide range of
competencies (heavily weighted towards the low end of the competence
scale in many cases), and thus chooses a lowest-common-denominator
approach that will work well for everyone, even if it may not be the
most efficient approach for the experts in the audience.
The conservative approach is to write out everything, as you have done
in your second option. It pays to remember that while this may
hypothetically take your power user a bit longer to read (2-3 seconds
per procedure?) compared with using arrows, these people are consulting
the documentation rarely, when they need to learn something new or
recall something they've forgotten. In that case, the performance
penalty is acceptable because it's so infrequent; furthermore, they're
prepared to spend a few seconds because they know they're learning
something for the first time.
In contrast, the general or neophyte user who will be consulting the
documentation frequently suffers from a significant penalty if you use
the arrows: if they fail to understand this convention, they fail to
understand your instructions, and probably won't come back to your
documentation again. For them, imposing a penalty of a few seconds is a
non-issue: whether or not they're in a hurry, the more relaxed pace of
this form of instruction helps them slow down, take a deep breath, and
overcome the anxiety that so often prevents learning. I offer no
statistical proof that this happens, but I have seen it enough times to
suspect the phenomenon is real.
Note that although you can certainly define the typographic and other
conventions you use in your manuals, you cannot ensure that readers
will find those explanations: few will read your manual cover to cover,
and few will have any idea where to look for the topic "explaining
obscure typographical conventions used in this manual", particularly if
you've already stressed them out by hitting them between the eyes with
incomprehensible instruction: where's the motivation to believe that
you did a better job explaining how to use the manual?)
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
