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
am >>>
Hi folks,
I've sure appreciated the responses to my trolling for
discussion on
multiple text styles. However, it's evident that a little
clarification
might be in order.
First, some definitions:
Text styles refer to the type face, point size, leading,
indentation and
font of text. <Arial, 12 pt, 6 pt above, 6 pt below, flush left,
regular>
would be a text style, just as we see in Word or Wordperfect
style sheets.
Type faces are the font family -- Arial, Times New Roman,
Garamond, Bodoni,
Mistral, and so on.
Fonts are the collections of individual letters within a type
face,
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
in the
appropriate point size underneath to provide spacing between
that line and
the next.
Quite a few folks wrote and cautioned against "ransom-note"
publishing -- a
kindergarten publisher's error. (Oooh - Let's use Rockabilly
for our
headings!!). Thanks, but my concern goes much deeper than
that. This
affects a "standard" practice among technical
writers/publishers.
There is widespread use, among software manual writers, of
different text
styles, apart from headings and body text, to indicate each
of: what the
user types in, what the computer responds with, what code
looks like,
possible error messages, and more. In a long document with
meaty paragraphs
and few bulleted or numbered sections, it doesn't look that
bad. The
thinking has been that users need the visual cues to
differentiate between,
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;
and Filename
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
sentence I
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
yesterday had
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
(leading and
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*
for
emphasis. I use rules (that's "lines" for the
typographically-challenged),
callouts and boxes where appropriate.
How about the rest of you software writers?
--Beth
Beth Agnew
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