Disadvantages of angle brackets?

Subject: Disadvantages of angle brackets?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Sat, 02 Jul 2005 09:24:22 -0400

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?)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


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.


disadvantages of angle brackets?: From: Tom Johnson

Previous by Author: Re: Job Hopping (was Re: Certification--a new concept. Discuss)
Next by Author: IEEEComSoc membership?
Previous by Thread: Re: disadvantages of angle brackets?
Next by Thread: RE: Disadvantages of angle brackets?

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

Sponsored Ads