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.
Subject:Tool knowledge versus Task knowledge From:Laurence Burrows <burrows -at- IBM -dot- NET> Date:Fri, 2 Oct 1998 12:41:15 +1000
Eric J. Ray wrote:
--------------snip
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.
--------------snip
As the wearer of many hats (pilot, aviation publisher, FrameMaker
re-seller/consultant, publishing consultant...makes me tired writing this
<g>) I see the tech writing task from more than one perspective.
I wonder if the process of technical writing meshes well with book/web/cd
publishing? In times past, 'professionals' did the production tasks while
writers just wrote the words (and organise the artists, photographers and
sales people). Since then we have seen the emergence of the
'multi-skilled' tech writer, spinning words with one hand whilst
contemplating page layout subtleties with the other. From the results I
see in the books, manuals and web pages I use, the following compromises
occur:
* Content and style OK, but delivery is wrong (see my rant on 3-ring
binders vs. perfect bound manuals), or published to web but audience
unfortunately not on-line (e.g. unemployment benefit guidelines published
on a web page), .pdf files need a 2-hour download to get the free reader
because it wasn't included on the CD ** target readers ignore/misuse/cannot
access the resultant document.
* Words OK, but illustrations/graphics/screen shots are amateur (or worse,
adapted from another product that subtly differs from the one under
discussion ** readers confused.
* Words and graphics OK, but layout is wrong--wrong type face, wrong page
size/orientation (so manual won't sit flat in available workspace), wrong
paper, help files won't fit on screen, web pages that have to be scrolled
sideways to read them, web pages won't print (big time gripe!), web font
over-rides default so user cannot enlarge if they need to, etc. ** readers
give up.
* Layout and delivery OK, but words seemingly translated from Urdu by
drunken Japlish translator sub-contracting on a fixed-price contract **
readers feel hung over.
* Layout very stylish with great graphics, but writers don't seem to have
actually tried using the product under discussion--reader tries to follow
instructions but there is always some vital bit of information missing **
readers then ring Tech Support, put on hold, suicide after 3 hours of Enya
and promos.
* Layout stylish, but content meagre so readers must rush out and buy
'Mastering Gump FrogSnotting in 7 Days!' or 'Dummies Guide to FrogSnotting'
** readers feel cheated and resentful.
I could go on (Bruce will say that I will anyway), but my point is that
being a good communicator probably will never make you a good artist or
printer. So why do we pretend?
