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: Capitalizing...research need From:"Richard G. Combs" <richard -dot- combs -at- polycom -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 15 Feb 2005 16:30:50 -0700
David Neeley wrote:
<snip "paradigm" description that assumes all your readers are completely
familiar with your "paradigm" and know exactly where to find what
information (sub-steps in sideheads??)>
> My points about bolding and such focused around the fact that
> requirements and preferences in documenetation change, and changing
> sporadic bolding is often a thankless task. If, instead, you have a
> small graphic that *shows* the UI element where needed, the bold
> element is much less significant to begin with and much easier to
> reuse the information in any way that you may wish.
Who's talking about "sporadic bolding"? And what about all the UI elements
that don't involve graphics/icons, just a text label? As for those with
icons, since when is their appearance less likely to change than their name?
And since when is a doc full of little icons or screencaps easier to reuse
and less labor-intensive to create?
> There is no substitute, I believe, for properly using styles
> throughout a document. Any format overrides that can be avoided are
> usually best so.
And what has this to do with the subject of typographically distinguishing
UI element names? Some of us, believe it or not, actually define styles
(Word) or formats (Frame) to identify and distinguish specific types of
data, and we never use overrides or "sporadic bolding."
I have a Frame template, for instance, that defines separate character
formats for window names, UI elements, user input text, user input
placeholder text, new terms, book/manual titles, file names, phone numbers,
and then some. Some of these character formats are typographically the same
(and some are the same as the surrounding pgf) -- the char format simply
provides metadata.
If you can't imagine distinguishing UI elements without "sporadic bolding,"
I think you need to get out more. ;-)
Richard
------
Richard G. Combs
Senior Technical Writer
Voyant, a division of Polycom, Inc.
richardDOTcombs AT polycomDOTcom
richardDOTcombs AT voyanttechDOTcom
303-223-5111
------
rgcombs AT freeDASHmarketDOTnet
303-777-0436
------
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Doc-To-Help 7.5 Professional: New version with new features, improved performance and reliability, plus much more! Download your free trial today at www.componentone.com/techwrlfeb.
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -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.
