Why Microsoft Developers Need a Style Guide

snydeq writes "What your interface communicates to users can be just as important as what your software does, writes Fatal Exception's Neil McAllister in discussing the latest edition of the 'Microsoft Manual of Style', a style guide aimed at designers and developers who create Microsoft software, as well as those who write about it. 'The gist of much of Microsoft's advice is that a user's relationship with computer software is a unique one, and it's important to craft the language of software UIs accordingly,' McAllister writes. '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.'"

If it's in the Style Guide, it actually happened..

[DontScotty]

And - people can not avoid or fix mistakes which they do not know about.

Silence on an issue = consent. So, if MSFT had not mentioned avoiding "'pimp' or 'bitch"; someone raised in an environment where that was ok - (looking at you, teens and young twenty-somethings who grew up saying "That's Gay" when you meant wrong, bad, or odd) may not fully realize the problem with borderline and unacceptable language.

Example: Error Message = "What a bitch! Just dumped a debug file in my program folder" or in the HELP>ABOUT saying "Hey, if you want additional functionality, allow me to pimp the ENHANCED version @ paymemorecash.local"

Re:If it's in the Style Guide, it actually happene

[bloodhawk]

while the derogatory terms etc may seem obvious, there are plenty of less obvious mistakes that people fall into. For instance we used naming conventions on errors in on of our production applications that referred to greek mythology and specifically the underworld. It came as quite a shock when we received official complaints from religious nutcases that said they were offended by our blasphemy. Since then we have had to rewrite a lot of that to use far more boring errors.

Re:If it's in the Style Guide, it actually happene

[russotto]

while the derogatory terms etc may seem obvious, there are plenty of less obvious mistakes that people fall into.

And sometimes not-mistakes. As some of the executives of a company I once worked for had to explain away (to a female user working for a major customer, naturally) an error box written by an ex-employee by claiming it was simply an unfortunate typo for "count error".

Re:Shorter version

[Gadget_Guy]

Why MS devs need a style guide: they thought the ribbon was a good idea.

Quite frankly, it was. I did have some problems, like the icon that turned out to be a menu (how many people had problems with that?) and Microsoft's refusal to repeat any function on two different tabs (so if something is on the home tab then it cannot appear elsewhere even if it should logically be on that other tab). However, if you watch ordinary people using Office 2003 (or below) then you will notice that they tend to hunt around the toolbars for functions rather than use the menus where you don't need to hover the mouse to read what a button does. The ribbon is perfect for those people. It is also good for tablet users.

The biggest problem people had with the ribbon was that it changed an existing user interface that had not changed substantially since the Windows 3.1 days. All of a sudden, they had to re-learn the package again. That is a pain in the proverbials. However, new users to Office 2007 and 2010 must surely be scratching their heads and wondering what all the fuss was about.

Re:Bad title

[SplashMyBandit]

Yeah, the "understated" UIs look great but are actually poorly designed from a usability perspective.

Example: Last week I bought an iPhone 4S and couldn't figure out how to make a call. I went to "Phone" where I had contacts and was presented with buttons for doing Face Time, sending messages, sharing contacts, and adding a contact to favorites, but there was no button to make a call. I mean, given that choosing the Phone app means you will want to make a call on a selected contact about 95% of the time you would think there would be a massive "Call" icon, since that is the most common thing you'd like to do. It turns out you have to tap on the phone number to make the call - even though there is absolutely nothing to indicate that tapping the number would make a call (my expectation was that tapping the number would edit it). Now that I know that all the interface elements are clickable "buttons" *even if they don't look like the buttons shown elsewhere* things are much easier (and this is coming from a long-time user of Macs). While many of the UI features of Apple are excellent I consider their minimalist approach has gone so far as to present too little information. My point here is that while we are decrying Microsoft for their UI designs we can also do the same for Apple. Mostly less is more, but sometimes less really is less. One of my hats is a trained technical writer and from that point-of-view I consider some elements of Apple's style to be very, very bad - but that is not a particularly fashionable point of view at the moment.

Re:I have an idea for the style guide

[Coriolis]

As a huge fan of fluent code, but also as someone who prefers to see the distinction between a promise and a concrete implementation to be at a glance of the class definition, I have to disagree. Of course you should be using a language derived from your problem domain, but if your problem domain contained all you needed for the solution, then it itself would be the computer program. At some level, you have to use the language of the solution domain, you can't wish it away. I would also say that, these days, having to chance the name from ISomething to plain Something is no big deal, due to built-in refactoring support. Finally, what are the deprecated constructs and styles in C#? Can't think of any of the top of my head.