Re: Tool knowledge versus Task knowledge

[Kris Olberg <kjolberg -at- IX -dot- NETCOM -dot- COM>]

-----Original Message-----
From: Eric J. Ray <ejray -at- RAYCOMM -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Thursday, October 01, 1998 2:54 PM
Subject: Tool knowledge versus Task knowledge


[snip]

>The people who pointed out the folly in teaching a specific
>tool based on what is in use (today or tomorrow) in industry are
>completely right--the essence of a good technical communicator
>isn't the ability to use Frame, build Web sites, or design Winhelp.
>The essence of a good technical communicator is to identify
>what information the audience needs, to get that information,
[snip]

Ahhhhhh ... music to my ears. IMNSHO, this issue presents the biggest
challenge facing technical communicators today. So many are lacking so many
communication skills that they tend to focus on the tool, or delivery,
aspect instead of the content. I'm really tired of technical communicators
who call themselves communicators yet can't spell (or use a spell checker or
dictionary), don't know proper grammar, can't form good paragraphs, and
worst of all, don't understand the material nor the needs of the audience
for whom they write.

>The task of a technical communicator is to deliver
>information, and the ability to deliver should be
>independent of the tool of the hour. A tech writer
>who is proficient with DocumentDevelopment 99
>should also be able to produce in short order using
>FastTreeKiller '01.


There are certain common aspects to all delivery mechanisms. Most all tools
will cut, paste, add leading, format with a certain font, insert graphics,
generate indices and tables of contents, etc. Those are the things that
anyone pursuing technical communications needs to learn to survive in a
world where so many doc managers step over dollars to pick up dimes.

But the smart manager lets a writer focus on the content and hires
production people to do the formatting. Companies can do this with relative
ease if they have solid style specifications and tool savvy production
personnel.

Good content is what makes a communication good. Consider this--Edmund's
site on the 'net consistently receives rave reviews for navigability and
retrievability, yet it lacks layout sophistication. However, Disney's site
has received poor reviews for navigability despite its eye candy.

[snip]
>That said, I'm often struck by just how much effort we
>could save by really understanding the technologies and
>tools that we use. Based on postings to this list and
>others, it seems that many of the confusing aspects of
>being a technical writer stem from not fully understanding
>the tools and technologies we use. (Yes, I realize that there
>are other confusing issues and interpersonal ones rank up
>there as well, but bear with me for a minute.)

[snip]

A writer's tools are vocabulary, style, construction, grammar, tense,
punctuation, audience definition, and environmental requirements. Period (no
pun intended). Cutting, pasting, formatting, and printing are the domain of
the word processor. Graphics generation belongs to artists.

[snip]
>I'm not necessarily advocating that everyone turn into
>a techie geek--one per office usually suffices ;-) --but
>I'd be interested in other people's comments and input
>on these issues. Many of us have better things to

[snip]

How many of you TRAINED technical communicators can answer the following:

What is the appropriate font for presentation graphics (overheads) any why?
What are the appropriate angles and positions for graphic callouts and why?
What is the appropriate point size for a 3" text column?
Why is text in all caps hard to read?
Which is easier to read: left justified text or justified text?
Why are page numbers commonly placed near the outside margin of the page?
When do you use an hyphen, en-dash, and em-dash?
What is the appropriate line weight for line graphics embedded in text
columns?

If you can answer all these, consider yourself experienced at document
production. (In going for the "kill," I could have added a whole slew of
questions about hardware and software mechanics.) But be assured that my
technical writer "test" consists of a whole different set of questions.

I've voiced some strong--probably not popular--opinions about the domain of
a technical communicator. Let me finish by saying that continuing to enable
the insistence of management that writers "do it all" is a mistake. It
dilutes and degrades the professional writer.

Regards...Kris
-----------------------------
kolberg -at- healtheon -dot- com
kris -at- olberg -dot- com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=