Voice in Technical Writing
The next version of Windows has the code name Longhorn. That's not really a secret; you can read about it on the Longhorn page on the Microsoft Web site. I went to a presentation about the Longhorn voice, where they described the philosophy behind the style of writing they want to have for the Help and UI text. For the most part, it sounds like good advice for any technical writing—the same good advice we usually hear, but that we have a hard time putting into practice. Not because we don't want to, but I think because there's a long history of technical writing in a style that is associated with professional or technical things. That style instantly springs to mind when I start to describe something technical, and it takes effort to replace it.
The typical style is usually the machine voice; a clipped, sentence-fragment style that perhaps sounds like a no-nonsense computer is generating the instructions, for example "Estimated disk usage at 54 percent." There's no attempt to address anyone who might care about the fact; it's just a fact that is stated.
To avoid the machine voice, some people adopt a marketing or sales rep voice that goes too far the other way: "It's really easy to connect to your data—just drag-n-drop the data icon and presto, you're done!" There's some personality here, but it gets a bit hard for me to read after a few sentences. There's just too much personality, I guess.
The goal of the Longhorn voice is to be more conversational; not sounding like the writer is trying to drum up enthusiasm artificially, and not presenting facts that don't seem to need a reader. It's the advice I always read in books about technical writing, but Longhorn is institutionalizing it so that everyone on the team knows to try harder to overcome the first technical phrases that spring to mind about a new feature (or that are lifted from a spec). I think it will take a team effort to achieve this voice; everyone wants to write in a way that's easy to use, but it will be hard to do it consistently without a conscious team effort.
In my own division (the developer division—I work on a small part of the Visual Studio Help), we haven't focused much on voice. Certainly we aim to write in a style that is easy to read and that is active, but as a division we haven't come up with examples of good writing (with some sort of personality) that should be emulated throughout the Help and UI. I think we probably should. Even though we're writing what is primarily reference material to help developers find the information they need as quickly as possible, a little personality might make it a bit easier and more enjoyable to use.