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.
Lyse Tremblay wondered: <<I remain to decide what would be the best
tool to use to develop these procedures because these are internal to
IT and most probably will not be published externally.>>
A few parting thoughts. First, the tool probably isn't all that
relevant so long as it produces reasonably clean and standardized
"code" (content). Any word processor will do for writing the
procedures, any Web software will do for creating a hyperlinked web of
information, and any database will do for storing and searching the
information. There may indeed be one "best of breed" application, but
the odds are good that _any_ modern software in these categories will
do everything you need with various degrees of elegance. But see below
for additional thoughts.
Second, talk to everyone involved in the project for a reality check on
whether you truly don't need to publish this information externally. In
some cases, there are regulatory requirements that require this; for
example, when I chaired a WHMIS (http://whmis.org/) implementation
committee and helped prepare parts of our disaster recovery plan, we
were required to store a copy of our information with the local fire
department*. There may be similar requirements for your company.
* Though when I talked to the leader of the emergency response team, he
noted that it was probably better if we didn't give him our full
laboratory database. His logic was that if his team knew what was
stored in our building, they'd be afraid to enter the building in a
fire.
Third, you'll need some form of offsite backup--disaster recovery
resources are useless to you if they're consumed by the same fire that
requires you to use them--which means some form of external publishing
is necessary. There will clearly be security issues, both in terms of
keeping those backups safe and in terms of protecting any confidential
or proprietary or strategic information in a way that also won't
prevent _you_ from getting at the information when the building burns
down and the PostIt note with the password attached to your monitor
becomes charcoal. <g>
<<Although I would like to use an authoring tool right from the
beginning to help maintain the useable content, I'm not sure I can
justify costly tools such as AuthoIT or XMetal simply because there is
only two of us TWs and others (developers) have to be able to use the
tool as well.>>
In that case, why not go for the poor man's XML solution: XHTML. This
is by no means as sophisticated and rigorous an approach as true XML,
but if you're discplined in how you code the XHTML (i.e., enforce the
use of well-formed templates), it should be relatively easy to import
the results into a power tool like XMetal for cleanup should you
migrate to full XML in the future.
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList
