Single sourcing part 1: the definition – by Nicholas Graziade

I have simple question: imagine you know about 100 content pages that contain a definition of your company's product, "Whirligig 1.0." Sure, the content varies from page to page, but this definition is the mission statement that truly gets the point across. It is the honest, Gospel truth about Whirligig 1.0.

Then it happened. Last week, the development team released Whirligig 2.0, which vastly expands the product's capabilities. It's an exciting chapter for the whole organization. Your years of innovation have really hit the nail on the head! And, naturally, the marketing team have redefined that mission statement. And, of course, it is not a small change. It is not something that you, the humble technical writer and all-around knowledge management pro, can brush aside with the claim that the current definition is simply a "broader stroke." No, you will need to update that definition on every known page. In fact, you will probably need to scour your knowledge base for every UNKNOWN page that also includes that definition. Your sigh might well make the floor rumble: this is no small task.

I've managed knowledge bases that ranged from hundreds to thousands of pages of discrete topics, and if I could identify one thing that made content consistency manageable, I wouldn't even pause to think. The answer is clear: single-source publishing.

What is single-source publishing?

I will confess that it took a couple years into my professional life to really discover single-source publishing (sometimes known as single sourcing – my preferred term for the concept). The fundamental principle behind single sourcing is both novel and brilliant:

Use content from one place to populate content everywhere else.

However, can we call this article over? The definition is clear enough: I can take everything that I want to use, keep it in a single document file, and use that to go forth and single source everything, right? All I need to do is copy and paste from my primary document into all my subsequent content, no?

Well, not quite…

While single sourcing has a clear conceptual skeleton, there is a bit more that really puts the meat on these bones. I’d like to discuss two important ideas here: relationships and technology.

Relationships

Just as they are when humans interact with one another, relationships can get pretty complicated. However, there are three types of relationships that will help you frame single sourcing. Let’s look at these from a source (where the content starts) and destination (where the content ends) perspective.

Think about how you manage your knowledge base content, and ask yourself some of the following questions:

• Is each page in my knowledge base unique or do I use common language in several places?

• Does my knowledge base use consistent definitions or do I have slight variations in each article?

• How do I currently maintain common terms and content across my knowledge base?

• Do I have a strategy for updating common terms and content when they change?

If any of these questions give you some heartburn, you’ll want to investigate single sourcing even further. The reason is simple and goes to the nuance of what single sourcing really achieves in a knowledge base:

Single sourcing allows me to maintain my content in one place. If content changes affect multiple places, I can change the source content and allow the update to cascade to each destination.

Let me be crystal clear: one change to the source content can update dozens, even hundreds of articles. And yes, that is typically in the blink of an eye!

Technology

I hope you can agree that light speed updates to content is amazing, but how can you make this a reality? Well, this is where technology comes in. Before the Information Age, the best innovations to manage multiple copies of content were crude, but effective. Carbon copy paper, for example, allowed a merchant to provide a receipt to her customer while keeping a copy for herself and maybe even a second copy for her accountant. Fortunately, as we approach the first two decades of the 21^st Century near their end, we have a few more options. One important development uses XML schema. These have found use in single sourcing since they emerged in the 1990s, allowing documents in various formats to pull source content that match the corresponding tags. This creates two layers in your content: the source layer (which contains all the necessary markup/code/technical details), and the presentation layer (which is what you and your audience actually sees). The distinction between layers is so effective that even WYSIWYG editors preserve this idea, allowing you to create single sourced details directly in your running text. In fact, as we will see in my next article, KnowledgeOwl has ways to do this too.

Don’t leave me hanging!

If I let my consciousness wander too freely, I could probably spend the next several weeks relentlessly typing my single sourcing experiences into a veritable tome, but I’d rather leave you with some food for thought. This will help prepare you for my next article, which will dive into some of the super cool tips and tricks that I used to single source in KnowledgeOwl.

I want you to think of common text in your knowledge base that you repeat. This could be a definition or an introductory paragraph or sentence. This could be legal boilerplate or even just a really awesome way you’ve described something that you use again and again and again. But I want you to think about every place you’ve used it and even to check your articles. Does it read the same way each time? Are there any variations? If you updated it at one point, did you catch every instance? Investigate a bit – you might find single sourcing to be the solution you crave.