Re: TECHWR-L Digest, Vol 40, Issue 22

[Geoff Lane <geoff -at- gjctech -dot- co -dot- uk>]

On Monday, February 23, 2009, Sarah Stegall wrote;

> What the blue blazes does this have to do with technical writing?
---

It has a lot to do with technical writing in that it's part of a
thread that IMO illustrates very well some of the pitfalls of written
communication. The thread started as a branch of "Qualifications for
an off shore writer?" so perhaps you missed the link because of the
subject change. However, you need to consider the thread holistically
else many posts taken out of context might seem off-topic.

As a technical writer my job is to learn and then disseminate what
I've learned in a form that suits my target audience. Part of that is
to know what my audience finds offensive, so that I can avoid
offending them.

Just in case you missed the previous posts, I'll summarise: This
branch started with Kevin McLaughlan's remark to the effect that a
degree only shows you're good at tests and where he quoted his
grandfather's saying that education doesn't make you smarter. IMO,
both he and his grandfather are wrong. Kevin because a degree also
demonstrates learning ability and a vocation degree (like MBA) shows
that the holder is trained to, and has achieved, a certain minimum
standard. Kevin's grandfather not only because an increased knowledge
of a subject you use in life imparts greater ability, which many would
consider being smarter, but also because of the point I made in the
post to which you responded. Next, Leonard C. Porrello responded by
parodying Kevin's quote - to which Kevin took offence. Now although
Leonard had (IMO) a valid point, it was lost because of the manner in
which he made it. From this, tech writers might learn to avoid
parodying their audience's heritage. From that point, others claimed
to have taken offence along the thread for various reasons, and from
each one can identify a pitfall.

That said, my post is also relevant (IMO) to technical writing because
the linked article suggests ways in which we can structure our
documents to help the reader get to grips with the subject matter more
easily. Repetition and transferability are key IMO. I now see the "cut
and paste, search and replace" technique to copy documentation of one
task to another, similar task as quality assurance rather than
laziness or efficiency. The repetition should help our readers link
the tasks and so use the same basic procedure in each case. In
contrast, I suspect a reader would find it more difficult to link the
tasks if they were documented differently.

HTH,

-- 
Geoff

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing 
solution. Author in Doc-To-Help's XML-based editor,  Microsoft Word or 
HTML and publish to the Web, Help systems or printed manuals. 
http://www.doctohelp.com

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info. 

Please move off-topic discussions to the Chat list, at:
http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat