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:RE: Using the STOP methodology From:"Sean O'Donoghue (EPA)" <Sean.O'Donoghue -at- ericsson -dot- com -dot- au> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 18 Sep 2001 10:28:06 +1000
Okay I am getting into this discussion a trifle late.
Yes STOP documentation sounds like it has overhead costs - but if it sells
and works to add value, recognized by the customer/buyer, then go with it.
My addressing of this topic is a little sideways, in one of his emails
Michael stated:
>>I'm out to get rid of
>>the traditional techwriter as a specialist presenting information in a
>>specialized way with specialized tools. Instead, the techwriter should
>>specialize in setting up easily maintainable docs that can be filled in
and
>>edited by anyone on the team, and even built by anyone on the team.
Whilst this is a great business case - that anyone can do the documentation
In My Very Modest Opinion it ignores the real point of why technical writers
exist.
It isn't because of the tools - lots of
developers/programmers/engineers/office staff can competently use all the
tools of a technical writer.
It isn't the formatting, as a good documentation consultancy house can come
in and "set in stone" templates to control how information will appear.
It is quite simply because we write.
One of the least appreciated skills most technical writers possess (and we
should all possess ;-) is the ability to write accurately and concisely.
Often people on the "team" look on the writing as the "dull" part of the
job, a needless requirement forced upon them by management. As everyone can
write it is the belief that technical writers are not required because "Joe"
can write it; and usually Joe thinks he did a really good job. Only later
when it is read by someone else are the weaknesses of this approach usually
noticed.
Maybe all those "complex" tools, and hideous complicated formatting issues,
are the manner in which managers preserve the egos of employees by
disguising the simple fact that we rewrite correctly what others had
previously written badly.
*****
Oh and one other minor point - if anyone wants the world's simplest, purest,
most efficient, quickest formatting tip....three words - more white space.
Let the words have space to breath.
regards and thanks,
Sean O'Donoghue-Hayes
sean.o'donoghue -at- ericsson -dot- com -dot- au
(61) (03) 9301-1695
EAA/N,
Melbourne Central, Level 49,
360 Elizabeth Street,
Melbourne 3000
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.