Why I Wasn’t Sold on Single Sourcing (and Why I’m Changing My Mind)
November 17th, 2009I mentioned in my last post that one of my technical writing colleagues showed the user education team a spreadsheet where he had taken types of information, such as concepts, tasks, and frequently asked questions and indicated what types of deliverables it made sense to use them in.
Historically, I haven’t been a big fan of single sourcing content because I hate it when the content of the manual is exactly the same as the online help. I particularly remember trying to learn the basics of FrameMaker 7.2 in college, only to find that the lack of answers in the online help was duplicated in the manual on the computer lab shelf. So I think experiences like that—where someone thought single sourcing meant the exact same content in different formats—soured me on the idea of single sourcing.
In one project, we’re having to cut over from an old Business Objects environment to a new reporting environment. I was involved in the meeting where we planned how to manage the cutover. The program manager said that it depended on having a quick reference guide ready, something that described how to do the most important tasks in the new environment, such as scheduling reports, rescheduling, and changing preferences. Having already updated our application’s help on reporting, I could promise the guide would be ready in short order.
My single sourcing technique in this instance leaves a little to be desired, but I generated Word documents from RoboHelp of the topics I wanted in my guide. Then I imported them into InDesign using the Place function because InDesign is still my favored tool for quick reference guides. (This import actually works well if you have all styles accounted for in both documents and map the Word styles to InDesign styles.) It took me some time to massage the layout and edit the content (resulting in some changes to the original, so I admit it’s not true single sourcing), but the guide was done and ready for distribution in less than half a day.
It was with this task as a backdrop that I went to the team project review meeting and my colleague showed this spreadsheet. Because I had just used some help material to create a quick reference guide, I was seeing the merit of the kind of reuse his spreadsheet demonstrated.
So I’m changing my mind about single sourcing content. It’s about serving up different combinations of information to meet different audiences’ needs. It’s not so much about having the same content in different outputs, though that’s involved. I will be a bigger fan when it will mean authoring everything in one tool and being able to mix content and design more equally. Perhaps when I get into new projects with Flare, the templates (or master pages or whatever they’re called) will allow me to design print outputs to my satisfaction.
Related entries (auto-generated):
The Reason I Haven’t Embraced Single Sourcing
Switching to Single Sourcing: Not a Light Decision
Reviewing Projects and Deliverables as a User Education Team


November 17th, 2009 at 8:00 pm
Hey Ben,
I’m a big fan of single-sourcing, and we’re still working on implementing it successfully. I’d actually call producing online help and the user guide from the same content repurposing rather than single-sourcing, but that’s probably getting into some nit picking.
We do single source to a degree between our online help and our training books (still a work in progress). We are trying to reuse the task or activity steps from the help in the training books, with content like business processes staying mainly only in the help and scenarios only being in the training. Our team has been cut down this year, and our scope of work hasn’t really been reduced. So we have to use the ideas we were trying with our former larger team, but it’s more crucial now that we don’t have x number of people devoted to training material and y number of people to the help. Or, with some products, we don’t have the luxury of employing a separate instructional designer who can create training materials.
Our user guides are generally a PDF form of the help. Not perhaps the most ideal user experience, but our core focus is on the online help, and we produce the PDFs because customers want to be able to print.
[Reply]
Ben Reply:
November 19th, 2009 at 7:28 pm
That’s a benefit to single sourcing that I hadn’t thought of—maximizing the use of content to make up for fewer team members. Even if you have more team members, it could reduce redundancy among team members’ work. But that takes some additional coordination.
[Reply]
November 17th, 2009 at 8:42 pm
Hi,
Single sourcing really works, provided you set it up correctly.
I do not use it now for a variety of reasons, but I have been very successful with single sourcing in the past and the techniques I used then are useful even now in a non-single-sourcing environment.
My experience was with FrameMaker and WebWorks Publisher, but I’m sure there are other techniques that work almost as well .
Cheers,
Sean
[Reply]
December 4th, 2009 at 5:59 am
“I’m changing my mind about single sourcing content. It’s about serving up different combinations of information to meet different audiences’ needs.”
This is spot on. And sometimes the information must be presented differently, or even rewritten, for different audiences’ needs. That doesn’t stop it being single sourcing.
[Reply]