|
Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions | |
For keypad-based devices, all widgets that can accept focus should be laid out vertically (i.e. they should never be placed next to each other). Keypad navigation relies on the Up and Down keys to move focus between widgets, and the Left and Right keys are reserved for switching between tabs. Because of this, having two widgets that accept focus positioned side by side causes unintuitive navigation.
If the user presses the Left or Right key while in a tabbed window it should change the visible tab. To allow this, no widget may use the Left or Right keys when in navigation focus mode.
The number of tabs in a tab bar should be limited so that all of the tabs can fit horizontally with no scrolling.
Tabs are usually placed at the top of the screen. Other cases are supported, but not recommended (there are some drawbacks to using other configurations. For example, even if tabs are arranged vertically, left and right will still be used move between them).
A tab bar should only contain tabs of the same type (i.e. don't mix icon tabs with text tabs in the same tab bar). Recommended choices are:
For keypad-based devices, the list highlight when opening a list should be the first item (or the previously selected item when returning to a list). For touchscreen devices, the list highlight should be transient: it should appear when an item is pressed, and disappear once released.
The ordering of items in a menu should be based on the following ordering:
When the selection of a menu item leads to a new dialog:
Where an application is structured as a list of items and selecting an item shows its details, the menu for the list should not include any actions that are directly related to a single item. Actions that are applied to an individual item (and never to a list) should be placed in the menu that becomes available when the details of an item are shown. (Menu, Down-past-New, Select-Edit is just as many steps as Select-Item, Menu, Select-Edit).
When particular widgets are selected the softkey menu may change its option list. However, promoting this functionality is not recommended.
Menu options should follow all conventions found in the Naming conventions . An acronym or abbreviation for a menu item should only be used if the label doesn't fit on the screen OR if an acronym or abbreviation already exists for the current label (as this promotes consistency in the use of text labels).
Some dialogs consist of a list of items, only one of which the user needs to select in order to complete an operation. In a small number of cases the user may wish to do more with the item, such as edit it via the menu.
Such list dialogs are Menu-like Dialogs, and should behave like menus:
To assist in creating Menu-like dialogs use the function
QtopiaApplication::setMenuLike();
which maps the soft keys and menu correctly for the dialog.
If the dialog has a menu, consider having Activate, or Select in the menu, but ensure this command does not close the dialog.
Examples include: Profile selection, Speed dial action selection.
A dialog's title should describe the process that is currently taking place in the dialog. For example, Editing Event, Creating Event. A dialog title should not have its text appended with "...".
Dialogs are either shown full screen or at the bottom of the screen, depending upon the height of the dialog's sizeHint(). A dialog with a size hint greater than three fifths of the screen height will be shown fullscreen, otherwise it will be positioned at the bottom of the screen at its preferred height. Dialogs always use the full width of the screen.
Message dialogs that allow a positive or negative response should be phrased such that the user can answer Yes or No, rather than OK or Cancel.
Informative Message dialogs should only allow the Back softkey menu bar option.
Message boxes should allow no more than two options. Three or more options are difficult for the user to process. If it is absolutely necessary to provide three or more options a list of options should be provided via a Menu-like Dialog.
Existing Qt widgets should always be used where possible. If a custom widget must be used, make sure that such a widget does not already exist.
| Copyright © 2009 Trolltech | Trademarks | Qt Extended 4.4.3 |