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:Getting input into the style guide? From:"Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 24 May 2001 12:43:12 -0400
Jane Carnall reports: <<I ... set up a basic Word template with a minimal
number of styles, etc, so that I could format all the documentation into the
same format. One of the first things she said when she looked at it was:
"Oh, of course you didn't know, because the style guide wasn't available,
but we've agreed that all documentation produced by us has to be in Arial."
(I'd used Times New Roman for the body text, and Arial for the headers. Not
the most inspired of choices, but I wasn't after being inspired: just
getting a standard style that could then be changed as required.)>>
I don't find Arial a particularly good choice for body text in printed
documentation, because I find it difficult to read, but it's important to
note that:
(i) an appropriate sans serif font can be every bit as readable as serif
(e.g., Stone Sans is pretty sharp),
(ii) many Europeans are more familiar with and comfortable with reading body
text in sans serif than we provincial North Americans (and since you're
writing in Scotland...), and
(iii) Times New Roman is an eminently readable font, even though many
avant-gardistes consider it passé. There are several more elegant (in my
subjective opinion) versions of the venerable Times typeface, but TNR isn't
bad.
<<I want to get some input into this style guide, at least as far as it
concerns user manuals. I don't want to end up controlled by a style guide
that was developed in consultation before this company hired a technical
writer.>>
One of the best ways to get involved in this kind of effort is to solicit
feedback from the users of your products. Surveys tend to be biased ("self
selection") and produce very low response rates, so it's generally more
effective to stratify your sampling (i.e., pick a few representative
individuals from each major group in your audience) and actively seek out
their opinions about the current docs and your suggestions for change. If
you can't get permission to talk to your audience or access to the audience
is difficult, some of your in-house staff might be appropriate; for example,
if the marketing department is composed entirely of former gaming geeks, and
said geeks are also your audience, then they might be very good advocates
for your audience. Support the findings of your survey with research results
(e.g., see Karen Shriver's excellent "Dynamics in document design") and you
can make a compelling case for change. Example: "Shriver reports that Times
Roman is the most readable font ever created by any civilisation, anywhere
and anywhen" (she doesn't, btw <g>) "and guess what, our audience agrees.
Time to change away from Arial!"
<<Tactically, though, what I thought of doing was a brief (like 1 side of
A4) paper on "Good design for manuals" or "Elements of typographic design"
to be circulated to my manager and the QA and the marketing manager and
anyone else useful, on the lines of "These are my ideas on what our manuals
ought to look like, and this is why." That way I'm
not explicitly challenging the marketing style guide - I'm just saying what
I think will be good for *my* area of expertise.>>
This is a good, subtle approach, but because it's subtle, it might not work
or might take a long time to work; it's often much more productive working
directly with the people who make the decisions. If you do proceed, one way
you could do it would be to produce a regular "communication newsletter" in
which you provide an interesting, thoughtful, entertaining look at various
design issues (e.g., type choice) for all staff, and conclude each issue
with a list of the literature you consulted to support your case. Don't
explicitly address the style guide issue, as this might (quite rightly) be
seen to be manipulative or disingenous. Writing this shouldn't be a burden,
since it must be short and fun if you expect anyone to read it. Your
suggestion of a single page (and hopefully, lavishly illustrated or designed
with good use of white space) is right on the mark. Over time, people will
gradually come to recognize your expertise, and ideally, they'll eventually
ask for your opinions on document design.
<<I just have a strong feeling that any style guide that simply specifies
"Arial" as a font choice is not one that paid much attention to what user
guides need to look like>>
That would fit my prejudices too. <g>
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"Some painters transform the sun into a yellow spot; others transform a
yellow spot into the sun."- -Pablo Picasso (1881-1973)
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See http://www.infomap.com or 800-463-6627 for more about our solutions.
---
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.