RE: Disadvantages of angle brackets?

["Kathleen" <keamac -at- cox -dot- net>]

Geoff,
So would it be a fair summary to say that you're saying angle brackets
are ok only when writing for the experienced user?

This is another one of those issues that would benefit from a well-done
study: how long does it take people to catch on to what the angle
brackets indicate? Do they make a difference in usability for novices vs
their times savings/brevity? 

How quickly we forget: I can remember when I first encountered the angle
brackets: I thought they were horribly uninstructive and unintuitive but
used them because that was the style in place. It also was assumed that
everyone who used the instructions would at least be a computer user
(not sure I agree with you about the "power" user phrase).  I'm far from
a power user, but have gradually become inured to the brackets.

So I think I might agree that they are best used for instructions aimed
at experienced users. OTOH, when writing a manual, the angle brackets
could be introduced along with more formal instructions for the most
basic actions, which it could be assumed that novices would be using. So
the novice would gradually learn their meaning.

Rambling on,

Kathleen

-----Original Message-----
From: Geoff Hart

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)
www.geoff-hart.com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.