I loved Lucy Kellaway's (she of the Financial Times) article "Words to describe the glory of Apple" comparing the language style used by Apple and Microsoft and wondering if language style impacts the bottom line. If you don't want to register for the article, then the podcast version is here.
Ms Kellaway tells us that Apple's language makes for content that is "fun to read", "elegant", and "makes you laugh". It has a tone that is "direct', 'comic", and "elegantly threatening". She contrasts this with the Microsoft language used for the new version of Internet Explorer, "architected to run HTML5, the beta enables developers to utililize standardized markup language across multiple browsers" and the rest. This is "standard stuff" from Microsoft, and Luce is "irritated", "bored", "alienated", and "restless" with it.
Actually, I think the article is unfair to Microsoft, who do care about language and the example used is not representative of language used in other Microsoft products - games, for example. Plus, the audience for their words is different to Apple's; basically it's a marketing pitch to Microsoft's partners, encouraging uptake of a beta release.
The Apple language that Ms Kellaway admires is taken from the App Store Review Guidelines (full PDF version); a set of guidelines more likely to be read by geek and hobbyist developers working from home than the corporate equivalents. Such language is not used in other Apple products themselves. In fact, language quality is not an acceptance criterion for App Store submissions at all. That of course, is telling in itself. Why not let the market, the users, decide on the language?
In line with this, the Human Interface Guidelines from Apple for the iPhone has a common sense approach to language style. For example:
In all your text-based communication with users, be sure to use user-centric terminology; in particular, avoid technical jargon in the user interface. Use what you know about your users to determine whether the words and phrases you plan to use are appropriate.
For example, the Wi-Fi Networks preferences screen uses clear, nontechnical language to describe how the device connects to networks.
Very reasonable from a user experience perspective.
But, then Lucy says: "You might think there was a clear commercial advantage to be had in writing clearly and stylishly. But you would be wrong."
Not quite. There is a relationship, though it may not be all that visible to key decision-makers. That's because the commercial advantage does not come from writing clearly or stylishly per se, but its application. It comes from writing content that users actually want, in a way that they can understand, using terms and language that suits them; and that facilitates easy search and retrieval. The result is a quicker transfer and comprehension of information leading to better productivity for users and less training and support costs. And that's a competitive advantage.
In the enterprise applications space the opportunities for a product language tone that is "fun", "comic", or "elegantly threatening" doesn't exist in the same way it does for the iPhone app development community (and let's face it - for all the BS about the iPhone - most apps are little better than free low-tech toys designed by rank amateurs).
But that's not the point. The point is the language should suit the audience for the information. We need to spend less time worrying about our internal language style and all its nuances and rules and concentrate more on how users - our customers - themselves want it to be, and actually use it.
Bringing terminology in line with user expectations and concentrating on a few basic writing principles grounded in research on information search, retrieval, consumption, and problem-solving would yield far better bottom line results than fretting about a rigorous adherence to every single aspect of a style guide for no other reason than it's there.