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: FWD: Political traps From:The Tech Writer <techwrtr -at- CRL -dot- COM> Date:Fri, 19 Jun 1998 15:56:58 -0700
I had a very similar experience a while back. We decided to convert all
of our hard doc into HTML Help (well, except for the install and the
tutorial). I realized that this is not a Good Thing, because we had just
gotten the results of an online survey, in which we had 12 people say
that they liked our hard copy (or, even, that they liked that we even
*had* hard copy). Two people wanted to get better online doc, even if
they had to lose the hard copy doc.
Anyway, I wrote a counterproposal indicating all of the benefits of hard
copy documentation for certain uses (such as long conceptual topics where
the writer has to build on what's already been explained...something that
isn't feasible in online doc, where the user may or may not have read the
topics that lead up to the current topic). I also quoted the responses
from the survey, and gave information about how much a screen can hold
(1/3 of a page), and how fast users typically read on-screen (about 1/4
as fast as on paper), which I backed up with published sources.
I knew that I would be dismissed out-of-hand (and I was), but did it for the
right to later say, "See, I told you," when (if?) our users ask us for hard
copy documentation, again. (Plus, now I have a persuasive piece for my
portfolio! :-)
We'll see if I turn out to be right....
-David Castro
techwrtr -at- crl -dot- com
On Fri, 19 Jun 1998, Eric J. Ray wrote:
> Name withheld upon request. Please reply on list.
>
> *************************************************
>
>
> How do you present an alternative document design to people who've
> already made up their mind what they want?
>
> I agreed to follow a design our trainers wanted in creating our
> latest user manual. I hate the result and wish I'd fought harder for
> my design at the beginning.
>
> There are four problems:
> 1) I don't think they can visualize what I suggested without seeing
> it. (This-is-the-way-we've-always-done-it syndrome.)
> 2) They'll have to update their training classes to accommodate the
> rearranged material. (Valid concern given their workload.)
> 3) They had a long friendship and high respect (deserved) for my
> predecessor. They may see my suggestions as changes to her work
> rather than a reflection of how the product has changed.
> 4) Organizational politics align trainers with managerial users and
> our site with field users. The product changes impact field users.
> (Different manuals are not an option.)
>
> On my own time, I've prepared an alternative that is set up the way I
> feel the document should be. I'll accept whatever the trainers say,
> but I'd like to think they gave my suggestion fair consideration. Any
> suggestions on how I can get them to at least look at my version with
> an open mind?
>
>
>
>