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.
>>Maybe you can gloss over some of the more esoteric aspects of the "How."
>>But a basic understanding of how something works is necessary to
>>documenting it properly. It should never be "optional."
Looks like we've resurrected the how technical is technical enough thread.
Andrew, I think you are often a little too tough on people that already have all
the technical knowledge they require. I challenge anybody who's worked up about
all those non-technical writers out there to come up with just one post that
says basic understanding of the topic is "optional".
As I document the operation of a subway car, and how to engage the propulsion
system, I need no knowledge what-so-ever about the processes involved with high
voltage DC to 3-phase high power AC inversion. Nor do I need to know anything
about the software complexities of how wheel slip and slide calculations are
made and how the IGBT transistors are controlled to modulate power output.
While I have an understanding of these issues, I can quite effectively document
the inputs required by the operator and the results they will experience while
operating the train without that understanding. I could even go a very long way
into documenting how to maintain and repair these systems without that
knowledge. Surprisingly I can also give them detailed operational instructions
without knowing the first thing about the railroad's operating rules and
regulations (although when we don't have that information we have to be rather
global with the "Established regulations take precedence" warnings).
I have yet to see anyone argue something to the effect that I don't require at
least an understanding of where the voltages go in, where they come out, and
where they remain live even when unplugged. Which is what whomever is identified
as anti-technical seems to be accused of. Now the more knowledge I gain about my
subject matter the better off I am and the quicker I may grasp what I have to
document. But also, I have no need of learning enough to design a train from the
ground up (although as a mechanical engineering graduate I suppose I have).
To bring all this to an example given, the knowledge about the intricate details
of watch operation may interesting, but if my boss says "We need a user manual
right away, they need to know how to put it on and tell time." I couldn't give a
rat's *** what makes the hands go round or if it's waterproof if I don't have
the time or budget to find out. If I obsess about how it works I'm just as bad a
writer as those that obsess about process or format.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Learn about tools and technologies for user assistance developers at
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.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.
