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.
My software company is headed in a new (and promising!) direction.
In the past, the developers wrote the software, and then handed it off to
tech writing (in several iterations) for us to document. Developers ended
up doing a lot of the designing, too. This hasn't worked really well for my
team--we are always getting pinched at the end between the last-minute bug
fixes (uhhhh .... I mean, system enhancements ....) and the deadline. Ouch.
I should point out here that my team has been pretty much limited to writing
user documentation. Nothing too "techie." Though we have some ideas of the
underpinnings of the systems, we don't *really* know a DLL from a SQL. And
to this point, we have had very limited roles in the development of the
online help.
Now we are moving to a "component-based" system. In this system, tech
writers are going to be pulled in in the earlier phases of the project.
Right up front, we'll be helping to write the application definitions, and
developing the help text. The new product will have "components" and will
be database-driven. These components can then be shipped in about a million
different configurations to customers--and during the implementation process
at the customer's site, our engineers will be tailoring the system to the
customer's specific requirements. At the same time, we want to move to a
paperless (or *near* paperless) documentation suite.
I have soooo many questions!
(1) In the past, our system was "modular," but we sent everyone docs for
all the modules. (Marketing and sales said maybe it would entice folks to
buy more modules.) That really isn't an option now, 'cause there's going to
be so many (smaller) modules that doing so would only confuse folks. What
tools do you use to tackle something like this? What tool can we use to
attach our docs to the specific components? If we do have to continue to
print manuals (a possibility) what sort of system would let us
pick-and-choose the chunks to ship to each customer?
(2) In the past, we've only developed the end-user manuals. As we move to
the paperless environment, I figure we'll need to at least support the
online info with *some* paper docs. An installation manual? Reference
cards? What else? Are tutorials better on paper or online?
(3) Right now, we're writing the manuals using PageMaker on Macs. (The
development staff is all on PCs, of course.) Since we are going to have a
larger role in the development of the help system, I'm guessing that we'll
need to move over to PCs, and will have to find a new tool. Ideas?
I'm feeling pretty overwhelmed, thinking of all the things that will need to
change within my department; any and all advice is appreciated.
Patty Ewy
pewy -at- icontrol -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html