Newsletter Archives: June 2002 Columns
Single-Sourcing SIG-What Are We Using, Anyway? | When to Use Single-Sourcing | Single-Sourcing with AuthorIT®

 

Bill Swallow is a long-time single-sourcing advocate, Help author, and online publishing specialist. He is the list owner of the HATT, WWP-Users, and InFrame mailing lists, editor and Webmaster for InFrame Magazine, and speaks on single-sourcing and online Help topics in many professional settings. Bill lives with his family in Clifton Park, New York

 

By Bill Swallow

When to Use Single-Sourcing

 

It depends.

Don’t you just love that answer? I know I do. I love to answer questions with that phrase, as it often makes people stop and think (if for only a moment). Why would it depend? Isn’t single-sourcing the Holy Grail of publishing? I’ve heard so many good things about it that it MUST be just the thing I need!

Or is it?

Truth be told, there is no Holy Grail of publishing. Sometimes we can make our jobs easier for ourselves, and other times we have to roll up our sleeves and wrestle with the same beast we’ve wrestled with before. The question to ask is “What’s best for my situation?” This article will hopefully help you to understand the differences between single-sourcing, repurposing, and working on stand-alone projects, and shed some light on the benefits and drawbacks of each workflow. Knowing these differences, benefits, and drawbacks will help you determine which workflow is best for your situation.

 

Single-Sourcing

Single-sourcing is the act of producing multiple deliverables from one master set of maintained content, where any and all changes are made to the master content, and those changes then propagate to the target deliverables. The deliverables can be various formats (print, online Help, Web content, etc.) and/or be targeted toward various audiences (administrator guides, user guides, training modules, instructor guides, textbooks, etc.). The whole point is to maintain one set of information with minimal content duplication and, via a defined process, deliver that information in various ways.

Many people have defined their own theories of when single-sourcing is appropriate, and they’re all very valid in their theories and approaches. I’d like to take a step back from the fine points and attempt to explain the appropriateness of single-sourcing in a more generic manner, for there can be thousands of different scenarios in which single-sourcing can be a beneficial workflow. Ask yourself the following:

  • Do I have multiple deliverables to produce for my project?
  • Will I be re-using a significant amount of information in my many deliverables?
  • Am I expected to continue to produce and update these types of deliverables in the future?

If you answered “yes” to all three of the above questions, a single-sourcing workflow may be your workflow of choice. If you answered “no” to at least one of the above questions, you will be better off using a different workflow to complete your deliverables. Why? If you do not have multiple deliverables to produce, then your single source of information IS the deliverable; format it and ship it as needed. If you are not re-using a significant portion of information in your multiple deliverables (at least 40% of content, roughly), you are essentially working on several different projects simultaneously; create several stand-alone projects and manage them appropriately. If you are not expected to deliver this information in its various forms in later releases, you can safely repurpose your information for the target deliverable; convert it, make it pretty, and ship it.

Now, if you’re still gung-ho for the single-sourcing bandwagon, there are other concerns you need to consider. Ask yourself the following:

  • Do I have the time to define my single-source process and put the workflow in place before the deliverables are due?
  • Do I have buy-in from others who will be involved in this workflow (managers, writers, editors, etc.)?
  • Do I have room in my budget to accommodate any new tools (and perhaps training in them) needed to facilitate this workflow?

If you answered “yes” to all three of the above questions, you are safe to begin planning your single-sourcing workflow. If you answered “no” to any of the above questions, you may need to address and resolve these issues before proceeding further, or possibly look at another workflow in the interim until you can say “yes” to all the above. You need to be able to spend considerable time (how much depends on the size and complexity of what you need to accomplish) planning and implementing your workflow in order for it to succeed, else you may run into problems in mid-process that could jeopardize your projects. You need full compliance from those involved in this workflow to adhere to your process and style guides, else you may deliver information that is inconsistent in language, appearance, or structure. You need to evaluate your current tool set and potentially switch to a new tool set that will accommodate your single-sourcing needs, and with this switch may come additional costs such as training in the new tools or hiring of consultants to help you set up your workflow architecture.

 

Repurposing

Repurposing involves taking one existing document or data set and altering it to fit another use, format, or audience. Unlike single-sourcing, where all deliverables are maintained though a single information set, a repurposed deliverable is maintained separately from the original deliverable; it is a new and independent deliverable created from an existing deliverable.

Contrary to what has been expressed on many technical writing-related mailing lists, repurposing is not always “failed single-sourcing” or “the quick means to a solution”. Rather, it is a very effective means of migrating information to fill a new need. Repurposing should be reserved for projects that are transitioning from one set of requirements to another (e.g., your company wants to produce web-based online Help rather than printed manuals), or for projects that require a one-time “spin-off” of content in a different form (e.g. your company is private-labeling its product for another company, and the documentation must carry new logos and be delivered in a different style or format).

 

Stand-Alone Projects

A stand-alone project is one that does not fit any of the above descriptions. In a stand-alone project, you develop content in one medium and deliver that medium only. Though not ideal in situations where multiple deliverables are required, a stand-alone project is perfect in situations where content is developed for one specific need (e.g. a Help system). In a stand-alone project you may be duplicating information and hand-coding or hand-formatting information, but the resulting deliverable is all that really matters; as long as it’s presentation is clean and the information is present and accessible, the project is a success.

Stand-alone projects do have their strengths, some of which are more subjective than others. Writers are not necessarily required to follow a rigid means of authoring content, allowing them to be more relaxed and creative in the authoring process. Stand-alone projects can be highly customized, if needed. Stand-alone projects can also be started virtually immediately without the excessive planning you will find in single-sourcing projects (other than what information is included and how to present it).

 

What Now?

You’ve read about the three basic workflows, learned where they shine and where they fail, and are now better equipped to tackle your project at hand. Use the questions presented in the “Single-Sourcing” section to guide your decision. Better yet, pose these questions to your entire team to determine if you are all on the same wavelength, or use them to reach consensus with management and project leaders. The more you involve others in this planning process, the better chance you have at getting approval to properly move forward. You’ll also help your project team understand why you need things done a certain way once the workflow is put in place.

Remember, there are many different approaches to documentation, and no one approach or workflow is better than another in and of itself. Always analyze your needs before beginning a project, and determine your workflow accordingly. Single-sourcing may work in some cases, but will not work for others. Remember that there is no Holy Grail of publishing, only an appropriate solution for a specific need. Know your audience, know your requirements, know your options, and then make your decision.

Original source for this article is SSvsRvsSA_final_sb.doc

 

The opinions expressed by contributors to the Society for Technical Communication (STC) World Wide Web site are solely those of the individual writers and do not reflect the opinions of STC, the members of the STC administrative council, or STC World Wide Web volunteers.

Reference herein to any specific commercial firm, commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the Society for Technical Communication (STC).