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.
Anna Langley, Education Services
Check Point Software Technologies Ltd.
alangley -at- ts -dot- checkpoint -dot- com
"Get Check Point Certified"
Computer Reseller News Reports that Check Point certifications have
tremendous
ROI and are continuously being recognized in the industry as certifications
with
increased value. Visit 2003 Special Report: Certification to view the full
article:
-----Original Message-----
From: Dick Margulis [mailto:margulis -at- fiam -dot- net]
Sent: Friday, February 13, 2004 2:16 PM
To: Anna Langley
Cc: TECHWR-L
Subject: Re: FONT STANDARDS
Anna,
THERE YOU GO WITH THE SHOUTED SUBJECT LINES AGAIN!
The trend in the last couple of decades has been from the extreme of
showing every type of on-screen object with a distinct typographic
treatment toward the extreme of not differentiating anything.
The rationale for this shift is threefold: readers really cannot keep in
their heads the meanings of eight different type styles, nor should they
have to; with careful writing, the context makes the meaning clear
anyway; the more complex the scheme, the likelier it is that the
document will have formatting errors around this issue, further
confusing the few readers who do manage to keep it all straight.
I think the majority opinion (though not an absolute consensus by any
means) is that it is best to keep all this signification stuff as simple
as possible.
You MIGHT want to keep code samples in a monospace font like Courier
(there are better choices for code that distinguish clearly between zero
and capital oh, and between one and lowercase ell). I've seen plenty of
situations where even this is overkill.
You MIGHT want to use bold to identify field names, although I prefer
using capitals and not using bold. The decision might depend on the
audience and the medium, though. For online work, I wouldn't use bold as
a marker for the simple reason that the difference between bold and
normal may not be visible in the viewing environment. I use initial
caps, regardless of whether the field label on the screen has initial
caps. For example, if the screen prompt is "Select a file type," I'll
refer to the Select a File Type list in preference to using quotation
marks or bold. This goes against the usual advice to make the text match
the screen, so follow my lead only with extreme caution on this one.
You MIGHT want to use small caps for, say, key names,, button names, or
list selections; but I wouldn't bother. Again, I use an initial cap.
Press Enter. Click Cancel. Select Design Template (*.pot).
Just my opinion.
Dick
Anna Langley wrote:
> Dear Technical Writers:
>
> I'm working on my team's document template. I'd like to know the font
> size/style standards you've developed for:
>
> Commands and strings.
> File names.
> Directory names.
> Utilities.
> Menu selections.
> Keyboard, menu, and GUI buttons.
>
> Right now, we don't have a standard, except that we put commands in a
> Courier font, and everything else doesn't get a separate font style. I've
> looked in my Chicago manual, and can't find a recommendation. So I'd like
to
> know what you're doing.
>
> Thanks so much for your help!
>
>
