The field of technical writing is making a push toward single-sourced content. This involves authoring in one place and being able to chuck the content into different formats, such as help systems and manuals. It’s supposed to make things better for content management, as well as for localization because you have only one set of content that has to be translated.

I personally haven’t bought off on this yet. For me, there’s one basic hang-up.

When I’m using a software application and run into a problem or want to do something that isn’t intuitive, I generally check the online help first. That’s just what I do—I create help systems myself, so I figure I ought to use other help authors’ material. Imagine that I can’t find what I’m looking for there. So what’s the next option?

If there’s a manual, I check there next. Perhaps there’s something extra in that size XXXL book sitting on the shelf. It doesn’t take me long when I check the index and start looking at the content to realize that the manual is exactly the same as the online help. The only thing that’s different is the output. There aren’t any more answers in the manual than there were in the help.

Personally, that’s frustrating.

If I see a different form of documentation, I expect there to be something different about the content, too.

This scenario reflects a pure single-sourcing practice, most likely. But I have experienced this frustration of having identical content in two formats.

I felt this way even before a certain project required me to create both a manual and a help system. The application accommodates complex business processes. The manual is task-based, taking users through the steps needed to complete their responsibilities using a number of screens. The help, however, is context-sensitive, giving a screen-by-screen explanation of the functionality.

If a user wants to know how to complete a task, she consults the manual. If she has a question about a specific screen during the process, she clicks Help. A PDF version of the manual is available in the application, so even users who don’t like a hard-copy book still have access to the manual’s content.

But wait… The glossary in both the help and manual are the same. Does that count as single sourcing? Probably not, because the source of the glossary content isn’t the same. It was a good old-fashioned copy/paste job.

Not every project fits the aforementioned model, which is why I think that single sourcing can be advantageous in many situations. But I don’t think it’s a cure-all for the challenges of technical writing. Much like any approach to a project, one ought to analyze the situation and see if single sourcing is appropriate in that case. If it’s beneficial for the user experience, do it. But if the users expect something else, go that route.

This may sound like an overly simplistic view of things. Obviously, organizations are concerned about time and money. Using one content source saves both. Absolutely true, but it may cost something else—the user’s ability to understand the product. To me, that’s the most important consideration. Some single-sourced outputs do vary the content to some degree, but the farther your output formats are from identical, the more work you’re adding, which is probably why some organizations do try to keep the single sourcing pure.

I expect to be single sourcing in the future. It has many benefits. My goal will be to assess whether that meets the needs of the users as well as the organization.

Related entries (auto-generated):

Why I Wasn’t Sold on Single Sourcing (and Why I’m Changing My Mind)

Switching to Single Sourcing: Not a Light Decision

A Tech Writer’s Christmas Wish

An XML Experiment Fizzles

My First Five Years as a Professional Communicator