the windows style guide

I am a UI programmer.  I work on the BrowserUI team.  Of course, very little of my time is spent actually making UI--the buttons and toolbars and such.  Adding a button takes a few minutes out of my week.  Writing the code to implement whatever the button does takes most of my time.  When I do write new UI, though, such as dialogs, etc, you can be sure I have a copy of Microsoft Windows User Experience open to page 451.  In the class I have been taking at the UW I have had to install a lot of free applications to do various mathy things, and the horridness of some of the UI has really made me sad.  I am not going to name names; all I ask is, please, put some thought into your UI design! 

The following is a list of things I have seen these last few months that really bothered me:

• If you have an edit box to enter values, make it usable--do not require me to move a slider or use up/down arrows.
• Do not put up modal dialogs that require information that I may want to cut and paste from the parent of the modal dialog.
• Please make all of your controls keyboard accessible and please bother to check the tab order makes some sort of sense.
• Do not allow me to enter values in two different controls that conflict.  When informing me of the conflict, please describe it clearly.
• If you know what a given setting needs to be, just do it.
• Please use color schemes that are reasonable: black text on white backgrounds; good.  Black text on green backgrounds; bad.

All of this and more can be found in the book; ranting about bad UI is not novel.  Even if you do not program for Windows, much of the content in the book is useful in making your app usable and making it look professional.

I am sure we can find plenty of Microsoft UI that violates guidelines in the book, with and without excuses for doing so.  I am embarrassed to admit I checked in a truly terrible dialog as an intern, but I promise I have learned from the mistakes of my youth.  I have seen the light; I have become a member of the Pixels-Matter school.

I just needed to get that off my chest.  Thank you for indulging me.

Comments

• Anonymous
  December 07, 2004
  Amen! Screwy tab order is a peeve of mine, since I'm a keyboard jockey. Another one is apps that forget mnemonics for all their controls and menu items (coughVC7cough).

• Anonymous
  December 07, 2004
  One useful test is to go back to a previous design and ask "Am I still happy with this?"
  
  Here's one of mine that falls into that category:
  
  http://www.zeepe.com/zeepesupport/caps/startup.jpg
  
  Some ideas here for the Office team? :-)

• Anonymous
  December 08, 2004
  I agree 100% on the tab order... a bad tab order is just horribly lazy and inexcusable. Maybe it's because I'm a programmer, but I think there are VERY few valid reasons to stray from the standard UI design for a given platform. I think what bugs me most about Microsoft UI is how often the "standard" seems to change. I guess not from a usability standpoint as much as design... look at how Office and VS have changed over the last few revisions. Can you convince anyone there on those teams to pick a UI and stick with it for at least two major versions? IE hasn't change at all in the last 2 or 3 year... oh, wait... :-)

• Anonymous
  December 08, 2004
  We should be venting at you, not you at us. I'll leave that for another day. But still an IE programmer complaining about poor usability ...
  
  For those of us with MSDN libraries (pages aren't numbered), what is p461.

• Anonymous
  December 09, 2004
  The comment has been removed

• Anonymous
  December 10, 2004
  The Windows User Experience design guidelines can be found here:
  http://msdn.microsoft.com/library/en-us/dnwue/html/fore.asp
  
  The layout of dialogs, specifically, is here:
  http://msdn.microsoft.com/library/en-us/dnwue/html/ch14e.asp
  
  Sean

• Anonymous
  December 13, 2004
  Ahh the useless section of the current guidelines where pixels are unknown and one HAS to supply dynamic dialog resizing code to make it work. For me it's even worse as 1/ I do it at design time and 2/ I have to convert dialog units to pixels (and without knowing the conversion factor as I don't know the font), then convert pixels to logical twips. Then I need to change every element in a VB dialog to the correct size (VB does not default to proper sizes and never has - everything is 50% bigger than it should be).
  
  I take screenshots of shell dialogs then size my dialogs to the screenshot. I look at every possible way to write as a no UI application. Why does sizing a dialog take 10 hours while the code behoind it takes 10 minutes (rhetorical question).
  
  I don't care if my code works in the future if it doesn't work today.
  
  I give due consideration to some of the UI issues in IE and list them at a later date - though I have told you them before.
  
  My definition of componentised software is software that as a whole doesn't fit.

• Anonymous
  December 13, 2004
  The comment has been removed

• Anonymous
  December 17, 2004
  The comment has been removed

• Anonymous
  December 18, 2004
  This may seem trivial, but there is a common stylistic element that bothers me - having a "Cancel" button when what you really want is a "Go Back" or a "Close Window" button. Unless by hitting "Cancel," you are actually cancelling something, I don't think that it should be labeled "Cancel."
  
  However, I don't expect to get much support on this.

• Anonymous
  December 21, 2004
  http://www.asktog.com/Bughouse/10MostPersistentBugs.html
  
  See Tog's point 3 and my first point. Tog was the Mac UI designer.

• Anonymous
  May 25, 2008
  PingBack from http://aaliyah.freereportcontent.info/jeffschuette.html

• Anonymous
  June 13, 2009
  PingBack from http://firepitidea.info/story.php?id=214

• Anonymous
  June 18, 2009
  PingBack from http://barstoolsite.info/story.php?id=1271