Subscribe to the Journals I 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
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]