Single Sourcing – Is the Gain Worth the Pain?

Single sourcing has captured the imagination of the technical communication community like little else has over the recent past. Single Sourcing has managed to spawn admirers and skeptics in equal measure. Supporters believe that single sourcing is the future, and the long-term gains outweigh the initial pain. Despite its undeniable advantages, a significant section of experts believe that the effort and resources required to implement the single sourcing strategy outstrips its benefits. So, read on to see what people who have seen it and done it have to say…

Naresh Reasons Out...

I recommend single sourcing. Before reasoning out my recommendation, I would like to address the definition of single sourcing.

Single sourcing is commonly defined as writing in one editing tool and producing multiple outputs, such as printed books and online help. An example would be using Adobe FrameMaker to create content and then generating PDF and context-sensitive online help from the source files using Adobe Acrobat and WebWorks Publisher.

The not so common, but technically correct and complete definition of single sourcing is creating one master document and reusing the same content across different documents and document types. For example, maintaining one source document for various types of information such as installation instructions, system administration, and user tasks and then extracting appropriate content from this master document to publish installation guides, system administration guides, and user guides. The same information can also be published in different formats such as printed books and online help. One of the best tools available for this documentation methodology is ArborText EPIC, an XML editor.

To substantiate my recommendation, I would like to put forward some inherent advantages of Single Sourcing.

Advantages of single sourcing:

• Facilitates easy creation of output

• Promotes high reuse of content, thus reducing redundancy

• Lowers translation costs considerably

• Enables centralized document storage and management

• Controlling and tracking information updates and revisions is comparatively painless

Single sourcing also gives rise to certain challenges. Complications due to different authoring tools and the threat of duplication of content are some of them. Managing styles/standard practices in a distributed environment is also a constraint to be dealt with.

In conclusion I would say that single sourcing saves time and money; and also improves the quality of documentation.

Naresh KN is Documentation Manager with Oracle Process Manufacturing (OPM).

Frederick Menezes Points Out...

Is it nirvana or is it just a hyped-up buzzword? Between arguments for and against it, “single sourcing” is still a misunderstood term.

Single sourcing is not about converting a document from one format to another. Neither is it about converting a print document to an online document and then tweaking it to suit the online medium. Or vice versa. That would be “repurposing.”

Single sourcing is the process of using a single source document to generate different versions of the document, each of which is suitable for a specific purpose and medium. For example, in software documentation, you could generate a getting started guide, an online help system, and a printed user guide from a single source document. Even further, if the software product works on both UNIX and Windows, you could use the same source to generate two different user’s guides: one specific to UNIX and the other specific to Windows.

If such a single sourcing mechanism works, it holds huge advantages for documentation organizations. Single sourcing would avoid the duplication of documentation efforts, facilitate quicker document updates and reviews, ease document management, and reduce errors and inconsistencies across different documents. All these factors translate into significant cost savings.

But, that’s just one side of the single sourcing coin.

Planning and implementing an effective single sourcing strategy is a substantial effort. Documents generated through single sourcing have to be suitable for a given purpose and medium. What works online may not work in print. What’s appropriate for a getting started guide may not be appropriate for a user guide. What’s true on UNIX may not be true on Windows.

Tools can facilitate the single sourcing process, but only to an extent. It’s not too much of an effort to build templates or data definition files that would aid in the single sourcing process. Besides, building this framework is a one-time effort.

The bulk of the challenge lies in the writing strategy. It is critical for a writer to have a thorough understanding of each medium and the purpose of each document. The content must be extremely structured and exceedingly modular. Every step of the way, the writer must pause and reflect: Does this work for that specific document? Is this medium-neutral content? Do I have to add some medium-specific content? And so on. Writing in such demanding circumstances is not easy. And that’s an understatement.

So, while single sourcing means a significant gain, it also comes along with considerable pain. Thus, single sourcing is not effective in all scenarios. It works for comparatively bigger documentation projects. I would say that the printed user guide must be at least 500-800 pages to even merit a discussion on whether the associated documentation project should be single sourced. If the documentation project is smaller, forget single sourcing. The pain won’t be worth the gain. Repurposing will work just fine.

Frederick Menezes heads the Technical Services Education development and localization teams with VERITAS Software. He is the founder Editor of INDUS, and a past president of STC India.

Mayur Polepalli Opines...

In my opinion, single sourcing in its current shape seems more of a dream than reality. I feel this way after having tried to implement it enterprise-wide using various single sourcing tools. Also, it needs to be understood that single sourcing is more of a mindset, than just a tool. Here’s why I have reached this conclusion.

Inconsistent Writing Styles

When a document is single sourced, the writing style needs to be consistent. Here’s a test. Pull out a couple of documents from different writers in your organization. Invariably you will find that writing styles vary a lot. Hence the output from single sourcing is bound to be a collage of documents.

Audience Variation

To put it simply, what about the problem of grey/gray? Will you have a list of words that will be replaced depending on the audience? What is the kind of effort required to realize (or realize?) all the variations. Did you know antenna is U.S. English and aerial is British English?

Presentation Medium

Isn’t a large part of the content in a user guide different from that of an online help system? How would single sourcing help if the content is different? How would single sourcing help if the content is different?

Upgrading

Here’s a scenario to mull over: Single sourcing has been implemented enterprise-wide using ArborText. Two products use the same chunk of content. Product A extracts the relevant section from Product B. Product B is updated. How will this be cascaded to Product A’s doc team?

Locating Content

Assuming you have one doc server, how will you try to locate relevant bits of content? ArborText and FrameMaker don’t really support meta tags.

Application-Specific Content

The levels of user assistance vary depending on the product. For a certain application, I have gone to the extent of writing, “Click the (X) button in the top right hand corner of the screen to close the window.” There are other situations where we assume the user knows this operation. How can we single source content for both these applications?

To implement single sourcing in an organization, all the writers need to have the same writing style. Newer roles will need be created. For example, a writer can be asked to sift through the repository, to identify duplicate content or create a list of commonly used procedures. Until this happens, single sourcing is only a dream!

Mayur Polepalli is a Technical Writer with Oracle Corporation, Bangalore.

STC India | Home | Contact Us

Copyright © 2005 India Chapter STC. All rights reserved.