Single Source Publishing Part 2: A Solution
The second article in a short series by Adam Hyde about Single Source Publishing. Part One here.
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.
WordPress is a single source publishing system. To produce a post, the author does the following:
- writes the post within WordPress, using the basic web editor supplied
- presses ‘Update’ and the content is pushed through to the web
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.
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.
Single Source and Multiple Actors
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.
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.
Single Source and Multiple Outputs
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.
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.
So what’s the problem?
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?
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.
The content you are editing in WP is stored as HTML. Exactly that same source is directly transferred to the web at publish time.
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.
When designing a publishing system you face two basic questions, in this order:
- what output formats do I need?
- what source file would best lend itself to transformation into the outputs?
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.
Unfortunately, the process for designing systems too often takes the following format, in this order:
- what source file format is currently in fashion? (hint: it has been XML for the last 20+ years)
- how do I build a system around that format?
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 . But I’ll get to that in some of the upcoming articles in this series.
Part 3 now available here. Thanks to Henrik van Leeuwen for the images and Raewyn Whyte for copy editing.