diff --git a/src/articles/entry2.md b/src/articles/SSP-JATS/entry2.md
similarity index 95%
rename from src/articles/entry2.md
rename to src/articles/SSP-JATS/entry2.md
index bb7d76656a7f4e415db5ecb34c27e062cc5e467b..1606cfe15f68f5dde88288549b7c391326e15320 100644
--- a/src/articles/entry2.md
+++ b/src/articles/SSP-JATS/entry2.md
@@ -1,13 +1,14 @@
---
-title: "Single Source Publishing and JATS"
+title: "Single Source Publishing and JATS"
+subtitle: ""
date: "2021-11-27"
intro: In general, Journals (and many of the family of workflows associated with publishing research) require 3 output types – HTML, PDF, and JATS. Along with finding reviewers, this requirement for…
author: Adam Hyde
tags: featured
-class:
+class: ""
icon: "/images/uploads/kotahi-jats-V2-500x500.jpg"
---
-
+<!-- link for checking: http://localhost:8080/articles/single-source-publishing-and-jats/ -->
In general, Journals (and many of the family of workflows associated with publishing research) require 3 output types – HTML, PDF, and JATS.
Along with finding reviewers, this requirement for document preparation (generally called typesetting) is one of the big publishing bottlenecks. The tooling and processes for typesetting can be complex so it is also difficult for Journal staff to do this themselves. The result is that many ‘throw it over the wall’ to an outsourced vendor. This incurs costs which may or may not be affordable for the Journal. The back and forth with vendors also prolongs the time to publish. In addition, conversion costs are added to the total cost of production and passed along, sooner or later, to subscribing institutions (such as universities), funders, or the researchers (in the case of Open Access via Article Processing Charges).
diff --git a/src/articles/SSP-Kotahi/entry1.md b/src/articles/SSP-Kotahi/entry1.md
new file mode 100644
index 0000000000000000000000000000000000000000..59b7f596828f0caae5a9f02e8d052933b44d293a
--- /dev/null
+++ b/src/articles/SSP-Kotahi/entry1.md
@@ -0,0 +1,289 @@
+---
+title: "White Paper: Kotahi Current State"
+subtitle: ""
+date: "2021-09-15"
+author: Adam Hyde
+# image: Coko.png
+---
+ The Kotahi workflow is very configurable and can support very linear, to very concurrent,
+ workflows. In addition, the submission types supported are configurable. These two features together mean that
+ Kotahi can support a wide variety of use cases and workflow models.</p>
+ <p class="paragraph">This document outlines Kotahi as it is configured for a typical Journal workflow. Please note
+ that this is just one configured pathway and many parts of what you will see in this document are configurable to
+ meet your needs.</p>
+ <p class="paragraph"><em>Please note—Kotahi is undergoing heavy continuous development. For an insight into
+ the current issues please see </em><a href="https://gitlab.coko.foundation/kotahi/kotahi/-/issues?state=opened"
+ rel target="blank"><em>here</em></a><em>. Some pre-recorded demos are provided, please click on the demo icon to
+ review. In addition, all images can be clicked on for a more detailed view. This White Paper is a light
+ overview, for in depth detail please contact Coko (email included below) for a full demo and discussion.</em>
+ </p>
+ <h2>Typical Journal Workflow</h2>
+ <p class="paragraph">For the purposes of this document we will look at the following configuration which is being
+ used by the Aperture Neuro journal (Organization of Human Brain Mapping).</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img01.png">
+ <figcaption class="decoration">Aperture Workflow in Kotahi</figcaption>
+ </figure>
+ <p class="paragraph">The Aperture workflow in sequential notation looks something like this:</p>
+ <ol>
+ <li>
+ <p class="paragraph">Author creates new submission (a link, attachment, or ingested docx)</p>
+ </li>
+ <li>
+ <p class="paragraph">Author completes submission data</p>
+ </li>
+ <li>
+ <p class="paragraph">Author submits</p>
+ </li>
+ <li>
+ <p class="paragraph">Managing Editor views manuscript</p>
+ </li>
+ <li>
+ <p class="paragraph">Managing Editor desk reject (can reject submission)</p>
+ </li>
+ <li>
+ <p class="paragraph">Managing Editor assigns to Senior Editor</p>
+ </li>
+ <li>
+ <p class="paragraph">Senior Editor checks manuscript</p>
+ </li>
+ <li>
+ <p class="paragraph">Senior Editor assigns to Handing Editor</p>
+ </li>
+ <li>
+ <p class="paragraph">Handling Editor assigns Reviewers</p>
+ </li>
+ <li>
+ <p class="paragraph">Reviewers accept / decline invitation</p>
+ </li>
+ <li>
+ <p class="paragraph">Reviewers review</p>
+ </li>
+ <li>
+ <p class="paragraph">Reviewers submit review</p>
+ </li>
+ <li>
+ <p class="paragraph">Handling Editor makes decision (accept/revise->goto 9)</p>
+ </li>
+ <li>
+ <p class="paragraph">Handling Editor publishes (production covered later in this document)</p>
+ </li>
+ </ol>
+ <p class="paragraph">We can break the above into 4 high level stages:</p>
+ <ol>
+ <li>
+ <p class="paragraph">Author submission (steps 1,2,3)</p>
+ </li>
+ <li>
+ <p class="paragraph">Editor Assignment (steps 4,5,6,7,8)</p>
+ </li>
+ <li>
+ <p class="paragraph">Reviewer Assignment and Review (steps 10,11,12)</p>
+ </li>
+ <li>
+ <p class="paragraph">Editor Decision (steps 13,14)</p>
+ </li>
+ </ol>
+ <p class="paragraph">The following sections will look at each stage and the associated user Interfaces.</p>
+ <h3>Author Submission</h3>
+ <h4>Login</h4>
+ <p class="paragraph">All users authenticate before they can use Kotahi. Aperture supports the ORCID OAuth protocol
+ and process. However this can be replaced by any shared login system or with a sign-up and sign-in process. Upon
+ login all users are directed to their Dashboard where they can view all the manuscripts they are working on (as
+ authors, reviewers, or editors).</p>
+ <h4>Submission Types</h4>
+ <p class="paragraph">Kotahi supports any type of filetype as a submission attachment as well as link submissions
+ (for submitting code stored in repositories or Jupyter notebook instances etc).</p>
+ <p class="paragraph">In addition, if a submission is in MS Word docx format then Kotahi will ingest and convert the
+ file into an internal stored and editable data format for editing in Kotahi’s internal <a
+ href="https://waxjs.net/" rel target="blank">Scholarly Word Processor</a>. In this later mode, Kotahi becomes a
+ complete Single Source Publishing system (more on this later).</p>
+ <h4>Submission Form</h4>
+ <p class="paragraph">Submission data can be captured by user entry with the Submission Form. The creation and
+ ongoing maintenance of the Submission Form is done by the Journal Admin with the internal Form Creation user
+ interface (see later in this document).</p>
+ <p class="paragraph">Please see below for the Aperture form captured in its entirety (click to see the entire form).
+ </p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img02.png">
+ <figcaption class="decoration">Example Submission Form</figcaption>
+ </figure>
+ <h4>Submission</h4>
+ <p class="paragraph">Upon completion of the submission form, the manuscript and its associated declarations and data
+ can be submitted. The author will be asked to agree to any terms and conditions (configurable) before the material
+ can be submitted. Upon submission, the state for the manuscript changes from ‘unsubmitted’ to
+ ‘submitted’—this information (current state) is displayed on the Dashboard as well as in many
+ other places throughout Kotahi.</p>
+ <h3>Editor Assignment</h3>
+ <p class="paragraph">Editors break down to the following generic roles:</p>
+ <ul>
+ <li>
+ <p class="paragraph">Managing Editor</p>
+ </li>
+ <li>
+ <p class="paragraph">Senior Editor</p>
+ </li>
+ <li>
+ <p class="paragraph">Handling Editor</p>
+ </li>
+ <li>
+ <p class="paragraph">Editor (misc)</p>
+ </li>
+ </ul>
+ <p class="paragraph">Editors can view manuscripts they are associated with via the Dashboard as well as seeing all
+ manuscripts on the Manuscripts Page (permissions permitting).</p>
+ <h4>Manuscripts Page</h4>
+ <p class="paragraph">The Managing Editor can view new submissions via the Manuscripts Page (click to enlarge).</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img03.png">
+ <figcaption class="decoration">Kotahi Manuscripts Page (with example data)</figcaption>
+ </figure>
+ <p class="paragraph">Columns can be sorted by Creation Dates, State etc.</p>
+ <p class="paragraph">Managing Editors (ME) can choose a new (or any) manuscript to view by clicking on
+ ‘View’. Alternatively, the ME can click on ‘Control Panel’ to view the manuscript,
+ submission data, and the submission’s associated workflow controls.</p>
+ <h4>Control Panel</h4>
+ <p class="paragraph">The Control Panel displays the Manuscript, Submission Data and workflow controls for the
+ selected manuscript as per below (click to enlarge).</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img04.png">
+ <figcaption class="decoration">Kotahi Control Panel</figcaption>
+ </figure>
+ <p class="paragraph">Please note, the above screenshot is soon to be replaced with three separate tabs for 1)
+ workflow controls 2) manuscript 3) submission data (as per <a
+ href="https://gitlab.coko.foundation/kotahi/kotahi/-/issues/621" rel target="blank">this issue</a>).</p>
+ <p class="paragraph">From the Control Panel, the ME can reject the manuscript or assign a Senior Editor. Upon
+ assigning a Senior Editor, the manuscript will appear on the Dashboard for that editor. The Senior Editor can then
+ access the Control Panel for that manuscript, view the manuscript and data, and assign a Handling Editor.</p>
+ <h3>Reviewer Assignment and Review</h3>
+ <p class="paragraph">The Handling Editor (HE) can access the Control Panel for the manuscript from their Dashboard.
+ They can then review the manuscript and submission data. The next step is for the HE to invite reviewers. The
+ Invite Reviewers page is accessible via the Control Panel.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img05.png">
+ <figcaption class="decoration">Kotahi Reviewer Management</figcaption>
+ </figure>
+ <p class="paragraph">At this stage of invitation, the editor can also decide if the reviewer is doing their own
+ review or a shared review.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img06.png">
+ <figcaption class="decoration">Reviewer Management showing shared review option</figcaption>
+ </figure>
+ <p class="paragraph"><em>Screenshot taken from CB (t.b.a) Instance</em></p>
+ <p class="paragraph">Reviewers receive an email with the invitation to review the manuscript. Contained in the email
+ is additional information about the manuscript (this is set via the Form Builder, see below).</p>
+ <p class="paragraph">The reviewer can then accept or reject the invitation via their Dashboard (soon also via the
+ email). The Reviewer can then access the manuscript, filtered submission data, and the review form via the
+ Dashboard. The Review Page has a section for writing the review and attaching files:</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img07.png">
+ <figcaption class="decoration">Kotahi Reviewer Form</figcaption>
+ </figure>
+ <h3>Editor Decision</h3>
+ <p class="paragraph">When reviews are complete, the HE can access the reviews via the Control Panel for the
+ manuscript and decide on whether to accept, reject, or request a revision. Secondary revision types are managed
+ through email templates (see below).</p>
+ <p class="paragraph">The HE can write their response to the author in the panel provided. The text is shown to the
+ author on the submission form (connected to versions, see below).</p>
+ <p class="paragraph">The author can then revise both the submission data and the manuscript and resubmit. The
+ process continues until the article is ready to publish. Editors can assign the same reviewers, or new reviewers
+ per round.</p>
+ <h2>Communication</h2>
+ <p class="paragraph">Kotahi leverages many realtime tools for communication as well as utlizing its own email
+ template system. Realtime communication is supported by ‘presence indicators’ to indicate if a user
+ is logged in at that time. Also supported is live video communication for the editorial staff (linked from the
+ Manuscripts Page). Live chat is also available per submission for communication between authors and editorial
+ staff, as well as private chats for the editorial staff to discuss the submission.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img08.png">
+ <figcaption class="decoration">Kotahi Chat (Author view)</figcaption>
+ </figure>
+ <p class="paragraph"><em>Author—Editor chat embedded in the author submission pane (click to enlarge).</em>
+ </p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img09.png">
+ <figcaption class="decoration">Kotahi Chat (Editorial view)</figcaption>
+ </figure>
+ <p class="paragraph"><em>Editorial chat for staff only (per manuscript).</em></p>
+ <p class="paragraph">Emails can be sent for each manuscript via the email template controls. The Publisher can
+ configure as many templates as they like. Emails can be sent to existing users or people with no account. A record
+ of all emails sent is kept as a retrievable log within the editorial staff chat.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img10.png">
+ <figcaption class="decoration">Email Management</figcaption>
+ </figure>
+ <p class="paragraph"><em>Screenshot taken from the CB instance of Kotahi.</em></p>
+ <h2>Versions</h2>
+ <p class="paragraph">Submissions are managed per revision round. Each round creates a new version of both the
+ submission data and the manuscript attachments/internal content store. Revision history can be browsed by authors
+ and editorial staff alike. Earlier versions cannot (of course) be edited.</p>
+ <h2>Single Source Publishing</h2>
+ <p class="paragraph">If docx files are submitted, Kotahi can be a complete end-to-end <a
+ href="https://coko.foundation/single-source-publishing/" rel target="blank">Single Source Publishing</a> System.
+ Docx content is ingested and converted to Kotahi’s internal data format. The content is then editable via
+ the Wax web-based word processor built into Kotahi.</p>
+ <h2>JATS</h2>
+ <p class="paragraph">The JATS production interface is currently being built. The JATS production interface will also
+ support automated PDF output via <a href="https://pagedjs.org/" rel target="blank">pagedjs</a>, and SEO optimised
+ HTML for pushing to publish interfaces.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img11.png">
+ <figcaption class="decoration">JATS Export</figcaption>
+ </figure>
+ <h2>Publishing</h2>
+ <p class="paragraph">Aperture is going live with the FLAX publish front end. Flax is a new product from Coko which
+ is connects directly to Kotahi for realtime publishing of articles while being a completely extensible CMS for
+ building entire Journal sites. Kotahi has an extensible ingestion API and publishing API. These APIs allow for a
+ vast variety of (for example) publishing integrations. NCRC, for example publish to a Google spreadsheet (since
+ they are processing existing preprint URLs) as well as registering reviews with DOIs on Crossref. If the target
+ system for publishing offers an integration endpoint of any kind, then Kotahi can integrate with it.</p>
+ <h2>The Form Builder</h2>
+ <p class="paragraph">The Form Builder sounds humble but it is an immensely powerful tool. The Form Builder enables
+ the admin/ME to build the submission forms using a web interface. However, the interface also allows for the
+ tagging of each field with unique IDs (useful for building JATS/XML at export time), identifying which fields will
+ be shown to reviewers when inviting them to review, controlling taxonomy, identifying which columns are displayed
+ on the Manuscripts Page, and it can even be used to extend the Control Panel UI. The Form Builder will
+ increasingly become an central part of the Kotahi platform. Form Builders are much underestimated.</p>
+ <h2>Reports</h2>
+ <p class="paragraph">Reports are integrated into Kotahi and are pretty comprehensive. We have opted for dynamic
+ rendering to improve the user enjoyment of the Kotahi UI.</p>
+ <h2> Workflow Configuration</h2>
+ <p class="paragraph">There are immense workflow configuration options. So far, almost all are via config files but
+ we have a UI config manager design. While we will use the above workflow, the following are two workflow examples
+ for the Novel Coronavirus Research Consortium and CBinstances:</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img12.png">
+ <figcaption class="decoration"><em>NCRC Kotahi Workflow</em></figcaption>
+ </figure>
+ <p class="paragraph"></p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP-Kotahi/img13.png">
+ <figcaption class="decoration">CB Kotahi Workflow</figcaption>
+ </figure>
+ <p class="paragraph"></p>
+ <h2>Summary</h2>
+ <p class="paragraph">Kotahi is a modern scholarly publishing platform. It is built with modern technologies with
+ modern, efficient workflows in mind. The platform is also very modular, extensible, and configurable. There is
+ almost no element of the system that is immutable—all elements can be changed if required. In addition
+ Kotahi leverages modern realtime communication protocols and together with the Single Source Publishing design the
+ entire system offers publishers enormous futureproofing and workflow optimization opportunities.</p>
+ <p class="paragraph">Lastly, <em>all</em> aspects of Kotahi are open source and liberally licensed (MIT). Coko
+ exists to support organizations wanting to hire us to extend Kotahi or go it alone. In all development scenarios,
+ Coko facilitates the multiple organizations extending Kotahi to ensure the community is building upon each
+ other’s work—this helps ensure lowering the burden of development cost and time as well as
+ eliminating possible duplication of efforts.</p>
+ <p class="paragraph">For more information contact Adam Hyde—<a href="http://adam@coko.foundation" rel
+ target="blank">adam@coko.foundation</a></p>
diff --git a/src/articles/SingleSourcePublishing/entry1.md b/src/articles/SingleSourcePublishing/entry1.md
new file mode 100644
index 0000000000000000000000000000000000000000..19ff94ff42c6bcfc8213c803129f76c130ad47fe
--- /dev/null
+++ b/src/articles/SingleSourcePublishing/entry1.md
@@ -0,0 +1,97 @@
+---
+title: "Single Source Publishing"
+subtitle: "Part 1: The Problem"
+author: Adam Hyde
+---
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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’.</p>
+ <p class="paragraph">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.</p>
+ <figure><img
+ src="/images/A1-Img1-and-A4-img4.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">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?</p>
+ <p class="paragraph">Generally, if content needs to be changed while in the ‘production stage’ it
+ requires several steps</p>
+ <ol>
+ <li>
+ <p class="paragraph">the content people, using their own tools, communicate the changes required</p>
+ </li>
+ <li>
+ <p class="paragraph">the production people, using their own tools, make the changes for each output format</p>
+ </li>
+ <li>
+ <p class="paragraph">the content staff check the changes.</p>
+ </li>
+ </ol>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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…</p>
+ <p class="paragraph">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…</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">What exactly is single sourcing and how does it avoid disconnecting content creation and
+ production?</p>
+ <p class="paragraph">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’.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="/images/A1-Img2.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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!</p>
+ <p class="paragraph">There is a good reason why you haven’t heard of anyone doing this despite the fact that
+ this is a <em>technically</em> 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.</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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 later parts.</p>
+ <p class="paragraph">(c) Adam Hyde, 2021. This work is licensed under a <a
+ href="http://creativecommons.org/licenses/by/4.0/" rel target="blank">Creative Commons Attribution 4.0
+ International License</a>.</p>
+ <p class="paragraph"><em>Thanks to Wendell Piez, Ken Brooks, Andrew Savikas and John Maxwell for feedback. Thanks
+ also to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.</em></p>
diff --git a/src/articles/SingleSourcePublishing/entry2.md b/src/articles/SingleSourcePublishing/entry2.md
new file mode 100644
index 0000000000000000000000000000000000000000..1210c747fb963adf263e1fef9755829a29289581
--- /dev/null
+++ b/src/articles/SingleSourcePublishing/entry2.md
@@ -0,0 +1,94 @@
+---
+title: "Single Source Publishing"
+subtitle: "Part 2: A Solution"
+author: Adam Hyde
+---
+ <p class="paragraph">Let’s look at a simple tool used for single source publishing on the web –
+ WordPress – which will help us understand some of the more complex problems Publishers face.</p>
+ <p class="paragraph">WordPress is a single source publishing system. To produce a post, the author does the
+ following:</p>
+ <ol>
+ <li>
+ <p class="paragraph">writes the post within WordPress, using the basic web editor supplied</p>
+ </li>
+ <li>
+ <p class="paragraph">presses ‘Update’ and the content is pushed through to the web</p>
+ </li>
+ </ol>
+ <p class="paragraph">That is it. The important thing to understand here is that content is authored in one place,
+ and at publish time, that content is transformed into the target output – in this case a blog post shared
+ on the web.</p>
+ <figure><img
+ src="images/uploads/SSP/A2-Img1.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Let’s add a little complexity as it is hard to really understand the value of single
+ source publishing from such a simple example. We will add more people and more outputs.</p>
+ <h2>Single Source and Multiple Actors</h2>
+ <p class="paragraph">Before publishing, other actors – copy editors, illustrators etc – might also
+ work on the content. These folks will also work within WordPress to edit the same post. All these people can
+ collaborate on the same source for the post. When it is time to publish, the process is still as simple as
+ pressing publish. There are no other versions of the content that need to be merged, checked, managed etc. Single
+ source has, even in this basic example, saved us a lot of hassle.</p>
+ <p class="paragraph">Furthermore, all the stakeholders here are using familiar tools. The WordPress editor is a
+ pretty easy editor to use if you are creating content for the web.</p>
+ <h2>Single Source and Multiple Outputs</h2>
+ <p class="paragraph">Now let’s look at adding multiple outputs. What if we wish to display the same WordPress
+ blog post to look good on both mobile and desktop devices. In this case, CSS (the set of rules used by designers
+ that describe how webpages should look) has the ability to identify whether the content is being displayed on a
+ small or large screen. CSS changes how the content is displayed accordingly.</p>
+ <p class="paragraph">As if by magic, we have effectively solved the problem of displaying the same content for two
+ different types of outputs – desktop and mobile displays.</p>
+ <figure><img
+ src="images/uploads/SSP/A2-Img2.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <h2>So what’s the problem?</h2>
+ <p class="paragraph">If you were building WordPress for the first time, and you needed to cater for the above
+ outputs (HTML + CSS for 2 display sizes), what file format would you choose to store your source?</p>
+ <p class="paragraph">No prizes for choosing HTML. To transform from HTML to HTML & HTML is cheap because there
+ is (in simple terms) no transformation needed. This is exactly what the smart folks at WordPress have done.</p>
+ <figure><img
+ src="images/uploads/SSP/A2-Img3.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">The content you are editing in WP is stored as HTML. Exactly that same source is directly
+ transferred to the web at publish time.</p>
+ <p class="paragraph">The trouble starts when you require significantly different types of outputs. What if, for
+ example, you required not just HTML but also EPUB, Screen PDF, PDF for Print, XML etc. In cases where you require
+ multiple output types, which is most publishing scenarios, you must choose a source file format that can undergo
+ significant transformation into all of the output formats you require.</p>
+ <figure><img
+ src="images/uploads/SSP/A2-Img4.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">When designing a publishing system you face two basic questions, in this order:</p>
+ <ol>
+ <li>
+ <p class="paragraph">what output formats do I need?</p>
+ </li>
+ <li>
+ <p class="paragraph">what source file would best lend itself to transformation into the outputs?</p>
+ </li>
+ </ol>
+ <p class="paragraph">After these two questions there are a lot of secondary questions (requirements) that will come
+ to bear on the problem, but let’s keep it simple for now.</p>
+ <p class="paragraph">Unfortunately, the process for designing systems too often takes the following format, in this
+ order:</p>
+ <ol>
+ <li>
+ <p class="paragraph">what source file format is currently in fashion? (hint: it has been XML for the last 20+
+ years)</p>
+ </li>
+ <li>
+ <p class="paragraph">how do I build a system around that format?</p>
+ </li>
+ </ol>
+ <p class="paragraph">Unfortunately, this latter thought process has driven the publishing industry into building
+ expensive and inefficient systems and largely prevented the industry from moving towards more elegant workflows.
+ </p>
+ <p class="paragraph">(c) Adam Hyde, 2021. This work is licensed under a <a
+ href="http://creativecommons.org/licenses/by/4.0/" rel target="blank">Creative Commons Attribution 4.0
+ International License</a>.</p>
+ <p class="paragraph"><em>Thanks to Wendell Piez, Ken Brooks, Andrew Savikas and John Maxwell for feedback. Thanks
+ also to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.</em></p>
diff --git a/src/articles/SingleSourcePublishing/entry3.md b/src/articles/SingleSourcePublishing/entry3.md
new file mode 100644
index 0000000000000000000000000000000000000000..85f078bc5d3c411e101e1e9efc2122eb31f875f1
--- /dev/null
+++ b/src/articles/SingleSourcePublishing/entry3.md
@@ -0,0 +1,92 @@
+---
+title: "Single Source Publishing"
+subtitle: "Part 3: Is Automation the Answer?"
+author: Adam Hyde
+---
+ <p class="paragraph">Obviously it would be awesome if we could push a button in our imaginary publishing system and
+ all the outputs would roll out automagically – fully formed, perfect and beautiful.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A3-Img1.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Is such automation possible? Let’s have a closer look at the types of conversion
+ involved.</p>
+ <h2>Structure</h2>
+ <p class="paragraph">There are two types (roughly) of structural conversion – upconversion, and
+ downconversion.</p>
+ <h3><strong>Downconversion</strong></h3>
+ <p class="paragraph">To create a simpler structure (eg plain text) from any source format, the transformation mostly
+ means removing information (structure).</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A3-Img2.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Removing structure is easy (usually), we just throw stuff away.</p>
+ <h3><strong>Upconversion</strong></h3>
+ <p class="paragraph">To get from our source file to a more complex structure, we need to add information
+ (structure).</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A3-Img3.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Adding structure is doable but not as easy.</p>
+ <p class="paragraph">A simple diagram to help us understand up and down conversion would be as follows:</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A3-Img4.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Down-conversion is generally an easier target for automation. Up-conversion is more likely to
+ require human intervention.</p>
+ <h2>Typesetting</h2>
+ <p class="paragraph">Another category of conversion is typesetting. Typesetting means we require a change in the
+ look and feel of the output (design).</p>
+ <p class="paragraph">There are two approaches to typesetting – ‘automatic typesetting’ (which
+ is done by a machine) and manual typesetting (done by a human).</p>
+ <h3><strong>Automatic Typesetting</strong></h3>
+ <p class="paragraph">Automatic typesetting is when a designer sets up a bunch of rules (templates) and then
+ ‘a machine’ applies those rules to the content.</p>
+ <p class="paragraph">Automatic typesetting is possible to achieve in some Publishing contexts but the more complex
+ your design requirements, the harder it is to achieve.</p>
+ <h3><strong>Manual Typesetting</strong></h3>
+ <p class="paragraph">When a designer uses a design tool such as InDesign to produce the required design, this is
+ manual typesetting.</p>
+ <p class="paragraph">Again, the more sophisticated the design, the more likely it is to require human intervention
+ to produce the desired result.</p>
+ <h2>Where does that leave us?</h2>
+ <p class="paragraph">If we can achieve all of our conversions – structural conversions and typesetting
+ – automatically, then we are in a winning situation. We can start with a source file and then press a
+ button and all of our outputs will be generated automagically. This is single source publishing achieved through
+ automation.</p>
+ <p class="paragraph">Automatic conversion is most likely to be achievable where we have either:</p>
+ <ol>
+ <li>
+ <p class="paragraph">very simple conversions</p>
+ </li>
+ <li>
+ <p class="paragraph">moderate expectations from our conversions.</p>
+ </li>
+ </ol>
+ <p class="paragraph">While often true in ‘web publishing’, these two conditions are seldom true for
+ publishers. Publishers, generally speaking, have high expectations for all their conversions and their outputs are
+ often complex.</p>
+ <p class="paragraph">What does this mean? In most publishing contexts, this level of automation is not achievable
+ – we will require manual processing, and manual processing inevitably leads to the broken workflows we were
+ trying to avoid. If, for example, we want to introduce a manual design tool such as InDesign, then we are changing
+ the people, tools, and source as discussed in <a
+ href="https://coko.foundation/single-source-publishing-part-1-the-problem/" rel target="blank">Part
+ 1</a> – and we are deciding against a single source workflow.</p>
+ <p class="paragraph">If we are to achieve single source publishing, but we can’t do it by automation alone,
+ then we need another strategy.</p>
+ <p class="paragraph">To achieve all the efficiencies of the single source workflow that we have discussed before, we
+ need to work out how humans (content producers, designers, production people) and machines can utilize different
+ tools, respecting their tool-cultures, while working on the same source to create all the desired outputs. How is
+ this possible?</p>
+ <p class="paragraph">(c) Adam Hyde, 2021. This work is licensed under a <a
+ href="http://creativecommons.org/licenses/by/4.0/" rel target="blank">Creative Commons Attribution 4.0
+ International License</a>.</p>
+ <p class="paragraph"><em>Thanks to Wendell Piez, Ken Brooks, Andrew Savikas and John Maxwell for feedback. Thanks
+ also to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.</em></p>
diff --git a/src/articles/SingleSourcePublishing/entry4.md b/src/articles/SingleSourcePublishing/entry4.md
new file mode 100644
index 0000000000000000000000000000000000000000..9617437ae039e979c6a52214a42584d9e847aa38
--- /dev/null
+++ b/src/articles/SingleSourcePublishing/entry4.md
@@ -0,0 +1,83 @@
+---
+title: "Single Source Publishing"
+subtitle: "Part 4: For the Good of The System"
+author: Adam Hyde
+---
+ <blockquote>
+ <p class="source-note">“[XML].. is seen as something that must be endured by content authors for the
+ greater good of the enterprise.”<br><a
+ href="https://web.archive.org/web/20060826041249/http://www.elkera.com/cms/articles/seminars_and_presentations/planning_a_single_source_publishing_application_for_business_documents/"
+ rel target="blank">Peter Meyer, 2005</a></p>
+ </blockquote>
+ <p class="paragraph">It seems (from Chapter 3) that our dream of perfect automated output is dead, so how do we
+ ensure all the folks involved in preparing content to publish – authors, editors, copy editors, designers,
+ format wranglers etc – can work on the same source?</p>
+ <p class="paragraph">Let’s look, at a somewhat simplified level, at the operations each of the main
+ categories of stakeholders have to perform.</p>
+ <p class="paragraph">Content – ability to change the content</p>
+ <p class="paragraph">Design – ability to change the look and feel of outputs</p>
+ <p class="paragraph">Format – ability to change the structure of outputs</p>
+ <p class="paragraph">The challenge for systems designers is to consider tooling that can help each group of
+ stakeholders work efficiently while they share the same canonical source.</p>
+ <p class="paragraph"> </p>
+ <figure><img
+ src="images/uploads/SSP/A4-Img1.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph"> </p>
+ <p class="paragraph">To solve this problem, the publishing sector’s ‘system thinking’ has
+ largely been, to date, driven by what experts believe is the best file format. This ‘file-format-first
+ thinking’ has looked like this:</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A4-Img2.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">This thinking has lead us to where we are today, and today we have broken, disjointed
+ workflows.</p>
+ <p class="paragraph">To bring about the efficiencies we are after, we need to think in this direction:</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A4-Img3.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">What if the file format was the last decision you made when constructing ecosystems of
+ publishing tools, rather than the first thing you decided?</p>
+ <p class="paragraph">Are we more interested in making decisions based on how we can help people work more
+ efficiently, or making decisions based on source file formats? When designing systems the publishing sector has,
+ for the past 25 years, appeared to have answered “source file formats” to this question. This is
+ largely why the sector has been driven away from single source publishing systems and is mired in the kind of
+ broken, slow, expensive processes we discussed in earlier and we illustrated as follows:</p>
+ <figure><img
+ src="images/uploads/SSP/A1-Img1-and-A4-img4.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">When we started our discussion of single source publishing systems in this article, we talked a
+ lot about source file formats. However, it appears that deciding on the actual source file format to be used is
+ (literally) the last question we must ask. The questions we need to ask are as follows, in this order:</p>
+ <ol>
+ <li>
+ <p class="paragraph">what tools can people efficiently use?</p>
+ </li>
+ <li>
+ <p class="paragraph">what group of these tools share the same file format?</p>
+ </li>
+ <li>
+ <p class="paragraph">what is the file format?</p>
+ </li>
+ </ol>
+ <p class="paragraph">We need to start looking at <em>ecosystems of tools</em> that people can use
+ efficiently to work together on the same source, and then adopt that source format, whatever it may be…..
+ this might be a lengthy exercise as there are a lot of tools and formats out there, so I’ll make it easy on
+ you.</p>
+ <p class="paragraph">In the next series of articles I’ll cover an ecosystem of tools that is extensive, an
+ ecosystem that has had more development than any other over the last 25+ years, an ecosystem that can deliver
+ everything publishing needs now and in the future — an ecosystem which shares the same file
+ format….stay tuned…</p>
+ <p class="paragraph"> </p>
+ <p class="paragraph"><br></p>
+ <p class="paragraph">(c) Adam Hyde, 2021. This work is licensed under a <a
+ href="http://creativecommons.org/licenses/by/4.0/" rel target="blank">Creative Commons Attribution 4.0
+ International License</a>.</p>
+ <p class="paragraph"><em>Thanks to Wendell Piez, Ken Brooks, Andrew Savikas and John Maxwell for feedback. Thanks
+ also to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.</em></p>
diff --git a/src/articles/SingleSourcePublishing/entry5.md b/src/articles/SingleSourcePublishing/entry5.md
new file mode 100644
index 0000000000000000000000000000000000000000..fd2055cf16a846889acc0cd51938cf663f85e4e5
--- /dev/null
+++ b/src/articles/SingleSourcePublishing/entry5.md
@@ -0,0 +1,136 @@
+---
+title: "Single Source Publishing"
+subtitle: "Part 5: Workflow-First Systems"
+author: Adam Hyde
+---
+ <p class="paragraph">In Part 4 of this series about single source publishing systems, we concluded that it is a very
+ good idea to build systems around ecologies of tools that share the same source file format, rather than deciding
+ on the source file format before workflow needs are considered. Rather than a ‘file-format-first’
+ approach, we should move towards a ‘workflow-first’ approach.</p>
+ <p class="paragraph">So we need to first consider, at a somewhat simplified level, the operations each of the main
+ categories of stakeholders in a single source publishing system have to perform:</p>
+ <p class="paragraph"><strong>Content</strong> – ability to change the content</p>
+ <p class="paragraph"><strong>Design</strong> – ability to change the look and feel of outputs</p>
+ <p class="paragraph"><strong>Format</strong> – ability to change the structure of outputs.</p>
+ <p class="paragraph">Setting aside the search for tools for a minute, it might be reasonable to ask – is this
+ approach even possible? Don’t each of these operations require something quite different from a file
+ format? So don’t we require different formats to service each phase? It seems, in the history of publishing
+ so far, systems designers have appeared to believe this to be true. This is why many publishing systems upconvert
+ to the ‘highest resolution’ format possible (generally some form of xml) as early as possible, and
+ then downconvert to specific formats for consumption by tools such as InDesign.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/uploads/SSP/A5-Img1.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">But it is possible for a single format to contain enough information to feed into each of these
+ operations. Let’s look again at each category of operations:</p>
+ <h2>Content</h2>
+ <p class="paragraph">First, the content folks must be able to edit a relatively easy-to-understand document.
+ Authors, etc, in most cases prefer a document which contains only what is known as ‘display
+ semantics’ as they don’t generally work with tools that enforce structure, rather they write from
+ top to bottom with a structure that is meaningful to them via the headings, indents etc displayed in the actual
+ document.</p>
+ <p class="paragraph">Authors of this kind, which is most authors, ‘just like to write’. They
+ don’t care too much for having to maintain anything beyond the text, other than how the document looks to
+ the eye.</p>
+ <p class="paragraph">So any format we choose must be able to support a suite of tools that these kinds of authors
+ can use. Generally speaking these tools are known as ‘word processors’.</p>
+ <h2>Design</h2>
+ <p class="paragraph">Designers must be able to take the same content and apply design to the content within the
+ constraints of the output format. For example, designers must make the document look good in paginated PDF for
+ printing (eg books), or EPUB, or the web etc.</p>
+ <p class="paragraph">Any suite of tools we choose must enable designers to change placement, color etc of all the
+ elements in the content as well as controlling the same for format-specific features (eg running headers, page
+ numbers etc) for each output type while using the same source file. Generally, to date, the typical tools for
+ designers have been what is sometimes referred to as ‘pixel pushing’ tools – tools where you
+ can point and click to target elements and change their look and feel. However, in recent years (well, for a while
+ now) there have been ‘rules based’ design tools. One such rule-based approach is CSS – the
+ set of rules web designers use to determine the display format of webpages.</p>
+ <h2>Format</h2>
+ <p class="paragraph">Format wranglers want to be able to output file formats required for archiving, transmission,
+ and storage. JATS (Journal Article Tagging Suite) is one such format, it is a variant of XML. Books have BITS
+ (Book Interchange Tag Suite) which is also a XML variant.</p>
+ <p class="paragraph">Format wranglers need the source file to contain enough information so the content can be
+ translated (restructured) to the new form. Format wranglers are a kind of technician—someone that is expert
+ in encapsulating data in logical structures. The tools for these folks have generally been specialist
+ pseudo-scripting tools such as XSL (Extensible Stylesheet Language) which is part of the family of XML tools.
+ However, there are other approaches – JSON, for example, is often used as a way to represent data,
+ especially for transferring or storing data for web applications. With JSON, transformation is managed by rules
+ encased in custom JavaScript code. But in essence, good format wranglers like to write rules that can transform
+ many files, they don’t like manually transforming each file.</p>
+ <p class="paragraph">For a format to meet the needs of each of these use cases, there are two factors that must come
+ into play:</p>
+ <ol>
+ <li>
+ <p class="paragraph">any alterations to the content by content, design, or format people, MUST affect only one
+ source – the single source</p>
+ </li>
+ <li>
+ <p class="paragraph">the source file format must contain enough information to service each of the tools used by
+ these folks</p>
+ </li>
+ </ol>
+ <p class="paragraph">That seems to make sense… but there is one additional issue that is very important and
+ which may not be so obvious. Any of the tools used can of course augment the source file with information for the
+ job at hand while not requiring that information to actually be part of the source file.</p>
+ <p class="paragraph">A good example is with transformation. The transformation folks can write a set of rules that
+ can map the source file onto another structure (such as JATS). To do this they need two things:</p>
+ <ol>
+ <li>
+ <p class="paragraph">enough information in the source file to enable the transformation. For example, to map
+ A->B the source file must first tell us what A is .</p>
+ </li>
+ <li>
+ <p class="paragraph">a set of rules that manage the execution of the transformation</p>
+ </li>
+ </ol>
+ <p class="paragraph">The interesting thing is that the rules ([2] above) for the transformation do not have to be
+ contained within our source file. These rules can exist entirely independently of the source file.</p>
+ <p class="paragraph">In this way the format wranglers can do a lot of things no one else cares about, without
+ overloading the source file with all kinds of requirements. This helps us keep the amount of information the
+ actual source file needs to contain to a minimum.</p>
+ <p class="paragraph">This is, if you had not realized this already, exactly the opposite to the way publishing
+ systems designers have approached this process to date.</p>
+ <p class="paragraph">So, let’s say this makes sense so far. But what of content creation and design?</p>
+ <p class="paragraph">For editing/content creation we need a format that doesn’t break if it is ‘badly
+ structured’. You may not know it, but if there is one thing authors are very good at, it is badly
+ structuring documents. So, we need a format that doesn’t care if the author structures things oddly. We can
+ clean that aspect up later.</p>
+ <p class="paragraph">This brings about an interesting quality of the file format. It must be capable of
+ being <em>progressively structured</em>. That is, we can start with a ‘badly structured’
+ document and the source file format won’t break. We can then improve the structure over time and the file
+ format will also be happy to do this.</p>
+ <p class="paragraph">This is also, not the way it has been managed to date in publishing systems.</p>
+ <p class="paragraph">Now to design. Design requirements are very similar to the requirements for format wrangling.
+ We need the source file format to hold just enough information so that we can design elements with our design
+ tools, but any further logic can be contained within separate rules and not contained within the source file. Once
+ again, that allows us to keep the requirements of the source file to a minimum.</p>
+ <h2>Ecosystem Features</h2>
+ <p class="paragraph">So, we have two sets of qualities when choosing our ecosystem — one set of features for
+ the source file format, and one for the types of tools we choose. For the file format we need this:</p>
+ <ol>
+ <li>
+ <p class="paragraph">contains just enough information for each of the operations (create, transform, design)</p>
+ </li>
+ <li>
+ <p class="paragraph">can be progressively structured.</p>
+ </li>
+ </ol>
+ <p class="paragraph">For the tools we need this feature:</p>
+ <ol>
+ <li>
+ <p class="paragraph">the design and transformation are managed by logic external to the source file format.</p>
+ </li>
+ </ol>
+ <figure><img
+ src="images/uploads/SSP/A5-Img2.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Where does that leave us? As it happens, it leaves us with the ecology of tools that surround
+ one of the most popular formats of our age – HTML.</p>
+ <p class="paragraph">(c) Adam Hyde, 2021. This work is licensed under a <a
+ href="http://creativecommons.org/licenses/by/4.0/" rel target="blank">Creative Commons Attribution 4.0
+ International License</a>.</p>
+ <p class="paragraph"><em>Thanks to Wendell Piez, Ken Brooks, Andrew Savikas and John Maxwell for feedback. Thanks
+ also to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.</em></p>
diff --git a/src/articles/SingleSourcePublishing/entry6.md b/src/articles/SingleSourcePublishing/entry6.md
new file mode 100644
index 0000000000000000000000000000000000000000..3c3cbf4c5ad6640bc967f9f529db4b330d312030
--- /dev/null
+++ b/src/articles/SingleSourcePublishing/entry6.md
@@ -0,0 +1,204 @@
+---
+title: "Single Source Publishing"
+subtitle: "Part 6: Concurrency"
+author: Adam Hyde
+---
+ <p class="paragraph">In publishing there are two types of concurrency we care about:</p>
+ <ol>
+ <li>
+ <p class="paragraph"><strong>workflow concurrency</strong> – the ability to perform multiple tasks
+ upon the work, by different people, at the same time</p>
+ </li>
+ <li>
+ <p class="paragraph"><strong>realtime editing</strong> – 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 <a
+ href="https://www.plasmic.app/" rel target="blank">Plasmic</a> / <a href="https://www.figma.com/"
+ rel target="blank">Figma</a> etc)</p>
+ </li>
+ </ol>
+ <p class="paragraph">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).</p>
+ <figure><img
+ src="images/uploads/SSP/A6-Img1.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">This is workflow concurrency.</p>
+ <p class="paragraph">Now, if we want two people to edit the same chapter at the same time this is realtime editing.
+ </p>
+ <figure><img
+ src="images/A6-Img2.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">Of course we can blend these two models:</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/A6-Img3.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">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 <a
+ href="https://www.plasmic.app/" rel target="blank">Plasmic</a> and <a href="https://www.figma.com/"
+ rel target="blank">Figma</a>). 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 <a
+ href="https://github.com/xylk/prosemirror-firebase" rel target="blank">ProseMirror and
+ Firebase</a> / <a href="https://demos.yjs.dev/prosemirror/prosemirror.html" rel
+ target="blank">ProseMirror and yjs</a>) then you <em>can</em> achieve simultaneous realtime editing.
+ </p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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.</p>
+ <h2>Concurrency vs Sequential Workflows</h2>
+ <p class="paragraph">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</p>
+ <p class="paragraph">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).</p>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">There are two essential characteristics of concurrency:</p>
+ <ol>
+ <li>
+ <p class="paragraph">the opportunity to see the current state of the work at any moment</p>
+ </li>
+ <li>
+ <p class="paragraph">the opportunity to act on the current work at any moment.</p>
+ </li>
+ </ol>
+ <p class="paragraph">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:</p>
+ <p class="paragraph">1.<strong> understanding state</strong> – an immediate understanding of the
+ state of the work at any moment</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/A6-Img4.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">2.<strong> reducing handling time</strong> – reducing the to and fro of
+ passing documents back and forth</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/A6-Img5.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">3. <strong>parallel processes</strong> – various team members can do what they
+ need to do in parallel with each other</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/A6-Img6.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">4. <strong>realtime problem solving</strong> – issues can be resolved in
+ realtime.</p>
+ <p class="paragraph"></p>
+ <figure><img
+ src="images/A6-Img7.jpg">
+ <figcaption class="decoration"></figcaption>
+ </figure>
+ <p class="paragraph">These 4 opportunities provided by concurrency can have, even if moderately implemented, a huge
+ impact as Ken Brooks has attested:</p>
+ <blockquote>
+ <p class="paragraph">“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.”<br>—<a href="https://www.linkedin.com/in/kmbrooks" rel
+ target="blank">Ken Brooks</a>, president, Treadwell Media Group.</p>
+ </blockquote>
+ <p class="paragraph">But concurrency also allows for completely new ways of working, as Barbara Rühling from
+ Book Sprints points out:</p>
+ <blockquote>
+ <p class="paragraph">“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. ”<br>— Barbara Rühling,
+ CEO, <a href="https://booksprints.net/" rel target="blank">Book Sprints</a></p>
+ </blockquote>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">Here are some examples of where concurrency could benefit a common publishing workflow:</p>
+ <ul>
+ <li>
+ <p class="paragraph">Art logs and image research starting as soon as FPO (‘for placement only’)
+ images are placed</p>
+ </li>
+ <li>
+ <p class="paragraph">Alt text being created as images are being added</p>
+ </li>
+ <li>
+ <p class="paragraph">Indexing could start as the text is completed (inserting tags) before the proof stage</p>
+ </li>
+ <li>
+ <p class="paragraph">Proofing being finished on one part of the book before the rest is finished</p>
+ </li>
+ <li>
+ <p class="paragraph">Concurrent page rendering enables author to correct or fit content as they write it</p>
+ </li>
+ <li>
+ <p class="paragraph">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).</p>
+ </li>
+ <li>
+ <p class="paragraph">Multiple authors working on the same text at the same time</p>
+ </li>
+ <li>
+ <p class="paragraph">Designers working on design of the actual content as a work is being created</p>
+ </li>
+ <li>
+ <p class="paragraph">Copy editors working on content immediately as it is completed by an author</p>
+ </li>
+ <li>
+ <p class="paragraph">Illustrators placing images in a work as it is being authored</p>
+ </li>
+ <li>
+ <p class="paragraph">Production editors understanding exactly what has and hasn’t been done at any time
+ </p>
+ </li>
+ <li>
+ <p class="paragraph">Developmental editors and authors working on the same text at the same time</p>
+ </li>
+ </ul>
+ <h2>SSP and Concurrency</h2>
+ <h3>So, what about SSP and concurrency?</h3>
+ <p class="paragraph">Remember these two features of concurrency listed above:</p>
+ <ol>
+ <li>
+ <p class="paragraph">the opportunity to see the current state of the work at any moment</p>
+ </li>
+ <li>
+ <p class="paragraph">the opportunity to act on the current work at any moment.</p>
+ </li>
+ </ol>
+ <p class="paragraph">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.</p>
+ <p class="paragraph">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:</p>
+ <blockquote>
+ <p class="paragraph">“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. “<br>— Andrew Savikas,  Chief
+ Strategy Officer at <a href="https://www.getabstract.com/" rel target="blank">getAbstract</a></p>
+ </blockquote>
+ <p class="paragraph">(c) Adam Hyde, 2021. This work is licensed under a <a
+ href="http://creativecommons.org/licenses/by/4.0/" rel target="blank">Creative Commons Attribution 4.0
+ International License</a>.</p>
+ <p class="paragraph"><em>Thanks to Wendell Piez, Ken Brooks, Andrew Savikas and John Maxwell for feedback. Thanks
+ also to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.</em></p>
diff --git a/src/articles/articles.json b/src/articles/articles.json
index 1337103453e47979262f81c9deb8caef8079c1a7..bc523c7bf5ab99a2d9901fac7d84053b5dfb3b82 100644
--- a/src/articles/articles.json
+++ b/src/articles/articles.json
@@ -1 +1,4 @@
-{ "layout": "article-single.njk" }
+{
+ "layout": "article-single.njk" ,
+ "permalink": "/articles/{{ title | slug }}/{{subtitle | slug if subtitle}}"
+}
diff --git a/src/layouts/article-single.njk b/src/layouts/article-single.njk
index 0cf4089989b91c87a3bc402e58eb3ae8c9214e32..0d26a2d0a981dcf6ba87867f35646c612164ad73 100644
--- a/src/layouts/article-single.njk
+++ b/src/layouts/article-single.njk
@@ -9,6 +9,9 @@
<header>
<h1>{{title}}</h1>
+ {% if subtitle %}
+ <h2>{{subtitle}}</h2>
+ {% endif %}
</header>
<article class="post-content">
diff --git a/static/images/uploads/Coko.png b/static/images/uploads/Coko.png
new file mode 100644
index 0000000000000000000000000000000000000000..e36880803c52f73bc46ddfd8132cf9c2ed9ec546
Binary files /dev/null and b/static/images/uploads/Coko.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img01.png b/static/images/uploads/SSP-Kotahi/img01.png
new file mode 100644
index 0000000000000000000000000000000000000000..4edcdee5f3afce508f63a0a69049c5a16ee03ebd
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img01.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img02.png b/static/images/uploads/SSP-Kotahi/img02.png
new file mode 100644
index 0000000000000000000000000000000000000000..ab99b2790b3018cad19db8d914a8b495a2737811
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img02.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img03.png b/static/images/uploads/SSP-Kotahi/img03.png
new file mode 100644
index 0000000000000000000000000000000000000000..93d0575a9a81fe5174eb68b4d6693d8ff848d3ad
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img03.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img04.png b/static/images/uploads/SSP-Kotahi/img04.png
new file mode 100644
index 0000000000000000000000000000000000000000..13b1c3e7748491f7eddb2b7b72ba75ec39565676
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img04.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img05.png b/static/images/uploads/SSP-Kotahi/img05.png
new file mode 100644
index 0000000000000000000000000000000000000000..146a507f745a9513ec5e2180a75a148775c0a4a0
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img05.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img06.png b/static/images/uploads/SSP-Kotahi/img06.png
new file mode 100644
index 0000000000000000000000000000000000000000..6bf9401faa66367959aa7dc27e95c0603315995b
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img06.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img07.png b/static/images/uploads/SSP-Kotahi/img07.png
new file mode 100644
index 0000000000000000000000000000000000000000..4add7ee5bf09b4fdd218bc95d9201e0db223f506
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img07.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img08.png b/static/images/uploads/SSP-Kotahi/img08.png
new file mode 100644
index 0000000000000000000000000000000000000000..83bea034315597c7da89fd52c9f7e41c93942cd5
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img08.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img09.png b/static/images/uploads/SSP-Kotahi/img09.png
new file mode 100644
index 0000000000000000000000000000000000000000..d10e8217223c0839ebe3de7e42fe1845cae5af05
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img09.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img10.png b/static/images/uploads/SSP-Kotahi/img10.png
new file mode 100644
index 0000000000000000000000000000000000000000..fc7be1ef13242cfcd3971418282c20543543dedd
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img10.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img11.png b/static/images/uploads/SSP-Kotahi/img11.png
new file mode 100644
index 0000000000000000000000000000000000000000..11232e8122520998d135b045180d6315ef2b609e
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img11.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img12.png b/static/images/uploads/SSP-Kotahi/img12.png
new file mode 100644
index 0000000000000000000000000000000000000000..a0eeca0f235bb7985f89a74d3af5dd8815c7a6a7
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img12.png differ
diff --git a/static/images/uploads/SSP-Kotahi/img13.png b/static/images/uploads/SSP-Kotahi/img13.png
new file mode 100644
index 0000000000000000000000000000000000000000..d0e65bb934f6d574d046a2985213daf5a2aa757c
Binary files /dev/null and b/static/images/uploads/SSP-Kotahi/img13.png differ
diff --git a/static/images/uploads/SSP/A1-Img1-and-A4-img4.jpg b/static/images/uploads/SSP/A1-Img1-and-A4-img4.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..af0abf839d5c567f6ca88ad487fdcedd41994c77
Binary files /dev/null and b/static/images/uploads/SSP/A1-Img1-and-A4-img4.jpg differ
diff --git a/static/images/uploads/SSP/A1-Img2.jpg b/static/images/uploads/SSP/A1-Img2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..ab20ded7f318df817c33b9c909f6cab5d91941ac
Binary files /dev/null and b/static/images/uploads/SSP/A1-Img2.jpg differ
diff --git a/static/images/uploads/SSP/A2-Img1.jpg b/static/images/uploads/SSP/A2-Img1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..f0be9c45c79fd89123c5b36730d664724653ef10
Binary files /dev/null and b/static/images/uploads/SSP/A2-Img1.jpg differ
diff --git a/static/images/uploads/SSP/A2-Img2.jpg b/static/images/uploads/SSP/A2-Img2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..26a39deb82a57b0c33c56441e8696ece16336873
Binary files /dev/null and b/static/images/uploads/SSP/A2-Img2.jpg differ
diff --git a/static/images/uploads/SSP/A2-Img3.jpg b/static/images/uploads/SSP/A2-Img3.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7025df7bca0adf90c773596144ac33fb829fc1c6
Binary files /dev/null and b/static/images/uploads/SSP/A2-Img3.jpg differ
diff --git a/static/images/uploads/SSP/A2-Img4.jpg b/static/images/uploads/SSP/A2-Img4.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..2cab82543d6abfa6e78390f6bb6ad02a77271aee
Binary files /dev/null and b/static/images/uploads/SSP/A2-Img4.jpg differ
diff --git a/static/images/uploads/SSP/A3-Img1.jpg b/static/images/uploads/SSP/A3-Img1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..43cab5e245972909d143d7753e9834e5a44c8792
Binary files /dev/null and b/static/images/uploads/SSP/A3-Img1.jpg differ
diff --git a/static/images/uploads/SSP/A3-Img2.jpg b/static/images/uploads/SSP/A3-Img2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..770e67713cd7069da45e4e0e097fd3d44ded074a
Binary files /dev/null and b/static/images/uploads/SSP/A3-Img2.jpg differ
diff --git a/static/images/uploads/SSP/A3-Img3.jpg b/static/images/uploads/SSP/A3-Img3.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..a2fabeda6c9ff209b8a55548f4196c928f8034fa
Binary files /dev/null and b/static/images/uploads/SSP/A3-Img3.jpg differ
diff --git a/static/images/uploads/SSP/A3-Img4.jpg b/static/images/uploads/SSP/A3-Img4.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..2d9a28f0aa8f18833afc589c49b99b1be0fe8436
Binary files /dev/null and b/static/images/uploads/SSP/A3-Img4.jpg differ
diff --git a/static/images/uploads/SSP/A4-Img1.jpg b/static/images/uploads/SSP/A4-Img1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..ed5a5dd3024fb5d6f1af29ccbaa54de50c6eb159
Binary files /dev/null and b/static/images/uploads/SSP/A4-Img1.jpg differ
diff --git a/static/images/uploads/SSP/A4-Img2.jpg b/static/images/uploads/SSP/A4-Img2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..a566dcf5181bfea635da636ea94117e9380e4ff6
Binary files /dev/null and b/static/images/uploads/SSP/A4-Img2.jpg differ
diff --git a/static/images/uploads/SSP/A4-Img3.jpg b/static/images/uploads/SSP/A4-Img3.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..aed92c06871fabed41598196fce038e22a15ef9d
Binary files /dev/null and b/static/images/uploads/SSP/A4-Img3.jpg differ
diff --git a/static/images/uploads/SSP/A5-Img1.jpg b/static/images/uploads/SSP/A5-Img1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..c36e33e48603f62996e24927c1accc58c340037b
Binary files /dev/null and b/static/images/uploads/SSP/A5-Img1.jpg differ
diff --git a/static/images/uploads/SSP/A5-Img2.jpg b/static/images/uploads/SSP/A5-Img2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..c84424e50f41ec1fbfbcc405a190fa1d7e17e495
Binary files /dev/null and b/static/images/uploads/SSP/A5-Img2.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img1.jpg b/static/images/uploads/SSP/A6-Img1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..ea724d414a657582d697202fa0ef7c19e8c61653
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img1.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img2.jpg b/static/images/uploads/SSP/A6-Img2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..90a1bb294c81554a9a866b56956854d6248191f6
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img2.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img3.jpg b/static/images/uploads/SSP/A6-Img3.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..6af19dd461b8cb6a84aec13bc61de0ec5263cfb9
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img3.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img4.jpg b/static/images/uploads/SSP/A6-Img4.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..d96f63fee353e2c4f175131792576f1a83e88fb2
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img4.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img5.jpg b/static/images/uploads/SSP/A6-Img5.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..6383fac551fc76f36833bd43def2cea84921c102
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img5.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img6.jpg b/static/images/uploads/SSP/A6-Img6.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..e993ab24f2e80d32a4086b4834cec8cc67003ea2
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img6.jpg differ
diff --git a/static/images/uploads/SSP/A6-Img7.jpg b/static/images/uploads/SSP/A6-Img7.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..371934af10a3505689c0d2c43bc975018bf0945b
Binary files /dev/null and b/static/images/uploads/SSP/A6-Img7.jpg differ