Why Microsoft developers need a style guide

Note to all coders: What your interface communicates to users can be just as important as what your software does

Page 2 of 2

Hidden gotchas of a global audience
Given the rapidly expanding global software market, internationalization is one of the most important UI design concerns. For many developers, internationalization simply means translating software prompts into other languages. But as Microsoft's manual points out, developers should be thinking about international markets even before they reach that point.

For example, UI designers should take pains to write in concise, clear Standard American English. Writing plainly is important for readability, but it also makes the sentences easier to translate. That's especially true if you're using machine translation, which can be a huge boon for software internationalization, provided your sentences are unambiguous and don't rely too heavily on idioms.

What you say to international audiences can be as important as how you say it. Here, Microsoft's advice isn't always intuitive. For example, you should avoid mentioning seasons wherever possible to avoid ambiguous associations; remember, Australians celebrate Christmas in the summer. Certain colors have political or religious significance in many cultures, too.

Especially treacherous are those words that have become part of the standard computing jargon but that may carry negative associations for some English speakers. In computer security, for example, a subnetwork containing systems that are exposed to the public Internet is called a DMZ, but that term could have unwanted connotations in war-torn countries with active demilitarized zones.

Similarly, the relationship between USB peripherals could be described as "master/slave," but these terms could also be considered offensive. (The "Microsoft Manual of Style" says such language is prohibited in "at least one U.S. municipality.")

Some tips are better than others
Occasionally, Microsoft's recommendations verge on the absurd. For example, you might not think it necessary to admonish developers to "not use slang that may be considered profane or derogatory, such as 'pimp' or 'bitch,'" but apparently it is.

Other sections of the manual seem designed primarily to ensure that writers toe the Microsoft company line. For example, no Microsoft communications may use the term "blue screen" to describe a program crash. Internet Explorer should never be abbreviated. And "hackers," in Microsoft parlance, are always of the black-hat variety: "Do not use 'hack' to refer to improvising a solution to a programming problem. Do not use 'hacker' to refer to an amateur programmer."

This howler stuck out, in particular: "JScript is the Microsoft implementation of the ECMAScript scripting language specification, an open standard. Do not refer to it as 'JavaScript,' which is the corresponding implementation by Time Warner." Huh?

More often than not, however, the "Microsoft Manual of Style" offers sound advice that can be beneficial to any software development organization, large or small. Its advice covers not just user-facing text but also source code comments and SDK and API documentation. And consider this: Independent developers who master Microsoft's linguistic advice gain one more hedge against competition from offshore outsourcing.

The book's greatest value, however, is simply that it can get programmers thinking about language in the context of software development. That's something the industry could use more of. After all, in an information economy, how you communicate information is at least as important as how you process it.

This article, "Why Microsoft developers need a style guide," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies