Single Source Publishing Part 6 : Concurrency

Adam Hyde Aug 26, 2021

Single Source Publishing Part 6 : Concurrency

Many thanks to Ken Brooks and Andrew Savikas for input into this article. Digest of this series available here.

In publishing there are two types of concurrency we care about:

  1. workflow concurrency – the ability to perform multiple tasks upon the work, by different people, at the same time
  2. realtime editing – the ability for multiple people to edit a document at the same time and see each other’s changes in realtime (like Google Docs, or Plasmic / Figma etc)

These two overlap but they are distinct. Here is a brief example to illustrate the difference. In a book production workflow, we may break the work (book) up into multiple documents – one for each chapter or even per paragraph (sometimes referred to as batching). Just by doing this we can have more than one person working on the book at the same time (each tackling a different chapter for example).

This is workflow concurrency.

Now, if we want two people to edit the same chapter at the same time this is realtime editing.

Of course we can blend these two models:

Now, realtime editing, as a type of concurrency, is a choice you have depending on the type of technology you choose for editing (there are also concurrent design apps like Plasmic and Figma). If you choose to use Microsoft Word for content creation, for example, you cannot achieve realtime editing. If you choose other tools (eg Google Docs, or ProseMirror and Firebase / ProseMirror and yjs) then you can achieve simultaneous realtime editing.

But it is good to remember that if the technology does offer realtime editing then there is nothing forcing you to use it. Whether you use it or not is dependent on how you want people to work. Previously in this series of articles about single source publishing workflows, I suggested we do not design publishing platforms starting from technical features (such as choosing the source file format first), but rather we take a workflow-first approach. It is the same with realtime editing – first work out your ideal workflow, and if indeed you actually want realtime editing, then add that to your list of system requirements. The technical consequences are a secondary problem.

As for workflow concurrency – we have the same set of questions. Do we want multiple people to perform different types of tasks on the work at the same time? Do we want, for example, the designer to be working on the layout as the copy editor does their work? Or an illustrator to be designing illustrations while an author is commenting on the illustration at the same time? These workflow concurrency questions must be answered when choosing or designing a publishing system, and once again it comes down to your answer to the crucial question – “what is my ideal workflow”. Other decisions follow from there.

Given all this, it is a good idea to first zoom out and question what value concurrency, of any kind, can offer a publishing workflow. We can then answer whether we actually want concurrency.

Concurrency vs Sequential Workflows

Publishing workflows these days are mostly sequential. A sequential workflow requires operations to be executed one after the other. Many publishers today, for example, are emailing (or uploading and downloading) bunches of documents for each other, usually in the MS Word format, to work on. An author emails files to a acquisition manager, who emails them to the production crew, who back and forth with authors and copy editors etc to get all the files processed (or “done_done_final_done_really-final-done_v2” as the case may be) and then the same files are sent to a designer/vendor etc

This is very sequential and we know its downside because that is how things work today. We know how much time and money these workflows cost (much more than necessary).

The question is whether concurrency is better? To answer this question we have to understand the essential characteristics of concurrency, and how they can help publishers.

There are two essential characteristics of concurrency:

  1. the opportunity to see the current state of the work at any moment
  2. the opportunity to act on the current work at any moment.

There is a lot to gain from these two simple features. From a very high level there are 4 general gains on offer that are derived from [1] and [2] above:

1. understanding state – an immediate understanding of the state of the work at any moment

2. reducing handling time – reducing the to and fro of passing documents back and forth

3. parallel processes – various team members can do what they need to do in parallel with each other

4. realtime problem solving – issues can be resolved in realtime.

These 4 opportunities provided by concurrency can have, even if moderately implemented, a huge impact as Ken Brooks has attested:

“By implementing collaborative editing, WYSIWYG rendering, and push-button distribution to all formats (courses, eBooks and print files) we discovered it can result in a 50% reduction in cost and a 50% reduction in cycle.”
Ken Brooks, president, Treadwell Media Group.

But concurrency also allows for completely new ways of working, as Barbara Rühling from Book Sprints points out:

“Book Sprints would not be able to produce books in 5 days if authors, illustrators, copy editors, designers etc were not all able to work concurrently. ”
— Barbara Rühling, CEO, Book Sprints

How much concurrency benefits your workflow depends on which parts of the cycle you decide to make concurrent, and just how far you are prepared to go. How far you take it is up to you.

Here are some examples of where concurrency could benefit a common publishing workflow:

  • Art logs and image research starting as soon as FPO (‘for placement only’) images are placed
  • Alt text being created as images are being added
  • Indexing could start as the text is completed (inserting tags) before the proof stage
  • Proofing being finished on one part of the book before the rest is finished
  • Concurrent page rendering enables author to correct or fit content as they write it
  • Testing the content with live customers as the rest of the content is being finished (O’Reilly does this, and it’s a way to do A/B testing for learning objects and assessment items in education. It’s a way to improve product-market fit).
  • Multiple authors working on the same text at the same time
  • Designers working on design of the actual content as a work is being created
  • Copy editors working on content immediately as it is completed by an author
  • Illustrators placing images in a work as it is being authored
  • Production editors understanding exactly what has and hasn’t been done at any time
  • Developmental editors and authors working on the same text at the same time

SSP and Concurrency

So, what about SSP and concurrency?

Remember these two features of concurrency listed above:

  1. the opportunity to see the current state of the work at any moment
  2. the opportunity to act on the current work at any moment.

These two features require the source to be shared between all those in the team. To have concurrency, on a system or document level, we need to share the source … sound familiar? Sharing the source is the same core design requirement of a single source publishing system. SSP offers more opportunity by design for concurrency than does a ‘multiple master’ publishing system.

SSP can offer publishing enormous gains through the introduction of concurrency into the workflow. Concurrency can help optimise how you work, or it can radically change how you work. How much you take advantage of SSP and concurrency is completely up to you. The advantage of SSP is that you have a choice, as Andrew Savikas points out:

“Concurrency is so powerful. It means it’s possible to (for example) have an author, copy editor, indexer, and designer all making changes in different parts of the manuscript at the same time. Of course, it does not always (or even often) make sense for each step of the workflow to be done concurrently, but an SSP model at least makes it possible. “
— Andrew Savikas,  Chief Strategy Officer at getAbstract

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.