User Assistance: Standard Gauge

by Tony Self  

It doesn't quite sound believable, but it's true. In 21st Century Australia, there isn't a standard national rail gauge. (Gauge is the gap between railway tracks.) In some states, narrow gauge is used, in others broad gauge, and ironically in just one state, standard gauge. This means that rail cars and locomotives can't travel between states.

This schmozzle started in 1847, before the independent colonies of the Australia continent became states in a federated nation in 1901. It was in 1847 that the first railway lines (in South Australia) were built. It started well, with a decision by the British Government's Secretary of State for the Colonies that all colonies should adopt standard gauge.

But what does this obscure historical anecdote have to do with technical communication? Let's think standards, and how standard adoption by an industry can go horribly wrong with enormous, long-term financial consequences.

A private company building a railway line in New South Wales lobbied for the standard to be changed to broad gauge. Broad gauge became the new standard in 1854. A year later, the chief rail track engineer in New South Wales was replaced, and the new chief convinced the New South Wales government to unilaterally change the NSW "standard" back to standard gauge. And the same pattern continued until there was no standard left.

You may be awestruck by these decisions, but in context, having a standard made little difference. Australia is a big continent, and the mooted railway lines were short and were contained well within the colony. There were no plans for railway lines to cross borders, so as long as all lines within a colony used the same gauge, there would be no problem.

There are many standards in technical communication, and their adoption is haphazard and parochial, to put it kindly.ISO/IEC 82079 is an international standard for technical communication, covering all types of product, software, and service related instructions for use. ISO/IEC 26514 provides requirements for the design and development of software user documentation. Both these standards arouse very little discussion in online forums or at technical communication conferences.

The Organization for the Advancement of Structured Information Standards, OASIS, approved the DITA standard in 2005, and although its adoption is growing, it is still nowhere near widespread in technical communication. Are technical communicators generally reluctant to adopt standards? It is undeniable that technical communicators love some standards, such as spelling and grammar, and argue strongly for the benefits of such language standards and conventions. But it seems to me that beyond language standards, we collectively show the same attitudes as the late 19th century colonial railway engineers.

The consequences of the Australian railway gauge decisions are still being felt, and paid for, 130 years later. Interstate tracks are slowly being changed to standard gauge, often by duplicating tracks. Blame for the decisions of the late 1800s is often sheeted to "politics." Rivalries between companies and colonies and even individuals, power struggles, and deep-seated prejudices were the cause. We have to be non-standard because our requirements are special. These same arguments are used by some technical communicators to avoid adoption of standards and as an excuse to implement a custom solution. Perhaps we, as a profession, need to move beyond the politics of standards and work together in a standard way.

Have anything to add when it comes to standards in technical communication? Feel free to post your comments below.

Comments

[Greg Babb]

Thanks for the interesting post. The first thing one must consider is the set of standards governing our industry and product. Take it from me; I work in the German-speaking part of Europe (DACH), and companies here are obsessed with standards. Such standards often also dictate what goes into the documentation. So in a way, by the time we've implemented these layers of standards, we're often not in need of yet another standard for the technical communication process itself. Having said that, it might however be useful to check out technical communications standards - if and when we have time for it.