skip navigation

An Introduction to Single Sourcing – Part 1

By Justin Darley, January 2003

Section 2 - Obstacles to single sourcing

So far so good, but clearly the issues that created problems when we were simply duplicating information have not disappeared. If single sourcing were easy we would have been doing it for years. So what are the obstacles that have kept us cutting, pasting, editing and reformatting for so long?

The problems associated with single sourcing are intimately linked with the benefits mentioned above. Successful single sourcing will, in the long run, free us from manually editing content to suit a range of different outputs. Unfortunately, to achieve the potential gains, and avoid the duplication of effort we may have been used to, we need to create mechanisms that will account for the different media, purposes and audiences that we aim to cater for.

This can be a time-consuming and potentially costly process. It is a process in fact that impinges on each of the areas of information development. The following table shows just some of the areas for concern:

Writers

  • Need to take account of phrases that may exclude users accessing their information via particular media or platforms. How will users click on a paper manual? How will Mac users push the Windows key?
  • Need to be aware of each of their audiences and of which pieces of information are relevant to each.

Information designers

(responsible for the visual design of information)

  • Need to research extensively the differences in the proposed media. Will that fetching shade of cerise be rendered appropriately on a 256-colour display? Will it be legible if printed in greyscale? Are the fonts you have chosen installed on a Macintosh?

Information technicians

(responsible for developing the technical process)

  • Need either to create a technological framework, or to learn and make use of one of the off-the-shelf solutions

Knowledge managers

  • Need to be familiar with the revised roles and considerations of both writers and information designers. It may well fall to knowledge managers to hold the whole process together
  • May find themselves liaising with content developers who have previously moved in very different circles and written to very different rules

A need for a user focus

All of these obstacles and changes of roles serve one major purpose: ensuring that single sourcing addresses the needs of users. The aim is to ensure that all outputs are usable and the key is user focus. All parties involved need a clear perception of the needs and limitations of the targeted users.

Each output must be customised to cater as closely as possible for its potential users. If your single sourcing effort is 100% successful then users should receive information as perfect for their use as if it had been written solely for them. Perhaps this goal is unrealistic, but I believe we can get very close. With thought and care it is possible to deal with these obstacles. By adopting the following strategies you can create single sourced information that is customisable to meet the needs of a range of users, diverse media and multiple goals.

Strategies for single sourcing

The required strategies for a successful single sourcing project fall into two categories: analysis and granularity

Analysis

Those of you familiar with Cherryleaf's user-focused philosophy may well know what's coming next! The key to any successful piece of documentation is to analyse the intended audience. This focus on the user's needs is, if anything, strengthened in a single sourcing environment. As mentioned above, we need to know all about our users. In a single sourcing environment, however, the analysis doesn't stop here. Not only do we not have a unified (or at least broadly similar) audience for our information, but we also have users in a range of environments using a range of equipment.

To cater for this change in circumstances we need to be better informed on a range of technical issues. At the simplest level we need to re-acquaint ourselves with the fundamental differences between paper and online formats, but it doesn't stop there. If we are truly single sourcing then our users will be accessing the information on a range of platforms. You will need to know what the Macintosh equivalent of the Windows key is (or the PC equivalent of the Apple key for Mac users). The online formats that you produce may also differ: you will very likely need to move beyond Microsoft HTML Help. Content itself may differ: installing software, for example, on a Linux machine may be very different to installing on a PC.

Aside from the technology, you may well need to appreciate the requirements of a broader range of audiences. Training courses can be very similar to user guides but not identical: they are likely to require a greater depth of explanation and the provision of practical exercises. A sales brochure on the other hand may require much higher-level explanations of functionality.

In brief, you need to analyse the following for each output:

  • Who are the users of this information?
  • What do they need to know?
  • On what medium are they viewing the information?

For online outputs, or for software documentation:

  • What platform are your users using?
  • What are the limitations and possibilities of this platform?

Once these areas have been examined we can move on to the technique that will provide us with the degree of flexibility needed to make one source of information cater for a wide range of uses and audiences: granularity.

Granularity

To achieve the flexibility required to produce multiple outputs from your single source you need to be able to do three things:

  • Represent a unit of information in more than one way
  • Include or exclude units of information based on output
  • Use a unit of information to carry out more than one function

Doing any of these requires that these units of information be identified. As a Help Author by trade I was used to working with units of information generally no smaller than a topic. Those of you who primarily write for paper may work in larger units still. For single sourcing we need to increase the level of granularity of our information, in other words we need to think about our information in smaller units. An example:

Diagram showing how a topic is granular and content can be reused

As you can see the size of a unit (or grain) of information may well be much smaller than a page or topic. We might need to exclude content as small as a single sentence or even a word or letter. We may also need to exclude tables or images.

Granularity is not just about including or excluding content. We will also need to identify grains of information to alter their appearance or to change how they are used. The title of the topic above would probably be a simple heading in a paper output. In HTML however we may well want to out put this information twice: as a heading and as the title element for the file. We may also want to perform string splicing and convert it to serve as the name of the file.

These points:

  • Excluding content
  • Altering appearance
  • Altering function

serve to identify the grains that we need to control. Anything in your information that you may need to exclude, reformat or alter the function of will need to be identifiable as a grain. Your chosen single sourcing technology will then collect these grains and assemble and format them as appropriate for each of your outputs. In other words, if the process that generates the outputs is to include or exclude something, or to change how it looks, it needs to be able to find it. This is usually done by one of two methods: by holding the grains as fields in a database, or using a mark-up language.

Next: Section 3 The technological framework