Qtopia Home - Classes - Hierachy - Annotated - Functions - Qt Embedded

Qtopia Phone Style Guide

Contents

• Introduction
• Application design
  • Document based applications
    • List of lists
    • List of items
    • Viewing a single item
    • Editing a single item
    • Deleting a single item
    • Navigational flow
    • Form layout
  • Task based applications
• Standard widgets
  • Labels
  • Buttons
  • Input fields
    • Text fields
    • Number fields
  • Tabs
  • Lists
  • Menus
    • Menu names
    • Menu-like dialogs
  • Dialogs
  • Custom widgets
• Interprocess actions
• Application naming
• Naming conventions
  • Abbreviations
  • Acronyms
  • Using the "..." label
    • Examples of when to use "..."
    • Examples of when not to use "..."
  • Currently used label names
• Qtopia Phone Keys
• Standard Icons and Usage
• Qtopia desktop.
• F.A.Q

Introduction

This document describes the rules to be followed when designing an application for the Qtopia Phone Edition. The focus is on consistency, think very carefully before departing from the preferred style.

Application design

There are two basic styles of application:

• Document based - Document based applications are used to view and possibly edit a specific document type. Applications such as the "Contacts" or "Tasks" are considered to be document based applications.

• Task based - A task based application allows a specific task to be performed such as view the time in the case of the Clock application.

Document based applications

The main window of a document based application will present a list of items, or in some cases a list of sub-lists.

Note: The documents are not necessarily individual files. The entries in an address book for instance may be considered documents.

Document based applications should follow a standard navigational flow:

• List of Lists (if necessary).
• List of Items.
• View of a Single Item.
• Edit Single Item.
• Deleting a Single Item.

List of lists

This is rarely needed. It is used when there are a number of lists that behave differently or have some incompatible properties. An example application is the Qtopia Messaging application. This application shows folders that have specific functions. The Outbox, Trash, Inbox, etc. all have particular properties that preclude grouping their items into one list.

The context menu must contain entries that act on all of the lists, and optionally a New entry.

Highlighting a list and pressing Select displays the List of Items. Pressing Back or Done must close the application.

List of items

This is the screen most applications will display when started via the launcher. It lists the documents that the application may view and/or edit. It is recommended that the menu contains a View Category... option to display only the items in the selected category.

The context menu should contain entries that act on all of the items, and optionally a New entry.

Highlighting an item and pressing Select should display a more detailed view of the highlighted item. Pressing Back or Done must return to the previous list of items or lists (if present), otherwise close the application.

When an item in the list is used to group or store information; selecting that list item should present the information about that item.

Viewing a single item

This screen displays a single item, and may allow navigation and activation of data within the view.

The context menu must contain entries that act only on the viewed item. If the application can edit the document, it should contain an Edit menu entry.

If the view contains elements that can be activated, then the Select key must activate the highlighted element. Pressing Back or Done must return to the list of items.

Editing a single item

This screen allows a single item to be modified. Edit screens must be able to be canceled via the Cancel option found in the context menu.

Note: When a user selects the Done or Back option and nothing has been altered the button acts as the Cancel option otherwise the item will be stored. More information on this can be found in the ... section.

When creating or editing an item, the first tab must be displayed with the first input widget focused.

The context menu must be limited to those entries that act on the item being edited. Phones that do not offer a No button may automatically have a Cancel entry added to the end of the menu.

Pressing Back or Done must accept the changes and return to the view. Pressing Cancel must discard the changes and return to the view.

Deleting a single item

An application that can create or edit an item should provide the ability to remove an item of the same type.

Items are only able to be deleted when viewing there details hence only one at a time.

Navigational flow

In order to maintain a consistent navigational flow, the following rules must be adhered to:

• When moving forward (e.g. by pressing Select or selecting Edit from the menu), the displayed screen must be in its initial state. For example, in a list of items the top-most item must be highlighted.
• When moving back (e.g. by pressing Back or Done), the previously viewed screen must be displayed in the same state that it was in when left. For example, if item D was highlighted then viewed, pressing Back in the view must return to the list with item D still highlighted.
• The left and right buttons are used for moving between tabs in a tabbed dialog although in some cases they may be used to select widgets that are horizontally aligned.
• The up and down buttons are used for moving between fields in a dialog.
• To edit a field you first have to focus it using the up/down buttons then select it by pressing select.
• The select button is also used to move through tabs when the tab has focus.

Note: In case there is no tabbed dialog it is very tempting to give the left and right buttons the same functionality as up and down. We have explicitly chosen NOT to do so in order to keep the user interface as consistent as possible, i.e. maintaining one way of doing things.

Form layout

An input form should provide a simple and familiar way for the user to input data. The basic layout of an input form is a 2 columned table: the first column provides a label for the field found in the same row; the second is the input field.

The basic layout of an input form should remain consistent between all applications. It is also recommended that the same input form is used when creating and editing an item.

Task based applications

These applications allow a specific task to be performed. They do not operate on documents, though they may generate documents. Examples of task based applications are Clock and Calculator.

Standard widgets

Labels

The rules listed below should be followed when creating a label:

• No labels should have ":" appended.
• There should never be a blank label listed in or for any widget.
• All labels should conform to the Naming conventions.
• Text labels should be left aligned (non-semitic languages).

Please utilize the Currently used label names table to keep labels consistent across applications.

Buttons

Button labels should follow the same labeling scheme described in Labels section.

For some applications it is desirable to associate keypad keys to buttons displayed in the applications (as is done in the the stopwatch/clock application) this is not recommended but if it must be done the label should include the associated keys label.

Input fields

The Copy and Paste options should be available in all text input fields unless there is sufficient reason not to have these options listed.

When the using the multitap input method pressing the 1 button should display a number of extended characters that are specific to the currently selected dialog.

Note: When using the singletap input method and the field should always start with a capital letter, the first character should automatically be capitalized.

Text fields

Input fields should only remember the input type for that specific field (not all widgets of that type).

By default singletap should be enabled in any text input field.

Number fields

No characters other than numbers should be allowed in this field. Letters should be appended as labels or combo-boxes where appropriate. For example, "10 mins" should only display "10" and have mins appended as a label.

Tabs

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.

Lists

A list may be displayed as an icon while it is not selected but when the list is opened the icon and label should be displayed with the icon displayed.

The default focus when opening a list should be on the item that the list was set to prior to opening.

If the list allows the user to select a blank item then the blank item should be listed as blank ie. not use a label such as "blank" or . List items that display additional dialogs when they are selected should simple list a "..." option.

Menus

The ordering of items in a menu must be based of the following ordering:

• New
• Edit
• Modify commands, e.g. Crop
• Delete
• Action commands, e.g. Beam, Duplicate, Copy, Paste
• View commands, e.g. Today, View Category...
• Options commands, e.g. Settings
• (separator)
• Help (added by system)
• Cancel

When the selection of a menu item leads to a new dialog, the menu item label should only be suffixed with "..." if the command is being further refined. In other words, the "..." extension should only be placed on the end of menu names when a selection of items is going to be offered or additional commands have to be specified. No space should be left between the first '.' and the last character of the menu name. Please refer to Using the "..." label for a full explanation.

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".

• Menu options should be hidden when unavailable.
• A menu should have the top-most item selected by default.
• A menu separator should be used to group options that perform associated functionality such as New, Edit and Delete.
• Menus with predefined names such as Cancel should use the appropriate icon.

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

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).

Menu-like dialogs

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:

• Highlighting an item should have no long-term effect.
• Selecting an item should close the window and return to the previous view (even if that means closing the application).
• The ContextBar icon for Key_Back should be Cancel, not the usual Back.

To assist in creating Menu-like dialogs you can call the function

QPEApplication::setMenuLike();

which will map the context bar and menu correctly for the dialog.

If the dialog has a menu, consider having 'Activate', or 'Select' in the menu, but make sure that this command does not close the dialog.

Examples: Profile selection, Speed dial action selection.

Dialogs

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.

Custom widgets

Well defined widgets (ie. those defined in qt) should always be used where possible. If a custom widget must be used, make sure that such a widget doesn't already exist. Ie. Time input widgets.

Interprocess actions

When an application is activated via a QCop message in order to view a document, pressing Back or Done must close the application. For example viewing a picture from the Documents launcher will open the picture in the Pictures application, Closing the image viewed in the application will close the application and return to the Documents launcher.

Application naming

Application names should be based on established application names used in the current phone market. They should be nouns and obvious to a user from any background.

Note: An application's title should be the same as its launcher name.

Naming conventions

All words should start with a capital letter with the exception of words that are usually excluded from acronyms such as "of", "and", or "to". These extremely common words are referred to as stop words.

Once a certain name is used for a specific item it should be re-used in each and every application. For example: if Contacts and Calendar both have a "company" info field they should use the same label. This means both applications use either "Company", "Cmpny", or "Comp.". Please see the used label names table for reference.

Abbreviations

The rules listed below should be followed when using abbreviations:

• Abbreviations are meant to be self explanatory.
• An abbreviation point should occur at the end of a word. For example: etc.
• Abbreviations consisting of initial letters are written as un-spaced and undivided sequences with abbreviation points after each letter. For example: e.g.
• Abbreviations should not consist of any characters except a-z A-Z.

NOTE: No abbreviation point is required if the last letter of the word is displayed such as "cmpny".

Acronyms

Acronyms basically follow the same set of rules as those found in the abbreviations section. Always check existing acronyms before creating a new one.

Using the "..." label

The following rules define the use of the ... in association with menu items.

• if the command has to be refined before a user can initiate an action then yes, use ...
• if the command does not need to be refined before a user can initiate an action then do not use ...
• if in doubt, do not apply ... to the menu

Examples of when to use "..."

Use ... only when the menu is followed by another dialog that is a direct and integral continuation of the command.

• Send All... is appropriate since the next dialog requires the user to select one of Email/Infrared/SMS before anything is sent.
• View Category... is appropriate since the next dialog requires the user to select which category they want to view.

Examples of when not to use "..."

Do not use "..." when the menu is followed by another dialog that is related to but not a continuation of the command.

• Edit (without ...) is appropriate if the user is immediately shown the entire record and is free to edit any aspect of it.
• Delete (without ...) is appropriate since the user does not have to refine the delete command in order for it to work. A please confirm dialog does not specify additional parameters; it is associated with the command but does not refine its functionality.
• Settings (without ...) should be used when a user is immediately given access to all the features that can be set, such as in the Calendar application.

Currently used label names

Qtopia Phone Keys

Qtopia requires the following keys:

Qtopia supports the following additional keys:

* on some phones, two keys represent both vertical and horizontal directions of suggested motion. Sometimes these are a Left/Up button and a Right/Down button, at other times they are a Left/Down button and a Right/Up button.

Standard Icons and Usage

Icon	Component	Filename	Description of Use
	Context Bar	back.png	Done: Finished using the current screen and wish to return to previous window.
	Context Bar	backspace.png	Delete text: Deletes (backspace) 1 character.
	Context Bar	cancel.png	Cancel: Removes all changes performed on the current item (transaction).
	Context Bar	ok.png	Accept: Accepts and disengages the current information/data in the currently selected widget.
	Context Bar	options.png	Open/Close Menu: Displays the current window's context menu.
	Context Bar	select.png	Engage/Select: Selects the current item, widget or grouping.
	Context Bar	view.png	More Information: Selects and displays information about the currently focused item.
	Context Menu	beam.png	Beam: Sends the currently viewed item via IR.
	Context Menu	edit.png	Edit: Edits the currently viewed item.
	Context Menu	find.png	Find/Search: Locates an item.
	Context Menu	help_icon.png	Help: Displays the help documentation for the current window.
	Context Menu	new.png	New: Creates a new item.
	Context Menu	trash.png	Delete item: Deletes the currently viewed item.

Qtopia desktop.

Qtopia desktop should follow the same standards adhered in Qtopia but should also follow close to the standards established by desktop user interfaces.

• Labels can be expanded to use there full name instead of an acronym or abbreviation.

Note: Creation of events, tasks and contacts should follow the creation rules specified in Qtopia ie. if the user doesn't enter sufficient information the item is not created.

F.A.Q

When should I display a confirmation dialog?:

What size should I be setting my dialog?:

Should widgets be hidden or disabled?:

Should I be adding a "Properties" option to my application?: