What's the big deal? After all, if everything else in your program is correct, having an ellipsis in the About box menu command isn't going to make your program difficult to use, is it? While that is certainly a valid conclusion, the premise is questionable. If you don't know the standards, what are the chances that everything else in your program is going to be correct? Bad user interfaces are usually not bad because they have one or two glaring problems. They're bad because they have dozens of small mistakes that can contribute to or directly result in the following problems:
- Inconsistency with other Windows programs and with the user's expectations
- Nonstandard mouse and keyboard input
- Nonstandard windows or dialog boxes that require nonstandard responses from the user
- Nonstandard controls or standard controls that behave in nonstandard ways
- Poor integration with the Windows environment
- Confusing and hard-to-understand error messages
- Inadequate accessibility
- Inadequate user assistance
Helping you make sure that your program conforms to what the user expects is exactly what the standards are for. Complying with the standards allows you to create programs that the user already knows how to use. For example, if you use a standard list box in a standard way, there's no need to document how to use it. And best of all, you don't have to do any of the really hard work—all of the design work and user testing has already been done for you. When you create programs that don't conform to the standards, you're pretty much on your own.
Conforming to the standards makes your job easier, not harder.
I appreciate the fact that Designing for the User Experience is a fairly large book and can be difficult to read at times. However, it is effective as a reference and you really don't have to memorize it. Just have a copy within easy reach, know what's in it, know what you already know, know what you're less familiar with, and know when you need to refer to it. That's all!
When to Violate the Standards
While the guidelines specifically state that compliance is optional, I believe they say this just to be nice. You should conform to the standards unless you have an amazingly good reason to break them. Here are some good reasons for not conforming to the standards:
- You are trying to advance state-of-the-art user interface design, and you really know what you are doing. In this case, you should also have a significant budget for user testing.
- You are creating a radically new kind of program.
- Your program has extraordinary requirements.
- You are creating a game or multimedia program that is designed primarily to entertain, and you feel that conforming to the standard appearance is too boring.
- You have decided that achieving another goal is more important, and you are making a well-thought-out trade-off.
- You made an honest mistake and will fix the problem as soon as possible.
I consider the following to be really bad reasons for not conforming to the standards:
- You don't know what the standards are.
- You prefer to make up your own standards as you go.
- You find conforming to the standards too much trouble.
- You found a really cool ActiveX control on the Internet and want to use it in your program somehow, even though it doesn't conform to the standards.
People often note that Microsoft itself breaks the standards all the time. However, note that they do this to advance the state-of-the-art of Windows user interface design. Also note that they have a substantial budget to design and test new user interface designs. Microsoft typically unveils these new designs with their Office and Internet Explorer products and eventually incorporates them into the standards and other products. If you want to follow Microsoft's latest user interface designs and you have a good reason to, that is fine by me. Typically I plan to adopt them too, but I'm usually not in a big hurry to do so. I prefer to give myself, my users, and my tools (especially MFC) a chance to catch up.
Violate the standards to go forward, not backward.