“Single-sourcing” describes situations where one file or database of information contains material that is reused for more than one product or more than one information deliverable. Two common scenarios are:
- Two or more products having much in common, such as related models of microwave ovens or laptop computers or “light” and “pro” versions of software. Rather than maintaining two copies of the common information, one copy is reused. Writers use various techniques to merge the common information with the variable information.
- Two or more deliverables are produced for one product; for example, software often has a user’s guide and online help. Much information is in common, but the way that information is combined and presented may vary quite a bit (and references to “page number x” must be removed in the help system or changed to something that makes sense in context).
To complicate a single-sourcing solution, many projects may include both conditions mentioned above: multiple related products, each delivered with more than one information deliverable.
This article does not address the (important) questions of when a single-sourcing methodology is a good solution to an information delivery problem (“good” here meaning saving time and money while maintaining or improving the quality of the resulting deliverables). Instead, I’m looking only at the editor’s involvement in the project.
I asked the HATT (Help Authors’ Tools and Techniques) group these questions: “How do successful single-sourcing projects handle the editing? At what stage are your editors involved? How do the editors deal with the material — with all the conditional material in the copy they edit, or with each output deliverable separately (seeing only the subset of stuff that goes into that deliverable), or both, but at different stages of the project? What are the good and bad points of the methods used?”
The answers, as expected, included “We don’t have an editor.” Other responses confirmed my experience that editing (whether done by an editor, the other writers, or someone else) occurs at these stages:
- Editors review individual chunks of information for grammar, style, and so on, during development of the material, either before they are entered into the common database, or in conjunction with technical reviews of the same material.
- At a later stage, editors review the chunks of information in files containing all the variations. With the right software, editors can look at the chunks of information in context (one deliverable at a time) by “turning on” only that deliverable’s chunks or they can look at all the related chunks (for different deliverables) at once.
- After changes from this editing pass and the technical reviews have been made, editors (or someone in QA – Quality Assurance) are given the individual deliverables to review, to make sure the right chunks got into the right deliverables.
Few organisations do all three of these editing passes.
Editorial markup may involve PDFs (either writing on printouts or electronically marking up the PDFs), a common scenario in FrameMaker environments; or editors may electronically mark up Word files, help databases, or HTML files. My research suggests that writing on paper is still the most common method used, at least in departments with trained and experienced writers who are responsible for the final output.
Last updated 18 January 2002