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: Single Sourcing From:Tim Altom <taltom -at- SIMPLYWRITTEN -dot- COM> Date:Wed, 9 Jun 1999 09:06:02 -0500
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
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
Adobe Certified Expert, Acrobat
Simply Written, Inc.
The FrameMaker support people
We train and consult on the Clustar Method
for single source documentation
>I have brought this topic to this list twice before. I would like to
>continue to talk about it because I recently have gone through the process
>of single sourcing. I produced a software manual from the online help for
>the same software using Robohelp. This process is not quick and Robohelp
>did not generate some of the graphics from the source file. I also had to
>set up the manual in the way a manual should look like. However, the final
>result pleases me and people in the company because it looks much better
>than the one produced by FrameMaker. I found this method is durable because
>I do not have to use two different software progams to work on help and
>manual. The problems I ran across are indexing, graphics will not convert,
>formatting, and numbering. I fixed the previous three, however, numbering
>is a consistent problem, I have to be very careful when I print. I also
>sent email for the solution to this problem, nobody could fix it.