Single-sourcing is dead. Long live shared pipes!
The term single-sourcing is too simplistic to describe today’s content creation environments.
Back in the 1990s, single-sourcing meant creating content in one format and then converting that content into another format. So, for example, you authored content in FrameMaker. The FrameMaker files were print-ready and you could generate PDF from them. For online outputs, there were converters, such as Harlequin WebMaker, WebWorks Publisher, or (much later) ePublisher Pro.
Single sourcing: Authoring and formatting in FrameMaker, then publish to PDF and HTML
The key to single-sourcing is that you put all of your content into a single format and workflow, then push the content (with varying degrees of pain and rework) to multiple output formats.
Many single-sourcing workflows were print-first. You created the print files and then figured out how to derive online formats from those files.
Introducing separation of content and formatting
Then, along came SGML and XML. The premise of these and other markup languages is separation of content and formatting. We mark up the text with a tag, and that tag is interpreted differently in print than in HTML. The <emphasis> tag might result in italics in print and in boldface online.
In general, though, we have been trying for a world in which all authors work in a single environment (such as DITA XML, the Darwin Information Typing Architecture), and we pushed their content through the same workflow to generate output. We have oceans of posts on “how to get more people into XML” or “how to work with part-time contributors.” The premise is that we have to somehow shift everyone into the One True Workflow.
Separation of authoring and rendering in DITA
But today, we have a complex landscape with lots of different places to create, store, manage content. Different software vendors are promoting different ways of doing things.
Some component content management system vendors offer integration their system and a variety of delivery portals. Some vendors offer end-to-end solutions that include authoring, CCMS, and delivery.
Shared pipes
I believe that our future is shared pipes; that is, a shared infrastructure for terminology, information architecture, and localization.
Shared pipes, diverse sources
To ensure a minimum level of quality, all content must go through the pipes.
Where appropriate, we’ll have single-sourcing, but not all content needs the same level of quality review. Instead, we’ll have make a distinction between “quick and dirty but good enough” and “must be the best quality we can manage.”
In a shared pipes environment, all of your content might use the same rendering and localization workflows, but diverse source formats and authoring tools.
What do you think? Is single-sourcing still the right term? Are we evolving toward a more complex workflow?
About the author
Mark Baker
Hi Sarah,
I am so glad you posted this. I have been saying this for so long that I had begun to feel like the voice of one crying in the wilderness.
Now, if your question is whether we will actually go in this direction, I may be a little jaded, having been suggesting it for so long now. But sometimes you simply have to wait for the right time and say it in the right way. I love the shared pipes image and I hope it does the job of getting the idea and its importance across.
In the meantime, you post inspired a post of my own: Time to move to multi-sourcing https://everypageispageone.com/2018/04/06/time-to-move-to-multi-sourcing/
Sarah O'Keefe
Hi Mark, great to hear from you! I was just reading your post. We’ll have to see where all of this goes..I am going to be refining this concept and presenting it at upcoming conferences.
Chuck Vermette
Sarah how does what you’re advocating differ from what any CMS is designed to do? I’m not clear on that.
Sarah O'Keefe
Hi Chuck,
If you can get all your content into a single CMS, you can manage it successfully. I’m pointing toward a future where we can get alignment even when different groups are using different tools.
Mark Giffin
This strikes a chord Sarah. How about giving a concrete example of what the tools level might look like? Or some idea of the interfaces between the different pieces that will harmonize things?
I had a crude thought of ingesting Markdown content into the DITA Open Toolkit and publishing it from there. Or DocBook XML ingested into Adobe Experience Manager Web CMS. Am I off the mark? How would translation work amongst all the pieces?
Sarah O'Keefe
Hi Mark,
The use case of different authors using Markdown and DITA is a great example. It all works the first time you import the Markdown into DITA and publish. But then what? How do you make the updates? Are they made in Markdown? Do you re-import?? That’s what I’m struggling with…
techwriterkai
We’re currently tinkering with tech writers writing in Flare and developers contributing content in github Markdown. The best we’ve come up with so far is a recurring import of the developers’ Markdown source into a Flare snippet with a wrapper around it that is maintained by the tech writer. This means we don’t have to roundtrip, but can insert the current status of the Markdown nuggets into the larger Flare content flow. Not exactly elegant, but simple and robust.
Lee Creighton
I’m wondering what tools—or, rather, combinations of tools—would work well in a shared pipes situation.
Being a longtime FrameMaker user, I’ve gotten very used to using its marker system as a springboard to multiple output formats. What kind of setup would we need to allow multiple authoring tools, yet still add the meta-information needed to do the equivalent of FrameMaker Index markers? In addition, I used custom FM markers to develop hooks between C++ code and pieces of documentation. And unless we forbade non-writers access to the source files, all sorts of havoc developed as markers were inadvertently deleted.
Perhaps I am not understanding the shared pipes concept deeply enough, or my mind is still stuck in sin glee source mode. I guess I’m not able to grasp the place in the workflow where the meta-information is inserted, and how it is prevented from destruction by continued doc development.
Sarah O'Keefe
Hi Lee,
I think the real issue with shared pipes is that you cannot force people into a single, specific tool. So a workflow that requires FrameMaker and custom markers is probably a non-starter. Instead, I would look at something more sharable, like an XML core. You could still use FrameMaker and markers, but if you want to integrate with other contributors, you would find a common format to work in.