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.
Re: Culture, or What it means to be a Technical Writer
Subject:Re: Culture, or What it means to be a Technical Writer From:DURL <durl -at- BUFFNET -dot- NET> Date:Fri, 8 May 1998 16:15:14 -0400
I really do see, Mark--I like the idea, in fact. It was just the
image of the Engineer and the Tech Writer standing
shoulder-to-shoulder facing the user...
I saw it in b&w, like a WWII movie, and strains
of something like "Battle Hymn of the
Republic" and jutting chins and taking hills and stuff..."We're gonna see
the message gets through, SUH!!" and the poor user, who just wants to get
his potatoes to market...sucked into somebody else's plot...oh dear I'm at
it again...!
Have a great weekend fokes,
mary
Mary Durlak Erie Documentation Inc.
East Aurora, New York (near Buffalo)
durl -at- buffnet -dot- net
On Fri, 8 May 1998, Mark Baker wrote:
> Mary Durlak wrote:
>
>
> > "AAAArghghghghghgh!!" screamed the User, running away from the
> >1,203-page manual in panic. "All I wanted was to write a letter!!!!!"
> >On Fri, 8 May 1998, Mark Baker wrote:
> > ...
> >> We do not stand between the engineer and the user, we stand shoulder to
> >> shoulder with the engineer, facing the user.
>
>
> But don't you see, the engineer communicates through the design of the
> product. 1,203 page user manuals result from writers trying to explain what
> engineers have done. If we make common cause with engineers in creating a
> complete product package that is designed to facilitate the users task we
> will describe only what the users needs to know to do the task, and cannot
> discover from the design of the product. Good products are designed for
> discoverability. Good documentation is an extension of that design, serving
> to enhance the inherent discoverability of the product.
>
> It is the writers who forget this, and who simply translate the spec, who
> end up creating 1,203 page manual with useful instructions like "To print,
> click once on the file menu. Move the mouse pointer down to the Print
> command. A dialog box will appear. In the text box labeled "Number of
> copies", type the number of copies you want to print ... " etc. etc. etc.
>
> As co-creators with the engineers we communicate only that which the product
> does not communicate itself. Bad docs are long translations of long
> technical specifications. Good docs are short original compositions that
> complete the usability of the product.
>
> ---
> Mark Baker
> Manager, Corporate Communications
> OmniMark Technologies Corporation
> 1400 Blair Place
> Gloucester, Ontario
> Canada, K1J 9B8
> Phone: 613-745-4242
> Fax: 613-745-5560
> Email mbaker -at- omnimark -dot- com
> Web: http://www.omnimark.com
>
>
>
>