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: Queries on Single Sourcing From:Mailing List <mlist -at- ca -dot- rainbow -dot- com> To:"'lyndsey -dot- amott -at- docsymmetry -dot- com'" <lyndsey -dot- amott -at- docsymmetry -dot- com>, TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 13 Feb 2004 15:25:04 -0500
lyndsey -dot- amott -at- docsymmetry -dot- com wailed:
> Ack! I am now ready to go back to being a Luddite.
>
> This reminds me of a company I worked for where each R&D
> group had its own techwriter(s). One group had rather
> a lot of writers compared to the other groups and it
> was lead by a guy who described himself in hushed tones as
> "not a technical writer, but a Documentation Architect."
> This guy had implemented in his group a system such as you
> describe. The idea was that you could re-use any chunk
> of text, assuming that you could find it in the huge
> repository. In fact, writers were required to look for
> it in the repository, whether it was there or not. The
> fact that, when and if it was found, it had to be tweaked,
> and the fact that I have rarely re-used an untweaked chunk
> of text in my entire career,
[...]
> Call me wishy-washy, but I'm a Luddite again. I can see how
> single-sourcing would work for the help, training, and
> manuals, etc. in a single project, but to try to make it
> work over more than one project sounds like a complete
> waste of effort and a form of bureaucratic abuse.
Well, a lot of companies have products that build upon
previous products, and/or multiple, concurrent products
that share common hardware, code, interface elements, etc.
But I think my point was that it would be completely
silly to go to the trouble of creating a repository
of information chunks, merely to have the writers
manually search for chunks that they "needed". As
soon as the repository got large, it would become
more economical to just re-write material from scratch
rather than spend endless days trolling the muck for
a gem.
BUT, if you create a repository AND surround it with
useful, well-planned meta-data -- keywords, descriptive
fields, relationship fields, etc., etc., you are
effectively building intelligence into the repository.
If you do it right, then your extraction can be
rules-based and therefore automated to a large extent.
The trick is (are):
1) you have to be very good at creating useful meta data
to give life to your database/repository
2) you will still be wrong / have forgotten something,
so you should also have created your database in a
manner that's easy to extend both content and associated
meta data.
So, all that to say that that kind of repository is
something that I can admire from afar but, as the lone
writer at my location, I won't be trying to implement.
The closest I'm getting to "single-source" is that I'm
using condition tags in my RoboHelp project that is
being re-used for several projects/products. Perhaps
60% of the Help pages are common (so far) -- others
are either turned off for the latest product, or are
added in, new and don't apply to the other product(s)...
and with a little luck, the condition tags will let me
automate the output WebHelp.
