RE: Baiting for the single source rant
Darren Barefoot's comments hit a point I've been wrestling with, and for
which I would greatly appreciate feedback.
The point is that single-sourcing strategies may be more advantageous for
uses other than the production of multiple docs from a single repository of
verbiage.
Exactly.
I was first exposed to single sourcing many years ago in an engineering context. A company with whom I was interviewing was developing an in-house custom solution. I have no idea whether the project was ever completed, but it from an engineering project manager's point of view it was a dream come true.
On a large engineering project, there are thousands of "data bits" (for lack of a better term -- I'm sure there is one, and I'm sure I'll hear about it). It would be of great benefit if, when one of them was revised, the change was instantaneously global.
For example, take a pump. Data about this pump appears in a number of places: PFDs (process flow diagrams, a high-level representation), P&IDs (piping and instrumentation diagrams, the more detailed representation), equipment specifications, instrument diagrams, instrument specifications, line lists, equipment lists, instrumentation lists, purchase orders for the pump and its supporting equipment/instruments... you get the picture. A single bit of data, for example the pump number, might appear in literally hundreds of places. And a number of different people are responsible for maintaining the various documents.
So any time a piece of information about that pump is revised and approved, all of those people must change the docs they are responsible for. The engineering company I was interviewing with was creating a database-driven solution so that such a change, made in one place, would be reflected in all these kinds of documents.
This was long before SGML or XML became popular solutions. I have no idea what was driving the back end. But I was very disappointed that they didn't hire me, because I would have loved to see that system in operation!
I think single sourcing is most successful when the material being re-used is chunked very, very small, down to the phrase or even to the word. Help material and manuals should not be written in the same way that marketing material or purchase orders should, yet many of the "data bits" appear in all of these places. It's the re-use of the smallest bit that is the most useful, and the chasing of them for revision control that is the most time-consuming.
What I see happening all too often, as others have pointed out, is the repackaging of the same writing to various output media. That's what single sourcing seems to mean to a great many technical writers, and therefore to their project managers. But it doesn't create the most effective documentation.
Win
--------------------
Win Day
Multimedia Developer
http://www.creativeimplementations.com
mailto:winday -at- creativeimplementations -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A landmark hotel, one of America's most beautiful cities, and three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.com http://www.miramo.com +++
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
Previous by Author:
Re: Working for a subcontractor
Next by Author:
Re: Contractor Rates
Previous by Thread:
RE: Baiting for the single source rant
Next by Thread:
RE: Baiting for the single source rant
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads