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 (17)

  1. Mike Dunn says:

    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 (*cough*VC7*cough*).

  2. Jerry Mead says:

    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:

    Some ideas here for the Office team? 🙂

  3. 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… 🙂

  4. David Candy says:

    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.

  5. jeffdav says:


    I feel your pain. By all means, vent. The fact that I work at Microsoft is independent from whether or not I am frustrated by bad design.

    Page 451 is the beginning of the discussion of the correct way to layout dialogs. I am not sure if there is on-line versions of this or not.

    One does not need the Windows style guide. I am sure style guides exist for various Unix and Linux window managers, as well as MacOS. I suspect that many of them are the same. I am merely suggesting that all UI developers should read some literature on the topic, because it is obvious that many do not.

  6. The Windows User Experience design guidelines can be found here:

    The layout of dialogs, specifically, is here:


  7. David Candy says:

    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.

  8. David Candy says:

    In Winword 2, 6, and 7 (don’t remember about 1) hovering over a toolbar button or menu item will

    a/ tell you what the command does

    b/ if greyed will tell you why it’s greyed

    EG If I have no text selected and try to Edit – Copy the status bar will say "This command is unavailable because no text is selected". This is the greatest UI feature ever introduced (including for word programmers as many commands are unavailable in this or that mode because some UI designer didn’t think it made sense – of course there is nothing about this in the programming docs – Word has lots of modes). From Word 8 on (word 97) this is only available from context specific help (Shift + F1, click Edit, click Copy). It’s not in IE at all.

    I think

    1/ IE and OE and Explorer should also do this

    2/ It should be a windows logo requirement and incorporated into the WUE book (ok not for p451 though).

    It’s not my fault that the office team hate Windows and refuse to use system menus, toolbars, ststusbars, controls, etc.

    The second thing is selecting things in IE

    1/ There is no way to select with the keyboard (Shift + Arrow)

    2/ There is no way to select exactly what one wants with a mouse (as opposed to word select which is what Word calls it). Word allows Alt + Drag (while selecting) to allow absolute selecting overriding the default word select (which can be globably turned on/off as well).

    And as I said before

    After swearing at IE again, as I do all day, fix the windowing code.

    3. Blank windows. This is where the frame is drawn but the object in the frame is slow to initialise. It appears as if an IE window is not on top (which it is but invisable, except for the frame, for a while) as one can see the window beneath it in the Z-Order.

    4. Windows taking focus. EG open, then minimise 15 google windows as each page finishes loading it comes to the top. I use google’s cache to read MS’s web site.

    5. Consistant focus. EG opening google 1/2 the time the text box has focus and the other 1/2 it doesn’t, even though the text cursor is blinking saying it has. This could be related to closing minimised windows.

    And my pet peeve

    6. Very few pages finish loading. I used to only see this on ASP servers but now see it on all sorts of servers. I suspect that this is due to the large number of files that make up the average web page. One file times out (or something) and IE waits forever. If there was an http loging facility like OE has for NNTP/POP/SMTP I would be surer. Netcap is fairly useless as the viewer is only in NT4 SBS or SMS servers or something. If this is the case then IE needs to rerequest the file. There is no 5 minute timeout either. Related to this stalled page is some that one cannot stop the download (that is stalled anyway) so it doesn’t go into the cache (and I need this for TV guides).

    Maybe MS has an http logger available?

  9. Peter Torr says:

    Swapping OK and Cancel buttons really sucks to.

    The OK is on the LEFT and the Cancel is on the RIGHT.

    Is it that hard for people to follow? :-/

    Although I have thought for a long time that there should be a MessageBoxEx2Super() API that lets you specify:

    1) Custom button captions ("Save" and "Don’t Save" versus "OK" and "Cancel")

    2) A "Don’t show this again" checkbox (if it’s checked, a bit is flipped in the return value; app is responsible for persisting the answer)

    Writing a custom MessageBox is too much work, so you get really badly worded MessageBoxes (so as to give a Yes/No/Cancel answer) and no "don’t nag me again" support in too many apps (including our own).

  10. AfroBlanca says:

    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.

  11. David Candy says:

    See Tog’s point 3 and my first point. Tog was the Mac UI designer.