Single Source Publishing Part 1 : The Problem

Adam Hyde Jul 21, 2021

Single Source Publishing Part 1 – The Problem

The first article in a short series by Adam Hyde about Single Source Publishing.

Publishing has long suffered from broken workflows that slow down the time to publish and unnecessarily inflate the cost to publish. Publishing of all kinds suffers from these inefficiencies. Some of the problems are general, others are very idiosyncratic and particular to perhaps just one publisher.

However, no matter what kind of publishing you do, there is a good chance you suffer from a disconnect between content creation processes and production processes.

In many publishing environments authors, copy editors, proofers etc create and improve content primarily in one tool (usually Microsoft Word). The content creation process feeds into the production process where production staff create a multitude of other formats – HTML, PDF (for print and screen), possibly XML and ebook formats etc.

To convert to these file formats, the content has to either be programmatically converted to various target formats via software (eg Pandoc or bespoke software), or manually converted by people using software (eg InDesign). Publishers achieve this by either slinging the content ‘over the wall’ to a publishing services vendor or contractor, or they employ internal staff. The folks doing these conversions belong to the general category of ‘production people’ – usually programmers, designers, or ‘format wranglers’.

Here is the problem. Workflows that look similar to the above, which is most publishing workflows, separate the content creation from the content production. This disconnect separates ‘the who’ (who does the work), ‘the how’ (what tools are used), and importantly ‘the what’ – what files are worked on. The people, the tools, and the working files all change as the content jumps from content creation to content production.

To understand why this is a problem, we just have to consider this one very simple scenario: what if there need to be changes to the content after it has entered the production stage?

Generally, if content needs to be changed while in the ‘production stage’ it requires several steps

  1. the content people, using their own tools, communicate the changes required
  2. the production people, using their own tools, make the changes for each output format
  3. the content staff check the changes.

All this also requires managing because there is a lot of necessary back and forth which in turn creates a lot of expensive overhead for making even the simplest of changes. Additionally, jumping the gap from creation to production introduces errors.

Take a simple book example – if an error is discovered by the author (which is common) after the content has gone to the designer, then the author must write the comments somewhere (email/MS Word/annotated PDF), and send them to the designer. The designer must then interpret the results, which can in itself cause errors as designers are seldom content domain experts, and apply the corrections in (for example) InDesign. The designer then sends a PDF to the author to check..and so on…

Or a simple Journal example – the production staff have discovered from proofs that figures are in the wrong place. This information must be communicated to (for example) the publishing services provider (via email, MS Word, annotated PDF etc). The vendor interprets the information, makes the changes in their (various) tools, and sends back to the publisher to check… and so on…

In each of the above examples, larger publishers also have staff to manage the communication of changes, track the changes, check the changes etc. It is quite an ordeal that costs time and money. If publishers don’t do this well, the consequence is that more errors are introduced.

This is the problem ‘single sourcing’ is meant to solve. Single sourcing is a general approach to publishing workflows that is intended to avoid disconnecting the content creation and production processes – saving time and money, and reducing errors.

What exactly is single sourcing and how does it avoid disconnecting content creation and production?

Single sourcing isn’t a specific solution, it is a general idea that must be intentionally designed into a publisher’s workflow. Single sourcing changes how people work and often requires a different tooling. The secret really, if we zoom out to a high-level abstraction of the problem, is to work out how the content creation and production folks can work in a shared ‘environment’ where they all work on the same files, the same source files – hence the term ‘single source’.

In a single source environment if a change needs to be made while the content is in production the content people can make the change themselves. Less time and communication required, less to-and-fro, less management overhead, and fewer errors.

There are many ways of achieving single sourcing. Any book publisher could solve this by, for example, asking their authors to write their books in InDesign, saving the files to a shared server somewhere. Authors, copy editors, and designers (etc) could all collaborate in the same tool, changing the same files, and all changes could smoothly flow into the final output at the push of a button. Success!

There is a good reason why you haven’t heard of anyone doing this despite the fact that this is a technically elegant single source solution. No author is going to head off into the woods and spend 6 months in a cabin to conjure up their masterpiece – in InDesign. Not ever. InDesign is a production tool, it is not designed for authors.

The above example may seem frivolous, but it gets down to the core of the problem. Single sourcing, to be effective, must be done with tools that not only share the same source for content creation and production but also respect the different tool-cultures of content creators and production people.

Amazingly, this last point is often not taken into consideration. Unfortunately, too often, the content creators are never asked about the kinds of tools they like to work with. Their tool-culture is ignored. This is actually a problem with how tooling is designed and built, and worthy of one or more articles in itself. I’ll discuss how to build tools all stakeholders want to use in future posts.

The focus on my next article – will be on one approach to solving single sourcing that keeps all stakeholders happy.

Part 2 now available here. Thanks to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.

About the Author

Adam Hyde

Coko Founder

Adam is the founder of Coko, Book Sprints, Pagedjs and many other open source publishing projects.