By Ray Gallon | Senior Member
Standard Deviation is a column all about standards—a subject that affects most of our lives, but that we seldom think about. As the title implies, I want to keep the conversation lively and engaging. I’m always looking for guest columnists, and we welcome feedback with comments or requests for standards-related topics to cover. Email me at rgallon4stc@culturecom.net.
In the last Standard Deviation column, Alan Houser raised some important questions about how to measure if a standard is successful. His inquiry about how we find useful standards “in the wild” raised another important question: should we have general, independent standards for technical communication, or are we best served by sections included in specific industry-related standards?
In an ideal world, I would answer, “both”: 1) we need standards for the profession to determine best practices, norms, etc. at a high level; and 2) each industry needs to focus on its specific needs and specify them. In the real world, we can’t always depend on this.
Why develop a standard?
In my view, a standard should be developed only when there is a specific, expressed need. For example:
- The mobile telephone systems of the world need to be technologically compatible with each other to permit international roaming.
- In order to efficiently distribute electrical demand load across the European continent, European countries need to agree on a common voltage for high-tension transmission, and for step-down to domestic use. Common voltage is also necessary for efficient manufacturing of electrical appliances.
- In a global economy, certain basic terminology related to health, safety, or security needs to have agreed definitions and associated symbols that are used in documentation.
- Airport signage needs to use standardized visual symbols to avoid linguistic (and cultural) misunderstanding.
- Companies developing new technologies see that there is more advantage in having standardized signalling protocols, file formats, etc. that leave them free to develop functionality, rather than competing over (and wasting money on) which company’s proprietary format will become a de facto “standard.”
- Regulated industries need to know the standards to which they will be held accountable in different parts of the world.
Why use a standard?
One response that came in to our request for information about what standards people use in their daily work came from STC member Mike Unwalla, who uses the Simplified Technical English (STE), specification ASD-STE100 (www.asd-ste100.org). Mike mentions that there are around 3,300 copies of the latest version in distribution. This specification is available for free, but Mike says he paid for it in the past, because it was useful.
His response got me thinking: like DITA, mentioned by Alan Houser in his guest column, STE is about practice. It’s not about what you should or shouldn’t say in a document, and it’s not even directly about information typing or structure. DITA is, of course, about semantic markup, but the structure that derives from DITA is the result of using DITA, not the result of specifying the structure a document must have to meet a certain norm. To clarify, we technical communicators like standards that provide us with tools. DITA as a specification is useless to us—we need editors and content management systems that enable it. These tools, together with the DITA schema, guide and facilitate our work.
The DITA technical committee, of course, thinks about structure and information typing—that’s their job. But instead of specifying what structure we ought to use, and which information types need to go where, they specify a tool that helps us do that ourselves in a practical way.
Otherwise, as Mike put it, “Much of the information in the standards that I know about is the type of information that is available for a tenth of the price in a good reference book…. Why bother with a standard?”
Where should they come from?
Returning to the initial question, “Should we have general tech comm standards or should they be embedded in industry-specific standards?”, the real-world answer has to be, “Wherever we get the most practical results.”
“Most practical” might mean not in an official standard at all. The Microsoft Manual of Style has become the de facto standard for so ftware documentation. I don’t think I’ve ever worked in a technical communication department that didn’t have a well-thumbed copy of it.
The question echoes a decades-long debate about whether technical communicators themselves should be in their own department, or embedded with project teams, and like that debate, it probably does not have one definitive answer. But one thing should be clear: without adoption, there’s no standard, and to get adoption, a standard must be practical, available, and meet a clearly expressed need.
