Tool knowledge versus Task knowledge

[Michael Andrew Uhl <mikeuhl -at- MINDSPRING -dot- COM>]

Esteemed Colleagues:

In my job, knowing how to use the tools is what earns me my salary. Yes, they
want me for my writing skills, that's a given. But what my programmer and
science colleagues find me most useful for on a daily basis--and what they're
willing to pay me a decent salary for--is the ability to solve minor
communication problems very quickly. For example, just today, someone sent me a
FrameMaker file with a long two-column table and they needed it in WordPerfect
format, but with the same layout. I needed about five minutes to figure out
that

FrameMaker ==> RTF ==> MS Word ==> WordPerfect

gave the cleanest translation path for that particular document. She was happy
to get it so quickly, but she also told me that she's come to *expect* this
kind of thing from me.

Here's another example. A colleague gave me a WordPerfect file and needed it in
HTML, fast. Some of you would likely guest that you can probably just do a Save
As to HTML. You'd be right with that guess. Voila, you have HTML. However, he
didn't want to know that, he just wanted results. I knew that and gave him what
he wanted.

They want me to edit their scientific papers and reports and write monthly
reports for EPA that EPA finds acceptable. But more importantly, my group wants
me to be there to solve any communication *or* technical problem related to
communication that they might have. This, by the way, means having a good
working  knowledge of printers, personal computers, paper, toner, presentation
tools, scanners, and so on.

In fact, for my job, theories of communication--the kind we read about in STC's
quarterly journal--seem less and less relevant to me. Before I get toasted over
this, let me say, this is just for *my* current job. YMMV.

-Mike
--
Michael Andrew Uhl (mailto:mikeuhl -at- mindspring -dot- com)
Durham, North Carolina USA
http://www.epa.gov/vislab/




Eric J. Ray wrote:

> Taking a quick break from real work for a stint on the
> soapbox... (I'll freely admit that what I have to say seems
> to be internally inconsistent, but I'll stand behind the whole
> thing.)
>
> 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,
> to put that information into a form that the audience can and
> will use, and to deliver that information. Getting bogged down
> in the tools used to perform misses the point of technical
> communication and cannot be good for anyone in the tech
> comm food chain. (It also probably leads directly to the
> job ad I saw today looking for someone who
> is proficient in FrameMaker, Photoshop, and RoboHelp
> to develop documentation for Company ABC. Oh, and
> the position pays $10/hour for a non-entry-level job.)
>
> 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.
>
> 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.)
>
> Taking HTML as a reasonably universal scapegoat,
> we often see postings or hear discussions about
> making HTML print consistently in all situations
> from all browsers, about aspects of including
> .bmp (sic) images in HTML documents,
> about ensuring that documents look the same
> to everyone, and so forth. A little research into HTML
> would show that HTML (not CSS, but HTML) cannot
> control page breaks, that .bmp images aren't standard
> for Web browsers and aren't recommended for many
> reasons, that HTML<>WYSIWYG, and similar information.
> Not that everyone should instinctively know this, but
> an hour or two of research could save a lot of people
> a lot of work and frustration.
>
> Similarly, people using graphics and manipulating graphics
> would benefit from knowing a little about the differences
> between vector and raster images, which image formats
> are which, when each is appropriate, and which originate
> on and work well with different operating systems.
>
> Or, people troubleshooting output difficulties for
> hardcopy or PDF could often save a lot of time by
> learning a little about WYSIWYG programs and that
> printer drivers are simultaneously the linchpin
> and weak link in printing, and starting the trouble-shooting
> process with printer drivers.
>
> These aren't the best examples, but they illustrate, I
> think, the confusion that often results from not knowing
> the details of the technologies we use to deliver
> information.
>
> 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
> do than to bone up on arcane techno-trivia, and if you're
> using the Web to do so, you're handicapped in the first
> place by questionable sources and information that
> proports to be authoritive but isn't. However, I've
> found that the techno-trivia I've acquired over the years
> has been infinitely more valuable to me as a technical
> writer than I'd ever have imagined.
>
> Eric
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Eric J. Ray    RayComm, Inc.
> http://www.raycomm.com/      ejray -at- raycomm -dot- com
>
> * Syndicated columnist: Rays on Computing
> * Technology Department Editor, _Technical Communication_
> * Award-winning co-author of several popular computer books, including
>   _Unix Visual Quickstart Guide_, _Mastering HTML 4_, _Dummies 101:
>   HTML 4_, _HTML 4 for Dummies Quick Reference_, others.
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000==


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