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: Wish list for academic research From:"Eric J. Ray" <ejray -at- raycomm -dot- com> To:Jason Willebeek-LeMair <jlemair -at- cisco -dot- com> Date:Tue, 28 Sep 1999 21:18:51 -0600
Jason Willebeek-LeMair wrote:
> What makes a good heading is what I am concerned with, and that depends
> upon my audience. Specifics, like "use gerunds, don't use gerunds, use
> complete sentences, number each level of heading, capitalize this or
> that, this organization or format is superior to that one, use serifs,
> don't use serifs" are simply too specific to apply to a general
But the point, particularly when it comes to research, is that
you _DO_NOT_KNOW_ that. Unless you have a remarkably specialized
audience (and Cisco's audience doesn't count as that specialized, in
general), defensible studies could well show that specific
characteristics would be better received by your average
network admin, and those could be statistically validated to
apply to your audience, with some degree of certainty.
> This type of research rests squarely on the writer. If the writer does
> not have access to the audience, then of course he/she/it must go by the
> generalities (but would hopefully have access to any
> complaints/commendations). Trust me, if you really annoy a user
> (unintentionally, of course), they will let you know.
Not annoying a reader is minimal...serving a reader well is the
goal, and you're far less likely to hear back from a well-served
reader (and quite unlikely to get the feedback you need to move
a fairly-well-served reader up to the well category).
> And finally, what if research finds that 99.8% of UNIX admins will
> never, ever, ever go to the online help? Will that stop you from
> developing an online help system of the like they have never seen
> before, and then educating them in its use? Not me (but of course, I
> will also give them their preferred method and hope to catalyze a
> paradigm shift in future generations of UNIX admins).
It wouldn't stop me from _wanting_ to develop the end-all-and-be-all
of online help systems, but in strictly pragmatic terms, it'd
ensure that I just don't write online help for Product A, version 1.0,
in order to make sure that the hardcopy manuals for Product Z, 1.2
come out on time. As a matter of fact, if 99.8% of UNIX admins
will never use online help, according to empirical evidence,
I've probably written my last help file in my current gig, and
that's OK. Better not to waste anyone's time with it.
> That is why I think that general research findings cannot determine the
> goodness of a specific book.
Here, we agree. That said, general research findings offer a starting
point, which is better than the anecdotal evidence and speculation we