RE: Queries on Single Sourcing

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.

/kevin




Previous by Author: RE: GoLive vs. Dreamweaver
Next by Author: RE: Queries on Single Sourcing
Previous by Thread: RE: Queries on Single Sourcing
Next by Thread: RE: Queries on Single Sourcing


What this post helpful? Share it with friends and colleagues:


Sponsored Ads