He has no friends, but he gets a lot of mail.

Thursday 3 December 2009

Single sourcing is a bad name for multiple sourcing

Michael Hiatt's The Myth of Single Source Authoring has caused a bit of comment in the technical communication arena.  But it's not an attack on single sourcing, at least the way I understand it. The clue is in his second paragraph:
And who will be our emerging heroes to fill the promise of content reuse and localization savings? Knowledge mashups and applications using cloud-based linked data and the emergence of the semantic Web.
Wait, what? Single sourcing is essential for knowledge mashups! Let me explain:



Single sourcing may be a bad name. Single sourcing does not mean "a tightly-controlled, single, authoritative source for all information, presented in a canonical form which will be used regardless of the output format or the audience." It certainly doesn't mean, as he puts it, "the belief that static authoring from a single vantage point from a single author paid by a single organization is a workable system". Of course it isn't. Wasn't that the precise thing single sourcing was developed to overcome?


For me, single sourcing means "for each piece of information, having an identifiable owner, and empowering that owner to act as a single source for that information, in whatever information use environment it is presented."
 

In the old days, every document had a single author (paid by a single organization), which meant that the same information was presented in different ways in different documents. And this is the most important point that Michael makes: there was nothing wrong with this, because a well-designed documentation set is broken up into documents aimed at different use environments, therefore each document should be written in a different way. The biggest mistake in the single-sourcing world is the idea that you can reuse authored topics effectively between use environments, but even Wikipedia knows that.


The author's job, in both traditional and single-sourced contexts, is to identify an information use environment, in fact, to enact an information use environment. "Information use environment" includes audience, language, culture, expectations, anything which affects how someone uses information. There are technically as many information use environments as there are occasions a person has to use information; but readers are malleable, and willing to mould their environment to some extent to fit with the information they have access to.


Once the use environment has been enacted, and agreed between author and reader, then the author can "suit" the information she presents to that environment. The difference between traditional authoring and single-source authoring is that the process of "suiting" information in a single-sourced system occurs at the single, original, source of the information, or at least at the point where it enters the author's domain, not at the point where it leaves to be assembled into a document.


For material which is authored in-house, the difference is small, since it is the author who originated the material. Likewise, for material which an organization aims at a very specific information use environment, the difference is small, since it is the author's organization that enacted that use environment.


So how can we benefit from single sourcing? The key is in that action of enacting. In a small company, the sole technical author bears responsibility for enacting the use environment. Because she enacted it, she finds she cannot reuse anyone else's information. As organizations grow, authoring teams share house standards, and the enacted use environments get codified so that authoring teams can successfully collaborate. If, as Michael says, "a writer seldom grabs a topic wholesale and places it into his or her document. Topics rarely meet all needs of the author and usually throw off the context and purpose of the document", this is a symptom of a lack of standards in the organization, so that individual authors are making their own decisions about the target audience.


Sometimes this is the right thing to do, and as an organization grows, naturally the number of use environments it is exposed to also grows; but there is always a core, the "standard documentation set", whose use environment has been fully enacted and formalized.


Which is where mashups come in. We cannot expect a mashup to be successful unless we share enacted use environments between organizations; ultimately, globally. But when this happens, it will be a revolution, because readers of any content from any organization will understand their role in the environment, it will become part of the culture of information use, not just part of the house style of an organization. (Look at the "enacted use environment" of pictograms in airports and other places: a truly global standard, which almost everyone thinks of as "intuitive" purely because it's so culturally ingrained.)


With single sourcing, once we have agreed (to whatever extent) to enact a particular use environment and write content for it, an organization will be able to re-use content from any other organization, anywhere, and it will fit in seamlessly. Without it, an organization will always have to rewrite information so that it speaks their language.


And that is why single sourcing is really multiple sourcing.

Twitter / dajlinton