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.
> Does anyone have any information to support (or not) bolding
> GUI component names in printed reference manuals or Help
> systems?
>
> Years ago, we decided that the extra work required didn't
> create a proportional value. We also felt that the resulting
> text looked blotchy and was less readable.
>
In my previous company, I used to follow a style guide that says that all
the GUI elements should be in boldface. It made perfect sense to me. I
have seen a lot companies using this convention and I had a feeling that
this must be a strategy evolved as a result of some user analyses. The
users could follow the procedure more easily because the things on which
they have to perform the actions are highlighted.
I document Command Line Interfaces using a different style (in an easily
distinguishable font and in a separate line). This is feasible for CLIs,
but not for GUIs because you may be having a large number of interface
elements on a screen and such a documentation convention will ultimately
result in increased printing costs in case of hard copy documentation and
increased page count and file size in case of online documentation.
Testing your document for usability with and without using boldface for
UI elements will be good idea. You can approach a user of your product or
somebody who is not very familiar with the product for help. Request your
subject to read both (with and without boldface) the versions of the
document separately and complete a particular procedure. You can use the
time taken for each of these rounds and the user feedback to make a
decision on your problem. This is fairly easy and finally you will be
able to justify your decision in fewer words.
Hope this helps.
~Subash
--
Subash Babu
subash_tc -at- speedpost -dot- net
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.
