Re: Teaching Tools in Tech Comm Programs

Subject: Re: Teaching Tools in Tech Comm Programs
From: Peter Gold <pgold -at- NETCOM -dot- COM>
Date: Thu, 5 Dec 1996 07:50:21 -0800

On Thu, 5 Dec 1996, George F. Hayhoe wrote:

> There's been some discussion about the lack of training graduates of some
> technical communication programs receive in use of software commonly used
> in our profession.

> We first need to make a distinction between education and training.
> Education first teaches us how to learn, and then exposes us to theories,
> principles, and methods that apply whether we use the World Wide Web or
[snipped]

Maybe this is just MHO, but I think the issue is not so much specific
products, as use of tools.

For example, if you teach that technical writing requires clear writing,
consideration of audience level and need, good organization, etc., this
is only one layer of the "lasagna."

To implement these features in a document, whether on paper or
electronic, some tool knowledge is required, and often also strong
knowledge of a specific style manual or guide. I'm thinking of a passage
that contains a reference to another piece of information; there are several
considerations:

1. how do you cite that (what standard or style is appropriate)?

2. what's the mechanism (how do you do this in your writing tool)

3. if the document has a life beyond its first release, how do you
manage the changes and corrections?

4. if there are multiple authors involved, how do they participate
without interfering with each other? How do they interconnect their
citations and retain their sanity and productivity?

Some technical writing pieces are short or simple enough in structure and
longevity so that any writing tool is adequate, but others may require
tools that suit heavier demands. (I'm not saying that short or simple
documents are inferior or less challenging to write. Consider the phrase
on cigarette packs. It's based on years of research and lobbying effort,
and says exactly what it needs to, speaks to its audience clearly, etc.)

Make your choice by evaluating issues that look at the large picture, not
just how words appear on a printed page, or how cool the product's
interface appears.

Peter Gold
pgold -at- netcom -dot- com

Disclaimer: I'm a FrameMaker trainer (not affiliated with Adobe) and I
find that teaching Frame involves also teaching about how technical
documents work.


Previous by Author: Re: FrameMaker+SGML Time Estimate
Next by Author: Re: Dynamic HTML -- a definition
Previous by Thread: Teaching Tools in Tech Comm Programs
Next by Thread: Re: Teaching Tools in Tech Comm Programs


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads