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.

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

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

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

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


To subscribe, send a blank email to techwr-l-join -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.


Previous by Author: Citing or Referencing CADD Drawings?
Next by Author: Windows Vista and Office 12 (was: Poll)
Previous by Thread: Re: PDF bookmarks for LOTs, LOFs
Next by Thread: RE: Poll: How do you differentiate commands, etc. in text? (Take II)


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


Sponsored Ads