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:Reply- Clarification on Text Styles From:Carol Van Natta <CVANNATT -at- ITC -dot- NRCS -dot- USDA -dot- GOV> Date:Fri, 12 Dec 1997 07:15:43 -0700
Beth, your ideas sound fine, as long as you have the freedom
to use other graphical aids to replace the text style changes.
Where I work, we're constrained by a "minimalist" style by
the Powers That Be. We publish Word documents on
CD-ROM for users to print out and copy double-sided on their
own paper. We can't use shaded text boxes or callouts --
they're too unpredictable on other people's printers/copiers.
We have to use screen shots sparingly, so we don't choke
printer memory. We're allowed four typefaces, plus bold and
italic, and the body text must be 12 pt. Times, and nothing
anywhere can be under 10 pt. Our users vary from computer
illiterates to experts, and the software is a complex,
character-based UNIX database.
Sometimes variations in text style is the only way we have to
indicate commands to be typed or what the error message
says. Our users tell us they like it, because they can easily
find the command they're supposed to type (or the warning or
whatever) when they refer back to the page. We have to have
a short conventions section because of the varying levels of
user expertise -- some of our users have never read a
software user manual before (and wouldn't read ours if they
had a choice).
>>> Beth Agnew <bagnew -at- insystems -dot- com> 12/12/97 6:42
I've sure appreciated the responses to my trolling for
multiple text styles. However, it's evident that a little
might be in order.
First, some definitions:
Text styles refer to the type face, point size, leading,
font of text. <Arial, 12 pt, 6 pt above, 6 pt below, flush left,
would be a text style, just as we see in Word or Wordperfect
Type faces are the font family -- Arial, Times New Roman,
Mistral, and so on.
Fonts are the collections of individual letters within a type
so-named from the old days of hand-setting of lead type
when the individual
metal letters were kept in partitioned trays called "fonts". A
font is a
set of letters of one type face or size. Arial Bold 12 pt is a
font; so is
Arial Italic 10 pt. That's why you can buy 600 fonts on a disk
and only get
about 40 type faces.
Leading ("ledding") refers to the spacing between lines of
type. After the
typesetters laid down a line of type, they'd add a strip of lead
appropriate point size underneath to provide spacing between
that line and
Quite a few folks wrote and cautioned against "ransom-note"
publishing -- a
kindergarten publisher's error. (Oooh - Let's use Rockabilly
headings!!). Thanks, but my concern goes much deeper than
affects a "standard" practice among technical
There is widespread use, among software manual writers, of
styles, apart from headings and body text, to indicate each
of: what the
user types in, what the computer responds with, what code
possible error messages, and more. In a long document with
and few bulleted or numbered sections, it doesn't look that
thinking has been that users need the visual cues to
say, the name of a menu item and what they type in. You
might have a line
that reads something like: "Click File / Open, type in
c:\directory\filename, click OK and you will see your
document Filename in
the Editor window." File / Open might be in Arial bold;
c:\directory/filename in Times bold italic; OK in Arial bold;
in Times bold.
These text styles are the conventions used in the manual to
"help" the user
distinguish among interface and procedural elements.
I'm proposing that it is not at all necessary. In the example
just gave you, the multiple type styles are certainly overkill.
But I see
it time and again. On the surface, different type styles seems
like a good
idea, but what looks fine in the "conventions" section can
back you into a
corner when to remain consistent you have to use all of
those type styles
in one sentence or on one small page. The manual I reviewed
11 type styles on one 9 x 6" page! And this HELPS the
user? I think not.
I've stopped doing it. The "Conventions Used in this Manual"
section of our
user guides is GONE. Instead, I use more white space
indentation). I still use a sans serif type face for headings,
and a serif
type face for body text. Italics and bold are used *sparingly*
emphasis. I use rules (that's "lines" for the
callouts and boxes where appropriate.
How about the rest of you software writers?
Senior Technical Writer, InSystems Technologies Inc.
65 Allstate Parkway, Suite 100 Tel: (905) 513-1400 ext. 280
Markham, Ontario, Canada L3R 9X1 Fax: (905)
513-1419 mailto:bagnew -at- insystems -dot- com Visit us at: http://www.insystems.com