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: What's So Common About Content From:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 6 Nov 2002 09:43:52 -0500
<<I can imagine a scenario where one mocks up a user interface in a program like
Visual Basic, puts together a spec, and then invites a group of tech writers to
debate how best to approach the documentation. One could conduct a similar
exercise for non-software products, possibly using common household objects.>>
Which on the face of it seems like a good idea. But, how do you maintain the
interest of non-software during software exercises and how do maintain the
interest of software types when you do hardware/non-software. Also, how deep
does the development of the mock project go? Seems like a good school exercise
but risks being far too light and devoid of real substance for participation by
professionals or to result in a true simulation of document production. I for
one am not going to participate in any sort of exercise to document coffee pots
and toasters when on a daily basis I must document the overhaul, inspection,
troubleshooting, and operation of hardware with thousands of mechanical,
electrical, and electronic parts. Those documenting jet engines may probably
find what I document simplistic.
But I also think it's a fallacy to believe that you need an actual product in
order to discuss what the best ways are to approach documentation. Best
practices should be able to be discussed in generic terms.
Perhaps more useful would be case studies of actual documentation projects that
could be examined for what went right and what went wrong. If handled correctly,
the documentation of the process could help the management of the company as the
project progresses and the examination afterwards could also be very beneficial.
Eric L. Dunn
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!
Order RoboHelp X3 in November and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/techwr-l
---
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.
