Following UI Design Guidelines

It's worth researching the style guidelines for each platform. Much of the time, wxWidgets handles the differences, but there are some aspects that cannot be automated. For example, button layout differs between platforms. Apple is particularly strict about standard button ordering and spacing on Mac OS X. Here are just a few of the points to be aware of, both platform-specific rules and general observations. Also play with existing programs on different platforms for inspiration and to help you come up with an application design that is adaptable to your target platforms.

Standard Buttons

On Windows and Linux, groups of standard buttons can be centered or right justified, often in the order OK, Cancel, Help. On Mac OS X, however, the Help button (shown automatically as a question mark when using wxID_HELP) should be left justified, and the other standard buttons should be right justified with the default command as the right-most button: for example, ?, space, Cancel, OK.

Use the standard wxWidgets control identifiers whenever possible (such as wxID_OK, wxID_CLOSE, wxID_APPLY) because some ports (notably wxGTK) can map them to special buttons with appropriate graphics.

Refer to the section on "Platform-Adaptive Layouts" in Chapter 7, "Window Layout Using Sizers," for information about the wxStdDialogButton Sizer class, which can be used to position standard buttons appropriately on each platform.

Menus

A menu bar should have no "empty" menus. Careful attention should be paid to label capitalizationeach significant word normally has a capital first letterand providing mnemonics (such as &File) and shortcuts (such as Ctrl+O). Common commands should be supported where appropriate (such as Copy, Paste, Undo, and so on), and there should be neither a small number of very long menus, nor a very large number of smaller menus (nine or ten menus is probably the maximum reasonable number). Instead of supplying lots of separate menu items for different configuration operations, consider merging them into one command that invokes a tabbed dialog.

As with standard buttons, use standard identifiers where possible: in particular, use wxID_HELP, wxID_PREFERENCES, and wxID_HELP so that Mac OS X can move them to the application menu. You will need to design your menus so that removal of these items doesn't cause problems such as an empty Help menu or two consecutive separators.

Icons

Icons in your toolbar, frames, and other elements give a very strong impression of the quality of your application. Neglecting these can really let your application down. This is particularly true on Mac OS X, where there is a high standard of aesthetics. Consider having icons specially created, or a much cheaper alternative is to purchase packs of stock icons, perhaps getting the remaining non-standard icons designed for you in the same style. The investment will normally be well worth it, and your application will gain a stronger sense of identity. You can also find some icons on the webfor example, the L-GPL'ed Ximian collection at http://www.novell.com/coolsolutions/feature/1637.html.

Fonts and Colors

Don't be tempted to use a lot of different fonts and colors for your dialogs. As well as looking garish, using non-default fonts and colors makes it hard for wxWidgets to adapt to the current settings and themes to give a "native" look and feel. However, you can still allow the user to customize fonts for specific windows that present a lot of textual information, such as a report window. Refer to the platform guidelines on use of color. wxWidgets will do some adaptation here, but you may need to make further adaptations on custom windows that you implement.

Application Termination Behavior

On most platforms, document-based applications that aren't using MDI or a similar UI will show one frame per document. When the last frame closes, the application terminates. However, on Mac OS X, as we've mentioned in Chapter 19, "Working with Documents and Views," when there are no documents shown, the application should not terminate, and there should still be a menu bar from which the user can create or open documents or close the application. This can be implemented for wxWidgets applications by using an off-screen, hidden main frame, achieved with a small amount of code specific to this platform.

On embedded operating systems such as Pocket PC, applications stay in memory when their main window is closed, and the user does not usually have the opportunity to quit them. You will need to make a choice between conforming to the guidelines and permitting the user to quit the application to make room for others. On Pocket PC, wxWidgets sets the standard accelerator for quitting an application, Ctrl+Q, which sends a wxID_EXIT command event.

Further Reading

Listed below are useful guideline documents for the main platforms supported by wxWidgets, and books giving general advice on UI design.

• Apple Human Interface Guidelines: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html

• Key differences between Mac OS X and Windows UIs: http://developer.apple.com/ue/switch/windows.html

• Microsoft Official Guidelines for UI Developers: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnwue/html/welcome.asp

• GNOME Human Interface Guidelines: http://developer.gnome.org/projects/gup/hig

• GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers, by Jeff Johnson (Academic Press). ISBN 1-55860-582-7

• User Interface Design for Programmers, by Joel Spolsky (Apress). ISBN 1-893115-94-1

• Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design, by Larry L. Constantine and Lucy A.D. Lockwood (ACM Press). ISBN 0-201-92478-1