Why Microsoft Developers Need a Style Guide 262
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.'"
I have an idea for the style guide (Score:5, Insightful)
How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!
And then later let's change the types in the API but keep the unmatching old names for compatibility!
Re:Bad title (Score:4, Insightful)
Why is this for sale? You'd think they would want more well-designed software for their platform, especially with Metro just around the corner.
McAllister's an ID10T (Score:2, Insightful)
'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.'
Spoken like someone who's never written, read, or worked with any kind of code whatsoever. It's not uncommon for comments to contain language others outside the team will find offensive - developers get comfortable, and start writing for each other instead of the world at large. Since MS releases their code to outside parties, they feel the necessity to remind their coders to remember they're not the only ones reading the source.
Twit.
Re:Bad title (Score:5, Insightful)
It's the best way to encourage consistency across applications and the accompanying documentation. Does that not happen anymore?
no, it doesn't happen anymore. The original style guide was good - it said how much space to leave around the edges of dialogs, how big to make buttons and where to put the ok/cancel buttons. the end result was an overall look and feel that made sense no matter which application you used, and that meant TCO was reduced as users knew how to use it.
Fast forward to the XAML/WPF/C# era and all that went out the window in favour of "rich" UIs where you have a stupid coloured orb that everyone thinks is decoration until you realise it's the main system menu, and every application has a different set of awful skins.
I would hope (haven't read it) that this redresses the balance.
Re:I have an idea for the style guide (Score:5, Insightful)
How about, when naming variables, you have to put the first letter of the typename in the start of the variable name!
Hungarian notation isn't about using the typename at all.
Please tell that to Microsoft.
Has McAllister met any programmers? (Score:2, Insightful)
'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.'
IT skews dramatically male, and those men skew dramatically towards the socially inept. Making explicit rules about not using profane or derogatory slang in your UI is completely appropriate.
It's simple really... 2 rules, 2 things to avoid. (Score:5, Insightful)
1) Software is a conversation. Be polite.
2) Software is a servant, not an equal or a master. Software is the waiter. Don't put behavior in your software that you wouldn't accept in a restaurant.
The most aggravating and common user interface fails to avoid are:
1) Interruptions (e.g. Microsoft dialogs telling you updates have been installed, as if you give a rat's ass, refreshing a window or dialog that doesn't appear to need to be refreshed, being too helpful and hovering like Clippy).
2) Being ignored (Clicking or typing on screen and watching nothing happen).
There are, of course, many other transgressions, but most of them can be addressed by thinking through a restaurant example. If the waiter came and rearranged your dishes and silverware in the middle of your meal, you'd be furious. If the OS comes in and rearranges your screen while you're working, taking away your focus, you'll be furious. If the waiter keeps ignoring you or is slow, you get angry. If the OS keeps ignoring you, or gets slow, you get angry.
There are thousands of things you can do to improve an interface, but miss this stuff and you fail.
Re:I have an idea for the style guide (Score:5, Insightful)
I was (am?) the generation who learned to code in the mid-90s. I hate to sound lazy, but once we got over that hungarian nonsense, every team I've worked on just agreed (or had dictated) an autoformatter for our IDE and just made sure to run it before we committed. Hell one team had it setup as a pre-commit hook in SVN. It mooted many of the style arguments and let us focus on solving real problems.
Hell the more modern IDEs like Eclipse, IntelliJ, and VisualStudio even suggest variable names and hint for proper case. As programmers and software engineers should we not use software tools to do tedious and mundane work for us?
Re:I have an idea for the style guide (Score:4, Insightful)
Nowadays I think the reasons for hungarian have largely disappeared. Modern IDEs for Java or .NET provide enough assistance that you can find out the type of something by hovering over it. You'll get the type and any documentation. And ctrl clicking the type takes you to the definition. There is no need to decorate the type because it just adds noise. Personally I don't even like scoping which some Java devs seem to do with _ on the front of member variables because it usually confuses the IDE.
It may still have some use in JavaScript or Perl or other polymorphic environments where the editor / IDE and the runtime is pretty useless at assisting developers though it should probably be done in a limited way, e.g. s for string, n for number, a for array etc.
Art of programming (Score:5, Insightful)
However much like real artists in order to make a living they need to do a buch of commissioned work where you need to make what the boss wants and your personal style is limited. And as you get more artists on a project you need a style guide to make sure the project is consistent.
GNU projects often lose a good UI compared to their closed source counterpart because each artist is making their own statement in the program. I find that the GIMP does this. Now this isn't a flaw in the GNU but a good GNU project needs the same oversite and rules a good closed source solution needs, and often much earlier in the process because open source you get a lot of people doing a little bit of code, while closed source you get a few people doing the bulk.
Re:I have an idea for the style guide (Score:1, Insightful)
No we should not. Programmers and software engineers should only use Vi or Emacs (Notepad if you are forced to use Windows).
Hint: It's useful to justify your arguments, not just disagree with the last poster because it makes you feel elite.
If you're writing anything more taxing than a shell script in a text editor, not only are you incredibly unproductive, you're also probably in denial about many aspects of development because you believe you're 'better' than all the other 'lazy' developers.
IDEs are there to help make development faster and of a higher quality. Using bolt ons to help with testing, style and source control make the IDEs even more powerful. Look it up, you might learn something.
Re:Nobody is happy (Score:5, Insightful)
Because that way there's only one success, and many failures.
0(false) = success
1(true) = failure
2(true) = different failure
3(true) = yet another failure