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.
In response to an inquiry about single sourcing, Tim Altom wrote the text
that appears below. A thoughtful and articulate response. Thank you Tim.
Eric O.
Compuware Corporation
------------------------------
Your dilemma points out a problem many people have with single source: They
hope that tools provide single source. They don't and never will.
Single source is a process of planning, analysis, and structure. Tools are
secondary. We use FrameMaker as a core tool because of its power, but we can
and do occasionally do single source with Word. It's slower and less
flexible, but completely doable.
Simply Written believes in single source, especially for task-based
documentation. If you tend to write narratives instead of tasks, then single
source will be nearly impossible. But we write task-based documentation;
it's the basis of the Clustar Method. Using the Clustar Method we've done
many single source projects, in different tools. But we plan, analyze, and
only then implement. Just trying to port to a tool won't produce good single
source. You have to develop the front end first. Tools are just technology,
and technology can be made to work even if the solution is kludgy. It's the
analysis that's hardest to do. FrameMaker can make any manual look any way
you want. But that's only formatting. It's structure that drives single
source.
And remember that single source inevitably involves compromise. The Clustar
Method has its own built-in compromises that we've tested and honed, but any
method you use will involve compromises. If you start with an optimized
hypertext document, you won't wind up with a good print document, and vice
versa. You need to start with an acceptable parent document to produce both
an acceptable print and an acceptable hypertext document.
My guess is that you'd be best advised to examine the foundation of what
you're doing, and see if the problem is in the organization, rather than in
the technology. I know this is time-consuming, but we've found that
piece-meal technological solutions inevitably wind up being less efficient,
rather than more so, because you spend so much of your time trying to do
workarounds.