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.
"Michael West" <mbwest -at- bigpond -dot- net -dot- au>
>
> > and most of those steps contain multiple menu items
> > and menu names, then the point stands: there is so
> > much bold that any particular bold item doesn't
> > really stand out.
>
> A properly written step is not going to contain
> more than a very small number of objects to be
> acted upon. Normally two, I'd guess, and occasionally
> slightly more if the step combines multiple actions
> ("From the _File_ menu, choose _Print_, and then click
> _OK_" for example).
>
> If those objects to be acted on (File>Print>OK) are
> bolded or otherwise distinguished, it facilitates
> the transfer of information from the page to my
> eye to my hands. I have to do less looking back
> and forth between the text and the screen.
>
I feel that I'm repeating myself but my point doesn't
seem to be getting across so I'll try again. Say you
have a procedure with 8 steps. Each step has 2 or 3
bolded items, and there is little or no explanatory
text between the steps. That means that you have 2-3 bold
items in nearly every line of about 10 or 12 short lines
of text. If you are trying to go back and forth rapidly
between the text and the screen, having all that bold means
that it is not easily distinguished from the other minimal
text that is not bold. Therefore, the use of bold to
contrast with regular text is compromised given the amount
of bold in that concentrated text area.
> > > > Finally, the bolding
> > > > often means that users will skip over often important
> > > > explanatory text and just pick out the bold items.
>
> If that happens, something is wrong with the way
> the procedure is written.
>
I'm not following you. First you tell me that as a reader,
you want the GUI items to be bold so you can just pick them
out and skip the surrounding text. But at the same time,
you're saying that there is something wrong with the procedure
if the reader is skipping information they need?
I have already agreed with you that steps should not contain
explanatory material. But there is often warning or reminder
material (such as "Entity names should begin with an alphanumeric
character and not contain dots or underscores") that is
appropriate to include following the step. This information
is often necessary or crucial for correct application of the
step. I don't see how you can say that including this information
is incorrect construction of a procedure.
NEED TO PUBLISH FRAMEMAKER CONTENT ONLINE? "Mustang" is a NEW single
sourcing tool for FrameMaker that lets you easily publish your content
online. No macro language required! http://www.ehelp.com/techwr-l3
Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot-
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
