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.
Sheldon Kohn is <<... seriously considering implementing single-sourcing
throughout the company... everyone is excited about the possibilities the
approach offers and the real benefits we information developers bring to the
company under such an approach. Another obvious advantage is that we could
leverage the fact that our company is fairly young to establish the system
and processes as part of our culture without requiring extensive re-work.>>
The first thing is to make it clear that single-sourcing does not mean
dumping your printed documentation online, unmodified, nor does it
necessarily mean "write once, reuse everywhere" (although that's much closer
to correct). Both misperceptions can produce efficient _processes_ that
produce products that are hopelessly _inefficient_ for the readers. Strictly
speaking, the goal of single-sourcing is to write information so that it can
be reused, but not necessarily without some modification to account for the
different needs of different media. For example: You can't create truly
context-sensitive help in print, because the help isn't part of the
interface and can't be summoned simply by clicking a button when a given
dialog box is open. Conversely, context-sensitive online help doesn't
necessarily translate into good printed documentation (e.g., the wizards
don't work at all on paper, and the hyperlinks have to be replaced with "see
also" references). Saying that "the Name field can hold only 10 letters" or
"don't press this button" doesn't change between the online and print
versions, and that's the kind of information that really benefits from
single-sourcing.
My only experience with single-sourcing has come with relatively small help
files, and I've been able to accomplish what I wanted without sophisticated
tools: it's been mostly a question of fixing the text once for the printed
beta user manual, then moving it online with appropriate modifications for
the change in context. For more complex projects, keep asking the questions
here; we've got members (e.g., Mark Baker) who can give you the nitty-gritty
details far better than I can.
Hofstadter's Law: The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law.