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:Documentation Management Requirements From:"M. Dannenberg" <midannen -at- SI -dot- BOSCH -dot- DE> Date:Thu, 27 Mar 1997 14:25:13 +0100
> >
> > There are a number of documentation management and workflow packages
> > designed to meet these kinds of requirements. A revision control package
> > for software development is definitely not the way to go. I can imagine
> > that in some companies people might say, well we got this nice thingy
> > here anyway, so why not use it for documentation. Happened to me, but I
> > very quickly came up with 100 good reasons for not doing it, and now
> > we're evaluating a couple of real doc management packages.
> >
>
> Would you be so kind as to share the best of those 100 reasons with me
> (the list)? I'm facing the same argument now from engineering, and I am
> not sure whether the ClearCase version control system will work for our
> documentation.
>
The reasons mainly have to do with things that are really important for
documentation packages but that version control software does not
usually offer. Any package I would consider would have to be able to
index my files, i.e. build and maintain indexes from Frame or Word (or
whatever) files.
You also need a very sophisticated search engine with
pattern matching, proximity searches and all that. In software
development things are usually (hopefully?!?) tightly structured, so you
always know what is where. In a doc managemant package you need to be
able to find that thingummy Jane Doe wrote last year on diesel fuel
pumps.
Presentation is also an important point, you won't usually publish your
source code on the Internet (or intranet), but you want to be able to
pull a document out of your database, convert it to HTML on the fly and
display it in a browser. If you don't want to do this, you probably will
next year. Generally, it is necessary to be able to view documents from
the database without having to start the application they were created
with.
Then there is ease of use. A source code management package is used by
programmers who usually know what they're doing. A doc management
package should make information accessible to everybody in the
organisation (which of course also means you need sophisticated
mechanisms for managing access rights) and a difficult user interface
won't help with that.
If you publish in several languages you'll want to be able to keep track
of different language versions of a document and generally support the
translation process.
Workflow is also important (the more, the bigger your company is). After
developer Miller has checked in his draft, you automatically get an
e-mail notifying you of the fact. When you've finished your editing, the
document is automatically passed on to production etc.
By the way, all these are features of packages that are actaully
available on the market, I haven't just dreamt them up. Next week I'll
hopefully have time for a little survey of suppliers on the Web, then
I'll post some URLs.
Mike
Mike Dannenberg
ETAS GmbH & Co.KG
midannen -at- si -dot- bosch -dot- de
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
