Creating logical item groups

You should never have a grouping of more than five items without a separator, unless there's a very strong logical reason to do so—such as a history list, or a list of plugins. Groups of more than five items tend to be very difficult for people to process. To have a larger group, the items would need to be very strongly linked together and have a reason why the user would expect the list to be longer than five items.

Adhere to standards when ordering menus

You should always stick to the accepted standard for menu ordering. The leftmost menu is FILE, and it contains new, open, save, print, and quit functionality, usually in that order, although other functionality is often added between printing and quitting. Nearly every application will use that functionality. The next menu is EDIT, and it contains undo, cut, copy, paste, and usually find, depending on what is appropriate for your application. The HELP menu is always rightmost, and a windows menu is frequently next to that. In between, you are generally on your own.

Provide easy access to commonly-used items

The user will always be able to access items that are higher in the menu more quickly than those at the bottom. The implication is that more commonly used options should be at the top. An exception is that most studies show that it's faster to hit the second item than the first.

Use informative menu names

Remember that the width of the menu target on the menu bar is proportional to the length of the name, and the width of the menu when it opens is proportional to the longest name of the items within it. Try to avoid giving top-level menus names shorter than four letters. Except for common names, we recommend that they be longer whenever possible, without being unclear. Don't be afraid to give a menu item longer text, although at about the 30-40 character range they become hard to read.

Remember the ellipsis when an item leads to a dialog

Any menu item that results in a dialog box being displayed should have a label that ends in an ellipsis (...).

Adhere to standard keyboard shortcuts

For keyboard shortcuts, always use the accepted standards for common functionality, as displayed in table 10.8.

There is no commonly accepted shortcut for Redo, you'll sometimes see Ctrl-y, Alt-z, or another combination. If you are providing many keyboard shortcuts beyond the common set, it's recommended that you provide the user with an option to change them. Keyboard shortcuts are most valuable in an application where the user is doing a lot of typing, such as a text editor. They are less valuable in an application where the user is doing a lot of mouse work.

Reflect the active toggle state

When creating a toggle menu item, there are a couple of things to be careful about. First, remember that an unchecked checkbox menu item looks identical to a normal menu item. If the item text says something like fancy mode on, the user may not know that selecting the menu item actually changes fancy mode. Another concern is having the item text reflect the state that is not currently active, rather than the one that is. This happens when you use the

Table 10.8 Common keyboard shortcuts

Shortcut

Function

Ctrl-a

Select all

Ctrl-c

Copy

Ctrl-f

Find

Ctrl-g

Find Again

Ctrl-n

New

Ctrl-o

Open

Ctrl-p

Print

Ctrl-q

Quit

Ctrl-s

Save

Ctrl-v

Paste

Ctrl-w

Close

Ctrl-x

Cut

Ctrl-z

Undo

menu text to say what the selection does, for example saying Turn fancy mode off if fancy mode is on. There is no statement in the menu indicating what the state of fancy mode actually is, which can be confusing. To avoid this problem, it's a good idea to have a custom bitmap for unchecked menus (on platforms which allow this) to give the user a visual cue that the menu is a toggle. If you can't do that, text like toggle fancy mode or switch fancy mode (now on) can be clearer.

Use nesting cautiously

Nested hierarchical menus can be awkward to navigate, since they force the user to tunnel the mouse pointer through a narrow alley, then swerve at a 90-degree angle. You definitely want to avoid having more than one layer of nesting. If you are trying to map something that is genuinely tree-like, such as a directory tree, you may want to consider a separate dialog box with a tree control. Also, if you think your user population is going to have any kind of accessibility or coordination issues, try to avoid nested menus.

Avoid using font or color

Can you remember any application ever making use of font or color in its menu items? Neither do we (with the exception of menus whose purpose is to select a font or color). Definitely for use only in very rare cases.

10.5 Summary

■ Menus are the most commonly used mechanism for allowing the user to trigger commands in a GUI application. Menus in wxPython are created using three primary classes, wx.MenuBar, which represents the menu bar and contains menus, represented by wx.Menu. The menu is made up of menu items, represented by wx.MenuItem. To build a menu bar, the menu bar item is created and attached to a frame. Each individual menu is created, and menu items are added to it. Then the menu is added to the menu bar. Items can be added at any place in the menu. An item can also be a menu separator, rather than a normal menu item. Menu item objects can be created explicitly or implicitly created when the item is added to the parent menu.

■ Selecting a menu triggers a command event with the type wx.evt_menu. Menu events are bound via the containing frame, not via the menu item, menu, or menu bar. This allows toolbar buttons to trigger the same wx.EVT_MENU event as a menu item. If you have multiple menu items with consecutive identifiers that all have the same handler, they can be bound in one call using the event type wx.EVT_MENU_RANGE.

■ Menu items can be found by ID or by label from either the containing menu or the containing menu bar. A menu item can also be enabled or disabled from its containing menu or menu bar.

■ A menu can be attached to another menu rather than the menu bar, making it a nested submenu. There are specific methods of wx.Menu which allow you to add a submenu in the same way that a typical menu item is added.

■ Menus can be associated with keys in two ways. A mnemonic is the keyboard menu navigation triggered when the user presses the ALT key. When in mnemonic mode, the key presses trigger the appropriate menu or menu item. Mnemonics are created by inserting an ampersand before the appropriate character when creating the menu. A true accelerator key can be created to bind a key combination to a menu item. This information can also be included when the menu item is created. The decorators for keyboard shortcuts are ignored for the purposes of finding a menu item by name.

■ A menu item can have a toggle state. It can be a checkbox menu item, which switches from a checked to unchecked state and vice-versa when selected. The item can also be a radio menu item, in which case it is part of a group, only one of which can be in the checked state at a time. The checked state of a menu item can also be queried or changed via the menu bar or containing menu.

■ A menu can be created to pop up on a click inside a wxPython widget, rather than pulling down from the menu bar. This is done by trapping the event type wx.EVT_CONTEXT_MENU, and using the method PopupMenu() to display the pop-up. Menu item events within the pop-up are handled normally.

■ You can create a custom bitmap for a menu item, and under Windows operating systems, you can change the color and font of a menu item. Common sense should dictate the use of this feature.

Was this article helpful?

0 0

Post a comment