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.
"David Chinell" <dchinell -at- msn -dot- com> wrote in message news:205915 -at- techwr-l -dot- -dot- -dot-
>
> Does anyone have any information to support (or not) bolding
> GUI component names in printed reference manuals or Help
> systems?
>
I can't point to research, but I do know the conventions I have learned to
follow (unless I am working where the local style guide directs otherwise).
But the conventions I tend to follow have generally been the same as the
style guides that have been developed by experienced technical
communicators. Interestingly, it is an issue that was recently raised where
I am working now by the client (a VP).
Put simply, I do use bolding, but only within procedures, and only the items
that users take action on. So an instruction that says "Click OK," the "OK"
is in bold. But in something like "On the Orientation tab, click Landscape,"
I would bold just "Landscape."
Any GUI widgets mentioned in any text that isn't part of a procedure I don't
bold.
Typically, when readers are looking for guidance, their eyes are often drawn
first to the heading style that they know defines the beginning of a
procedure. If they are scanning, as readers often do, then the bolding of
the specific items they act upon in the procedure should attract the eye the
most; they are the critical items in the procedure.
I suppose there may be research in the various journals that may or may not
back up this belief. But from what I know about HCI and psychology, this
makes sense. I have never been in a position where I've had the time or
resources to actually test this against other alternatives.
ANNOUNCING ROBOHELP STUDIO
Create professional Help systems that feature interactive tutorials and
demos with all new RoboHelp Studio. More at http://www.ehelp.com/techwr-l2
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.
