Is Single-Sourcing Dead?

Matthew Dorma of Calgary, AB pointed me to a post by Mark Baker (https://everypageispageone.com/) entitled “Time to move to multi-sourcing” (https://everypageispageone.com/2018/04/06/time-to-move-to-multi-sourcing/). I discussed that post with several people and have thought about the implicit question it poses – is single-sourcing dead – for a while. This post is the result.

NOTE: The first part of the post – Is Single-Sourcing Dead? – discusses problems with single-sourcing in general. The second part – Alternatives to Traditional Single-Sourcing? – briefly addresses the specific points that Baker raises in his original post.

Is single-sourcing dead?

In my opinion, no. The single-sourcing concept – write once, re-use many times in many ways and many places – has some problems. But the basic concept is so useful that I see nothing that can replace it yet.

What are those problems? Can they be fixed, and how?

 ·       Inappropriate tools – Today, single-sourcing is based on using tools like MadCap Flare (note that I do a lot of training and consulting for MadCap), or standards like DITA. However, companies aren’t going to buy those tools for every employee who has to write something; the cost is too high. Instead, most of those employees will use Microsoft Word because companies see Word as being free. And employees can use Word to create print and PDF output – technically, single-sourcing but lacking the flexibility and output options of full-power single-sourcing.

The result? Trying to do single-sourcing using the wrong tools.

The solution? Simple in theory. Identify which employees create what material that has to be single-sourced and buy them the appropriate tools.

 6       Inappropriate training – In the early days of word-processing, specially-trained operators did the work. Today, employees get a copy of Word and are largely on their own to figure it out – with no training. The results are often inconsistent and with ugly code, but no one cares as long as the document looks good when printed. But if that document has to be imported into a single-sourcing tool like Flare, ugly code often causes problems that few authors know how to avoid or fix. Authors need at least some training in how to use Word but few companies offer it.

The same is true in single-sourcing. Authors may have the right tool but are often not trained on how to use it, or on the concepts of single-sourcing. I often meet Flare authors who were given the tool and told to figure it out on their own. Sometimes the results are surprisingly impressive but often the authors are just terribly frustrated.

The result? The best tools are often worthless if authors don’t know how to use them.

The solution? Obvious. Train the authors on the tools. And for subject matter experts upstream who use Word et al to provide content to the single-sourcing authors, provide at least minimal training and support in how to use their tools. How minimal? Two examples…

o   A client in Austin, TX whose authors used Word asked me what those “styles” were. I explained what they were and how to create and use them. The client was ecstatic at the amount of work they could save. From a five-minute discussion…

o   A client in Connecticut was having trouble getting their authors to create consistently-structured material. They had defined a structural standard but the authors deviated from it constantly. I explained how to create topic templates that could be added to their authoring tool’s interface. The client’s employees spent about an hour at a white board laying out a template which I then turned into an electronic one and added to the tool interface in about five minutes.

          Inappropriate standards – People often have no standards to follow to when it comes to using their tools – no templates for different types of material, or style usage standards, for example.

The result? People do whatever provides the result they want, even if that causes trouble down the road when it’s time to import the material into a single-sourcing tool or output to a new format.

The solution? Surprisingly simple. Identify authors’ pain points and create standards for them. Better still, embed the standards into the authoring tools as much as possible to make their use automatic. For example, create topic-type templates with embedded prompts – “type the list of tools here” – to guide authors as they write. Or create a stylesheet with clear style names and make it the project’s master stylesheet so that it will be applied automatically to every topic.

Adding standards is surprisingly straightforward. What’s harder is getting authors to use them. That will take training and time and perhaps some management muscle to insist that using the standards is a requirement, but that’s not a new task.

          Increasing complexity – Single-sourcing requires many tasks beyond just writing the content. Authors have to decide which output is primary in order to decide which features to use because some won’t work well or at all on different outputs. That means understanding those features. Authors have to create and assign conditions to control which content to use for which output. Define re-usable chunks of content. Create style sheets that behave differently depending on the output. Perhaps define microcontent. And more. And this all must be documented somewhere for reference by the current authors and later ones.

The result? The increasing power of our tools and increasing customer demands are leading to increasingly complex projects that that can easily go out of control.

The solution? Again, simple. Document your project. (See my book “Writing Effective Online Content Project Specifications”, available on Amazon, for my suggestions on how to document your projects and what can happen if you don’t.)

·        Lack of motivation on authors’ parts – Single-sourcing isn’t on most authors’ radar so they have no reason to move from the tools and workflows they know to something new to support some vague goal of single-sourcing.

The result? Authors type their content and make sure it prints well and that’s that.

The solution? Several parts. First, make single-sourcing a job requirement. Second, and crucially, explain why single-sourcing is important to the company and show how it can solve authors’ problems. Without that, authors will do the bare minimum needed to meet the single-sourcing requirement and even skimp on that unless there’s management oversight.

Alternatives to Traditional Single-Sourcing?

What about the “shared pipes” (from Sarah O’Keefe) and “multi-source” (from Alan Porter) models that Baker describes? Each seems to fix some problems of single-sourcing. However, each one has to add a complex black box in the center of the process, where the conversion and coding is done. In my view, the more that this conversion and coding can be pushed back upstream to the individual authors by giving them templates, style sheets, and other tools and leaving the black box central processor to the tool vendor, the easier life will be. No need for a dedicated IT person managing and maintaining a proprietary system that, in my experience, languishes after its initial champions have moved on.

What about the “subject-domain” model that Baker describes? In my view, this model can be handled by creating information-type templates for authors to use. We generally think of templates as specific to types of information/topics, but there’s no reason why templates can’t be applied to specific domains of information as well.

Summary

Single-sourcing isn’t perfect. No authoring model is. But it’s worked well for years and its problems seem to have straightforward solutions. Try those before throwing the single-sourcing baby out with the bath water.