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.
Subject:Re: Typographical treatment of GUI components From:Michael West <mbwest -at- bigpond -dot- net -dot- au> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 14 Jul 2003 08:22:01 +1000
> Does anyone have any information to support (or not) bolding
> GUI component names in printed reference manuals or Help
> systems?
I suspect that your engineering manager has no expertise
in typographic design and spends very little time using
user-assistance material, but unfortunately that will
probably not impair his ability to impose an unsatisfactory
solution on the rest of you. It happens all the time.
You cannot expect to find "scientific" support
for an isolated style convention like bolding or
not bolding GUI items. The effectiveness of
such practices can only be assessed in concert with
other page design attributes. This is so difficult
to do that I'd recommend taking the easy way
out: pick an existing set of publications that
everyone likes, and imitate it.
I'd suggest that you and other interested
parties sit down with various sample layouts of
"live" material and discuss and negotiate a solution
that seems to work best from everyone's point of
view.
Regarding the use of bolding or other special
styles for GUI elements: the best argument for
doing it is that it gives the user an extra visual
clue. It tells the user exactly what literal text string
to look for when performing the action being
described. This assumes that the writer is disciplined
enough to double-check all such strings to make sure
that they are replicated *exactly* between the
user-assistance material the interface. Without this
exact correspondence, the whole point of the exercise
is nullified. Using boldface is usually preferred over
enclosing the string in quote marks because inserting
quote marks can be misleading in some situations.
The best argument for *not* doing it is that
in some kinds of text (for example, command
lists) it can make the page look unappealing.
I often make an exception to a "boldface" rule
when constructing lists and tables if applying the
rule would mean that practically everything on
the page would end up bold.
If it makes the page "hard to read" then something
is wrong in the way it is being applied. Don't do
anything that makes a page "hard to read" for the
average reader.
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.
