| Home · All Classes · Annotated · Functions |
The rules listed below should be followed when creating a label:
note:Please utilize the Currently used label names table to keep labels consistent across applications.
Note: When using the singletap input method and the field should always start with a capital letter, the first character should automatically be capitalized.
No characters other than numbers are allowed in this field. Letters are appended as labels or combo-boxes where appropriate. For example, "10 mins" should only display "10" and have mins appended as a label.
Tab widgets should be able to gain focus from the user pressing either of the up or down directional pad buttons. When a user has the tab selected pressing the Select button should allow the them to proceed to the next available tab. Pressing the up or down directional pad buttons again will return the focus to the dialog, selecting the first or last element in the dialog.
If the user presses either of the left or right directional pad buttons while in a tabbed dialog, the user should be able to change the tab with the focus shifting to the tab's label/icon.
The ordering of items in a menu must be based of the following ordering:
When the selection of a menu item leads to a new dialog:
: {Note:} Application menu labels should not be appended with the type of item on which they are performing the action. For example, only Edit is required on the menu label, not Edit Event.
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 context menu may change its option list. Promoting this functionality is not recommended.
Menu names 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 (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 context bar 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 Dialogs 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 "...".
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 Done context bar option.
Well-defined widgets, that is, those defined in Qt, should always be used where possible. If a custom widget must be used, make sure that such a widget does not already exist.
| Copyright © 2006 Trolltech | Trademarks | Qtopia 4.1.7 |