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.
> In your discussion on the listserv, the following snip was posted:
> > dare I mention that taking the tool expertise and page
> > design function away from the tech writers is another
> > objective.
> I have seen this same idea in an ad for a Chicago firm looking for a technical
> writer expressed as (very freely quoted):
> > looking for a technical writer who can write.
> > No desktop publishing, just real technical writing.
[snip]
> But, as a technical writer who believes that the most important part of the job
> is "information transfer" or "development of instructional content", I am not
> very convinced that writing words without an awareness of the context in which
> the user will see them [the illustrations, their juxtaposition to other concepts
> and topics, their place within the overall scheme of the documentation set]
> allows me to ensure that the information transfer occurs. And, if that transfer
> does not occur, then any apparent productivity increase is spurious.
[snip
> JoAnn Hackos presents an illustration in one of her classes about a two page
> (front and back) quick reference card that took about 300 hours to design,
> develop and write in order to present the information in the best possible way
> for the end user. Without a writer who is deeply involved in user testing, design
> and presentational development, this kind of project cannot be successful. [The
> card reduced front-line installation service calls by a very high percentage.]
Yesss!!! Statistics and ratios and fiats and game plans alone won't do
the writing, education, knowledge transferring, etc.
An IBM-er authored "The Mythical Man-Month" in the '60s or thereabouts
which made the point about software engineering that although it's not a
human process, like human gestation, throwing nine times the resources at
a project won't complete it in one-ninth the time any more than nine
women can create a baby in one month.
For documentation to be useful, think of it as more than a
parts-and-features list, and give it the time and effort it needs.
