![[Index]](../../../../_stock/btn_index_wt.gif){kind=small}
![[Spacer]](../../../../_stock/btn_spacer.gif){kind=small}
![[Previous]](../../../../_stock/btn_prev_wt.gif){kind=small}
![[Next]](../../../../_stock/btn_next_wt.gif){kind=small}
|
|
|
|
|
|
Welcome to the Style Guide for UIQ 3. For many, the Style Guide is the jumping off point for getting to know UIQ 3 better. The Style Guide provides developers and interaction designers with guidelines on how to design application User Interfaces for the UIQ platform.
The Style Guide gives a good overview of the organization and function of key UIQ components.
The release of UIQ 3 means a great step forward for the UIQ User Interface.
UIQ 3 can be used for mobile phones that have any one of a variety of form factors. The phone can be pen-based or softkey, portrait or landscape, and, this is provided on just one codeline. For developers this means that applications can be written once and used directly on any UIQ 3 device regardless of form factor. UIQ 3 takes care of rearranging the layout and adapting the application to the mobile phone’s interaction style.
UIQ 3.1 introduces another level of flexibility by providing a variant of the UI Configuration Softkey UI. The way commands are assigned to softkeys and hardware keys in the Softkey variant introduced in UIQ 3.1 is different from the Softkey style UI Configuration in 3.0. The key set up is also different; the most obvious change is the removal of the Cancel key. UIQ has named the different variants to assign commands for the Softkey style UI configuration “Three Softkeys (3SK)”, when using 3.1, and “Three Softkeys and Back key (3SK&B)” when using 3.0. The abbreviations, 3SK and 3SK&B, will be used for the most part in this document. As a rule application developers and designers generally don’t have to pay attention to which variant of Softkey style that is in use, it’s taken care by the system.
Pictures used in the Style guide are 3SK specific if nothing else is mentioned.
|
|
|
The most obvious difference between the two available Softkey style variants is that the new Softkey style variant, 3SK, does not have a Cancel hardware key, instead the Right softkey is typically used to cancel and go back. The Left softkey is used to select positive commands like Done/Save, or when multiple actions are available, to open a menu. As with the Softkey style introduced in UIQ 3.0, the Action key is generally used to select the most important command, typically an action related to an item with focus.
There are also a couple of other differences between the Softkey style variants. The bullets below describe where 3SK differs from 3SK&B:
|
The Action key label (Center softkey) duplicates the Left softkey in case only two actions are available; meaning also the Action key is used to select a positive command. An icon is displayed on the Action key (Center softkey) when this occurs.
The Clear key which is used to delete text in text input mode can also be used to Cancel and go back when navigating between and within applications in non-text input mode.
The command on the Action key label (Center softkey) is also available as the first item in the menu when available.
As a rule application developers and UI designers generally don’t have to pay attention to which variant of Softkey style that is used by a specific handset, the system makes sure that the behavior described above is applied automatically as long as the application manages its commands in a correct way. This is done by assigning commands to different types.
|
|
Whichever UI configuration is used, the basic screen layout is the same. The screen is divided into four areas. One area, the status bar area, is used by the system and is therefore not available for application developers. The other three areas are used by the application. Two of these areas, the title area and the softkey label area, are controlled by the system but are used by the active application. The fourth area, the application space, covers most of the screen and is controlled by the application.
These four areas have the same function independent of the UI configuration. However, to simplify use of the phone, the areas are placed in different positions on the screen.
|
Note: Landscape mode uses the same components as Portrait mode but they can be positioned in a different way. The placement of the Softkey bar can be to the left, the right or at the bottom and is all dependent on what is supported by the device in use.
|
|
|
It is possible for an application to remove screen areas. Full screen is achieved when all screen areas except the application space have been removed. The Softkey bar should normally be left on the screen in Softkey style.
Applications that have support for full screen should have a menu command called “Full screen” located among the last commands in the menu and separated from the other commands with a divider.
The application can add a user setting where the user can select whether a specific view is to be displayed in full screen or not.
Applications displayed in full screen should not use tabs, even if the application makes use of tabs otherwise.
The Cancel/Back command takes the user back in the navigation hierarchy regardless if full screen is used or not, that is, full screen is not a state in the navigation model. When the view is entered again, the view should normally not be displayed in full screen, unless a setting has been made to display the view in full screen.
If the user leaves an application via the Application Launcher, the view state will be kept. This means that if a view is displayed in full screen when the user navigates away via the application launcher or via a DNL, the view is displayed in full screen when the user returns to the application.
Dialogs are not displayed in full screen. A dialog that is displayed over a full-screen view, in landscape mode, is displayed the same way as a dialog in landscape mode without full screen.
|
Building blocks are used to lay out the controls in a view. Each Building block has a number of slots where controls can be inserted and a view can consist of multiple Building blocks. The row height of Building blocks is adjusted after the font size and the available Application space.
A view that looks like the one below contains six Building blocks:
|
Applications can, and should, use a common set of System Building blocks. UIQ provides such a default set of Building blocks that can be used by any application. Each Building block has a defined layout and handles the placement of the controls to achieve the right margins and alignment.
The Building blocks can be mixed and will work irrespective of which Building blocks that are used together. But to achieve a clean and consistent layout the following guidelines should be used.
Choose a Building block that displays as much information as you think is necessary. For example, in the Contacts application a TwolineBuildingBlock is used to display phone numbers and email addresses, because it is important that the user can see all of the information.
The text in a View is normally aligned vertically on the left-hand side. In the example below, the Building block, IconCaptionedOnelineBuildingBlock, is used to achieve alignment. Also, the Name control, which does not have an icon, makes use of the same building block with the first slot left empty.
IconCaptionedOnelineBuildingBlock example
Avoid mixing Building blocks with different heights in a view in order to achieve good scroll behavior. If you use Building blocks with different heights, try to group them together as much as possible. If the building block is able to receive focus, the highlight covers the whole building block. When more building blocks than fit on the screen are added, the view become scrollable.
The MediumThumbnailDoubleOnelineBuildingBlock and the LargeThumbnailThreelineBuildingBlock are normally placed at the top of the screen where they are never given focus.
|
|
Many of the built-in applications are based around two standard view layouts: a Base/List view and a Detail view. The detail view can be of a “viewing” nature or an “editing” nature.
The base view is the topmost level of the application, providing the user with an overview of all items and navigation between them. The Base/List view normally displays a listt of items for the application where one item is always highlighted.
The interaction style of UIQ is to navigate to an item within the list view and open the detail view for the item by pressing the Action key. This implies that you view a single item at a time. The item that was opened in detail view (or just created) is highlighted in the list view when the user returns.
Applications may support the concept of categories to allow selective filtering of the items shown in the base/list view. Categories are explained further in section 9.1.
Dialogs can be used as a complement to application views. For example, a Dialog can be used to display an information message or to display or change user settings.
|
The user can save any changes by selecting the Save option.
It is recommended to try to limit the number of commands in editable views and dialogs in order to make Save and Cancel immediately available on the Left and Right softkeys. If this is not possible Save will be available in the More menu.
The Save option applies to the entire view/dialog, not to a specific tab. No item is saved if the user has opened the detail view but made no changes.
If any data is changed and the Cancel command is used to navigate from the view/dialog, the user is normally prompted with a query dialog that asks if the changes should be saved or not.
|
A highlight is displayed to indicate which control has focus. The highlight covers both the caption and the control and always uses full width independent of which control has focus. It is recommended that only controls that enable user interaction shall gain highlight, for example, a text used for information (e.g. a label control) should normally not gain highlight.
The Action key acts on the highlighted control. The control is typically changed to an active state when the Action key is pressed. The surrounding screen area, except the Softkey bar and the Status bar, is dimmed when a control is activated.
When activating a control in Softkey style, the set of commands displayed in the Softkey menu should only relate to the commands that relate to the active control.
The rich-text editor and the image-capture control are exceptions. Commands belonging to the active control are available in the application space. For example, cut, copy and paste will be available in the menu of the container control when using a text editor.
|
|
|
Navigation is the term that is used to describe the process of switching between views and applications. There are several issues involved: hierarchy, persistence of status, backtracking and the way navigation commands are given.
On the system level, there is a hierarchy where the Start screen is at the top (or the root). The next level is the application launcher. The third level is the individual application.
On the application level, the base view is on the top and detail views are on lower levels. Only views participate in the navigation hierarchy. Dialogs and menus are considered to be part of the view where they are activated.
|
UIQ does not provide a start screen. However, phone manufacturers and operators can customize their phones by adding a start screen.
When a phone has a start screen, the start screen becomes the root of the navigation hierarchy, just above the UIQ application launcher. Navigation to and from the start screen works in general the same as all navigation in UIQ 3. Movement down the hierarchy is achieved through direct links to applications or to the application launcher. Movement up the hierarchy is achieved through the back command. The back command is activated by a dedicated hardware key or by a softkey.
A special command that directly opens the application launcher, no matter where the user is in the navigation hierarchy. In Softkey style, there is a dedicated hardware key that activates the application launcher.
This special command works even when the start screen is active. Pressing the application-launcher hardware key when the start screen is active moves the user down the navigation hierarchy to the application launcher.
A special feature concerning the start screen is that when the application launcher is active the application-launcher command becomes a direct link to the start screen. Pressing the application-launcher hardware key when the application launcher is active moves the user up the navigation hierarchy to the start screen.
|
When an application is first launched the base view is activated. A detail view that is one level below the base view is activated by selecting an item in the base view. A detail view that is yet another level below is activated by a command in the detail view on the level above it. So moving down the hierarchy is accomplished by executing commands in a view.
Each view has a default setting that decides which tab is active and which component has focus. Normally, a view is set to the default when it is opened.
Moving up the hierarchy is accomplished by the Cancel command.
Normal activation of the Cancel command activates the view one level up. Prolonged activation executed by the Cancel hardware key activates the views in the hierarchy in succession. Activating the Cancel command when the base view is active makes the Application launcher active.
An important feature of using the Cancel command to climb back up the hierarchy in an application is that the default settings for tab and focus activation are restored when a view is exited. But, when returning to a view on a higher level, the default settings will not be restored. Rather, tabs and focus are found to be the way they were when the command to the lower level was used.
|
The normal method of switching from one application to another is to first switch to the Application launcher and from there switch to the other application. There are two ways to activate the Application launcher from a view in an application. The first one is to “back out”, that is, continuing to activate the Cancel command until the Applications launcher is reached.
The second way to activate the Application launcher from a view in an application is to activate the Launcher short-cut. This activates the Application launcher directly. The Launcher short-cut could, for example, be added as a separate hardware key (the Launcher key), this is up to the mobile phone manufacturer.
Both of these methods achieve the same result, the view is exited and the Application launcher is active. There is, however, a very important difference. When the Launcher key is used, the default settings for tab and focus activation are not restored. More over, the view that was active when the application was exited is remembered. When the application is once again activated from the Application launcher, the View that was remembered is activated. This behavior is known as persistence of views.
Another way of switching from one application to another is to launch the Task list (QuickLauncher). The Task list displays the most recently used view of the most recently launched applications. The Task list is activated by a long press on the Launcher key (if available) and gives the user a fast way to navigate from one task to another. If no Launcher key is available it is up to the mobile phone manufacturer to take action on how the Task list will be launched. The behavior for the persistence of views is valid also for a long press on the Launcher key. For more information about the Task list (QuickLauncher).
The tasks that users want to perform often require the use of more than one application. Users even want to use applications in parallel, for example, to temporarily leave one application in the middle of a task, carry out another task using another application and return to the first application and continue with first task. Users, of course, want to continue working on the first task where they left off. They do not want to have to begin again from the beginning.
To facilitate switching back and forth between applications, UIQ 3 secures the persistence of views when appropriate. The entire state of a view is not persisted. Dialogs and menus that were open are closed. But the positions of tabs and focus are preserved. Other details, such as the state of check boxes, can vary from view to view.
The backbone of this service is the two different ways to navigate between applications. Put simply, views are persisted when an application is exited by activating the Launcher key. Views are returned to their default settings when they are exited by activating the Cancel command. So, if you have completed the task you were using the application for, “back out”. If you want to return to where you are, use the Launcher key. Think of the Launcher key as the “switch application” key and the Cancel command as “exit”.
All modifications to user data should be saved automatically when switching applications. Leaving an application does not necessarily mean that the user will switch back to it immediately; the phone might even be switched off. Automatically saving user data ensures that it is not lost.
Application menus and pop-up menus are closed when switching to another application.
Controls in an active state are closed and the data is saved when switching to another application.
Dialogs are closed and saved when switching to another application.
Item selections are normally persisted in list views/base views. See section 8.4.4.
When editable views are exited and another application is activated, the data is saved and an Infoprint, “Entry saved” for example, is shown unless the view is empty or not edited since the view was last saved. From a system point of view, the application should be set as busy. The memory manager does not close down busy applications unless all other applications already have been closed and there is still not enough free memory.
All applications are returned to base view after reboot.
Another feature UIQ 3 provides to promote cooperative use of applications is the Direct Navigation Link (DNL). The situation that the DNL addresses is when there is a task that naturally begins in one application but ends in another. The prime example is using Contacts to start communication, for example, sending an SMS.
A very natural routine for starting communication is to look up the person you wish to communicate with in Contacts. There you choose the form or communication that is appropriate for the moment.
The solution is to use a view from a second application as if it were a detail view in the first application. This is achieved with a DNL. A DNL will switch to the view in the second application. More than that, it fills in the appropriate data from the first application in the view in the second application. In our example, the Send SMS DNL would switch to the Create SMS view in Messaging, create a new SMS and fill in the phone number.
After the message is sent, or if the user cancels the message, the detail view in Contacts reappears on the screen. Because we want the SMS view to feel like it is a view in Contacts, using the Cancel command will not go up the hierarchy in Messaging. Instead, it will go up the hierarchy in Contacts, that is, back to the detail view in Contacts where we first selected the Send SMS DNL. And, the state of that view will have been persisted.
Using a DNL is a powerful way to extend the apparent functionality of an application. It is, however, limited to just one level. If the meaning of having the DNL is interrupted, the Cancel command will not return to the view and the application will not be persisted. For example, the user could decide to interrupt the Send SMS task while in Messaging and switch to Agenda by way of the Application launcher. After returning to Messaging, using the Cancel command will go up the hierarchy in Messaging, not in Contacts.
If an application is exited via the Application launcher and then re-entered via another DNL, the state it was first in will be lost. The application will be returned to base view.
|
In UIQ 3 the whole idea behind where menu items are placed as been changed to meet the challenge of supporting different UI styles from one codeline. Different UI styles use the screen and keys in different ways. Menu items can not simply be grouped under different menus once and for all. In UIQ 3 there is really just a set of context sensitive commands. Depending on the number of commands in the set, the commands will be displayed in different ways, for example as softkey labels or menu items. The placement of the commands is dependant of the type that is assigned to each command. Different commands have different command types and are handled by the UIQ command processing framework (CPF). The different command types are laid out according to a set of rules. For more information about the most frequently used command types, see section 6.4.
We use the term command list to refer to a simple list of commands the user can choose to execute in a given situation.
The most important commands are displayed in the softkey label area and are activated by the softkeys. The most intuitive or most important command is mapped to the Action key. Remaining commands are typically available in a menu opened via a softkey.
An application can define one list of commands for each UI configuration. This enables an application to have different sets of functionality for each UI configuration.
The menu pane does not cover the title area or the Softkey bar, which typically gives a menu with seven rows in Softkey style. If more menu commands are available than can fit on the screen, a scroll bar will appear. Scroll bars in menus should be avoided if possible by reducing the number of commands in the menu or grouping related commands in a cascading menu.
Commands located in the main menu are normally removed when they are unavailable.
Do not use ellipses (…) to indicate commands that lead to dialogs. A menu command is a menu command, whether it leads to instant action or a dialog.
Use option buttons to avoid flip-flop command names such as Sort by xx and Sort by yy , because users often are not sure whether Sort by xx means “sort by xx is currently selected” or “if you choose this command, it will sort by xx”.
Two labels must be supplied for commands that are candidates for appearing on a softkey. One is a short label for the softkey and the other is a longer label intended for menu options.
The length of labels for commands in menus should be limited to approximately 15 characters.
The length of labels for commands on softkeys should be limited to approximately 7 characters.
Dimmed menu commands can gain focus.
Dividers
There are two kinds of dividers. A divider can be placed under a menu label, or it can contain a label and will then occupy one full row.
Use dividers to group similar menu commands together, and to separate them from commands that are unrelated but appear on the same menu. Do not overuse them.
If the application or dialog contains both control specific and application or dialog specific commands, a divider will be displayed between the last control command and the first application or dialog command.
Very short menus do not benefit from the use of dividers.
Cascading menus
A cascading menu can, like a divider, be used to group similar menu commands together. The benefit of using a cascading menu is that the number of commands is reduced in the main menu. It is important to find a suitable label that reflects the commands found in the cascading menu.
Cascaded menu panes are indicated by an arrow.
A cascaded pane is displayed even when the cascade command is dimmed.
The use of multiple levels of cascading menus is discouraged.
Commands currently not available in a cascading menu should normally be dimmed. This makes it’s easier for the user to learn the location of the commands.
|
The menu in Softkey style is context sensitive. This means that the menu changes depending on the position of the highlight. Unavailable commands in relation to the control having focus are normally removed; commands placed in a cascading menu are an exception. In some cases, a command can be dimmed to prevent the user from looking for a command that currently is unavailable. When acted upon, a dimmed command displays an Infoprint to inform the user why the command is not available. However, this rule does not always apply. On some occasions an Infoprint is unnecessary and does not have to be launched when a dimmed command is acted upon.
Commands that cannot be used within a specific tab are not available. An exception is commands located in a cascading menu. When one or more commands are available in several tabs all commands be should displayed but the unavailable commands should be dimmed.
Commands that are not expected to be used within a view in a specific state must not be available. For example, commands that cannot be used on multiple items are removed when the user has selected one or several items.
|
Some commands frequently recur in many applications. They should be made available in the same way each time.
|
|
The following table illustrates the order and grouping of commands. Not all applications contain this set of commands. When the commands are present, they should follow the suggested order in Softkey variant 3SK.
|
The condition in this example is that a contact entry with mobile phone number is highlighted in the list no entry are selected and category All is displayed.
|
|
The most frequently used command types are:
|
Most application commands are of Screen type. Context sensitive commands, that is commands that are dependent on which control is highlighted, are most often of the item type.
Commands can be grouped together in groups in two different ways: in named groups and in unnamed groups.
A named group can be assigned to any softkey. The entire group is assigned to the softkey as a menu pop-out with the group name as the softkey label. The group will become a cascading menu if it is placed in the menu.
|
Commands in an unnamed group never end up directly on a softkey. Dividers are displayed above and below commands within an unnamed group to separate them from other commands in the menu. Placing a named grouped in a cascading menu will have the same effect.
|
Action key: operates on the object or control in focus. The label “View” is normally displayed if there is a detail view for the focused item. This is commonly used in list views when the list contains items. See section 10.1 for details about Action-key labels. When the list is empty the label “New” is normally displayed (see section 6.4.).
The Done command is most often named “Save” in editable views and dialogs.
Action key: Operates on the object or control in focus. The label on the Action key is provided by the control.
|
View and Dialog
For applications where users frequently create new entries there must be a fast way of creating a new entry in the process flow from the application launcher to the new item. For those applications it is recommended that the New command is placed as the first item in the application’s Base View. If that is not applicable New should be placed as the first item in the More menu
The New command should be mapped to the Action key when an application does not contain any data.
New command example
|
In UIQ 3 there are three different types of dialogs. The old style dialog, which uses the Eik dialog class, is the most frequently used dialog in the system today. The Eik dialog class has now been deprecated, which means the old dialog style should not be used in new applications. Instead, one of the two new types of dialogs, the Simple dialog and the View dialog should be used.
The Simple dialog is a simplified version of the old style dialog. The Simple dialog does not, for example, enable multiple pages using tabs. The View dialog, which inherits from the view class, is in many ways like a view.
Both the Simple and the View dialog uses Building blocks for the layout of UI controls.
|
Choose a dialog title that gives a clear context to the user. If the dialog is opened from a menu command, the dialog title should have the same name as the menu command.
Each dialog saves its content independently, even if the dialog was activated from another dialog where Cancel is available. For example, pressing Save in a dialog further down in the hierarchy saves the settings, even if you press Cancel in the dialog higher up in the hierarchy.
If the user presses Save in a dialog without entering all the required information, or if some information is invalid, use an Infoprint to describe the first problem you find with the data and return control to the user with focus on the first field containing an error or an incomplete item.
The expression “OK” is never used in UIQ dialogs. ‘”Done’”/ “Save’” correspond to “OK” in other systems. “Save” is normally used in editable dialogs. Another label, for example “Rename”, that reflects the action executed when the softkey is pressed may be used. The exception is a dialog that does not save the content but passes the information on in a data flow. For example, a dialog where the user enters a passkey before downloading emails should not use “Save”.
In non-editable dialogs the command label should define a name that reflects the action executed when the softkey is pressed, for example, “Move” or “Download”. Use “Done” or “Continue” if no other suitable name is available. Give the user the option of closing the dialog via a softkey.
“Back” is also used as label for the Cancel command when editing in not possible i.e. list view and detail view/non-editable view dialogs. If the dialog has a save option and any data has been changed when the Cancel command is used to navigate from the dialog, the user should normally be prompted with a query dialog asking whether or not the changes should be saved.
Dialogs, other than notifications, which are covered in section 10.3, are application modal , that is, they prevent other actions from occurring in the application until the dialog is closed. They do not, however, prevent the user from switching to another application.
The default behavior of a dialog defines what happens if the user switches to another application while a dialog is opened. Normally, dialogs act as if Save has been pressed, saving data if possible. If user input would be required before saving, for example, if the dialog is in an invalid state, the framework cancels the dialog. No confirmation dialog will be shown to the user. Non-editable dialogs are canceled.
A View-dialog behaves and looks just as a standard view in landscape mode.
For Simple dialogs:
A dialog that is launched in landscape mode uses the full screen width.
The height is adjusted automatically according to the content of the dialog. The dialog does not cover the status bar.
The application space and the application title area are dimmed and unavailable when a dialog is opened.
|
A Simple dialog uses the full screen width. The height is adjusted automatically according to the content of the dialog. The Simple dialog is not allowed to cover the Status bar. A dialog is bottom aligned above the Softkey bar in Softkey style. An advantage compared to the old style dialog is that Simple dialogs are screen mode aware, meaning that the layout of the dialog can be adapted dynamically to both portrait and landscape mode. The simple dialog can use Building blocks for the layout of the controls.
Multiple pages using tabs is not supported by Simple dialogs. As a rule of thumb, Simple dialogs should only be used for simple actions (for example a single user input), ask a single question or provide information. Basically this means that a Simple dialog should not have more than a few of UI controls. The use of scrollbars in Simple dialogs is discouraged.
Examples of when a Simple dialog typically should be used:
Notification dialogs, for example new message and alarm,
Dialogs with only a single setting. The zoom level dialog is an example,
Dialogs which ask the user to choose an alternative, for example, the Send as dialog.
|
The View-dialog is a dialog that looks like a view. A View-dialog, for example, can use Building Blocks for layout, supports multiple pages using tabs and always occupies the entire screen expect the status bar and Softkey bar. View-dialogs should be used for relatively complex dialogs that offer the user many options and choices. The Select file dialog in UIQ 3 is a good example of when to use a View-dialog. View-dialogs are also ideal for dialogs with multiple settings.
Example of a View-dialog
|
Information dialogs give information to the user and require nothing more than an acknowledgement. They have only a Continue option which can be acted upon by the Action key.
The title text “Information” is normally used.
The default behavior for Information dialogs is that the dialog is closed if the user switches to another application. Notification dialogs are an exception see section 10.3.
Example of an Information dialog in Softkey style
Query dialogs ask the user a question. They have Yes and No options. The title text contains keywords that reflect the reason why the dialog is launched, for example, “Connect to Internet”, but without a question mark.
If the user navigates away without having selected any option the dialog closes as if No has been pressed.
Example of a Query dialog in Softkey style
Progress dialogs keep running in the background even if the user switches to another application. If the user switches back to the application before the Progress dialog has closed, the dialog will become visible again. Consider using an Information dialog after the progress is finished to notify the user about this. For example, display an Information dialog when the installation of an application is complete.
Use a Progress dialog with a progress bar control when the progress time is known.
Example of a Progress dialog:
|
Use a Progress dialog with an animation when the progress time is not known.
If the action can be cancelled and leave a net result as if nothing had happened, the progress dialog has a Cancel option. Cancel is assigned to the right.
If the action can be stopped and the action is partially completed, the progress dialog has a Stop option. Stop is assigned to the right.
Where possible it is recommended that users are allowed to hide Progress dialogs and continue to interact with an application while a task is executed in the background. When a Progress dialog is hidden, users should have the option to bring the Progress dialog back on screen again to view detailed progress information and to cancel or stop a task. It is recommended that the action to open a Progress dialog again is made available as a command on a Softkey or in the More menu. While a Progress dialog is hidden, progress information should be displayed in the View Context bar.
|
This section describes some guidelines concerning when and how to use some of the UIQ controls.
Each control in the system is suitable for different things. Controls have captions that are placed above the control. Normally controls are left justified. However, horizontal mirroring of control layout, for the purpose of localization, is supported. Most controls make use of the full screen width are left justified and placed below the caption. The Labeled check box and the Labeled color selector control do not make use of a caption. The description text is added directly in the control. The effect is that the Labeled check box and the Labeled color selector control are left justified and placed on the same row as the text.
In a view, an inactive control is removed. In a dialog, the inactive control is dimmed. This is to prevent the dialog from changing its height depending on active/ inactive controls.
|
Controls that require input from the navigation keys are often impractical to use directly in views or dialogs. The navigation keys is used to navigate in the view/dialog such as moving focus between controls or changing the active tab in a tabbed view/ dialog. To solve this, some of the controls make use of the Control stand-in and other controls have their own pop-ups to handle editable and non-editable states. The plain text editor shall normally be resizable when it is used within the control stand-in.
If only one control is present in a non-tabbed view or dialog, there is no need for having the control in a Container Pop-out. The benefit is that the user does not have to activate the control before acting on it. No highlight shall be displayed when only one control is available.
In a view/ dialog with only two controls and where one control is less important, consider putting the less important control in the menu instead. The important control can then be displayed directly in the view/ dialog. For example, in a Find dialog the most important thing is to easily input the search string. Functionality like ‘Find where’ is less frequently used and could be placed in the menu.
When a control is alone in a dialog it is preferable to not duplicate the title text in the caption.
|
|
Use the choice list control when one option is predefined and other controls are present in the dialog. This control is preferable over to the option button control when the number of choices can change. The choice list can also be used in a dialog when there is no predefined option and other controls are present. Avoid using the choice list control alone in a dialog. The choice list control requires several events to act upon and the benefit with having the control directly in the dialog is not great.
Choice list
|
Use the option button control when a few options are available and one option is predefined. Avoid using the option button control together with other controls in a dialog since this can cause problems with the navigation. Use the option button control directly in the dialog instead where the user can select and close the dialog with one press.
Option buttons
|
The list box is frequently used in UIQ and also used in many different situations. The list box can display items in a vertical list or grid.
Avoid displaying a List box control directly in a View/Dialog together with other controls since this could cause problems with the navigation.
The list box should, if possible, show an even number of rows. This is to prevent double row items, which are commonly used, being cut in half at the bottom of the screen.
Examples of different ways of using the list box control:
Select and view
Setting list
Select and continue
Select and return
This is an example of a Select and View list box.
UIQ provides a set of standard layouts. The combination of layout and data makes a list box item. An item can have a layout with columns and rows in any combination within the layout but it is recommended to use a standard layout.
Normal layout – The layout used for non-highlighted items in the list box.
Highlight layout (optional) – The layout used for a highlighted item in the list box.
Generally, the same Normal layout is used on all non-highlighted items in the list which makes the list look clear and simple.
The highlighted item in the list box can use a different layout, Highlight layout, which can contain different areas that can receive user input. This is used if the highlighted item is displayed differently than non-highlighted items. A Highlight layout is not used if the same layout is desired for both non-highlighted items and highlighted items. All items normally use the same Highlight layout for all items. It is important that the same number of rows is used for all highlighted items. This is to prevent the non-highlighted items in the list from changing position when the user moves the highlight.
Examples of commonly used list box layouts. For more information and the full set of standard layouts.
|
Content swapping is used for shifting data that is displayed in a defined set of slots in an item. The left and right navigation keys are used to shift data within the item.
If the highlighted layout uses content swapping but the currently highlighted item does not have any more data then what is displayed, the arrows are dimmed.
For each of the two content swapping arrows in the example below, the slot ID of the contact type (icon) and the contact contents (phone number) are defined.
Example of content swapping
The first item in a vertical list and the top left item in a grid normally have initial highlight by default. It is possible to display the initial highlight on other positions. For example, the initial highlight is displayed in the middle in the application launcher, which enables the user to fast access to several applications.
|
Up and down navigation keys are used to navigate within a list box that displays items in a vertical list, see section 4.3. As default, the list makes use of central scrolling when items are displayed in a vertical list, which means that the last/ first visible item is not highlighted until the list has reached the end/beginning.
If the list has a highlight layout it can make use of the context swapping functionality. Left and right navigation keys are then used to navigate the arrows inside the highlight layout. Consequently, tabs can not be used together with the context swapping functionality.
If the currently highlighted item is removed, the next item in the list will be highlighted. The highlight remains on the most recently highlighted item. For example, if a new item is created and then saved without any information, highlight remains on the previously highlighted item.
To be able to perform actions on multiple items in a list, for example, to delete several items at once, individual list-box items can be marked. To indicate that an item is marked a check mark in a check box is displayed to the left of the item. If a grid layout with a large icon/ thumbnail is used, the check box should be displayed in front of the lower-left corner of the icon/ thumbnail.
Commands will only affect items that are marked. The highlighted item is not affected if it is not marked.
Marks are cleared as soon as a command has been successfully performed. They are even cleared when the user switches to another application using the Back option, selects the “Unmark all” option or selects another category. Marks in a list view are persisted if the user switches to another application from the list view via the application launcher. Marks in a list view are normally persisted if the user enters the detail view for an item and then returns to the list view.
Examples of persisting marks
Suitable to persist marks: Marks are persisted when several messages in the Messaging application have been marked and the user opens the detail view of one of the messages. When returning from the detail view to the list view, the marks are persisted.
Unsuitable to persist marks: Marks are not persisted when several folders or files have been marked in the File manager application and the user opens a folder. When returning to the previous folder, all the marks are removed.
When an item is dimmed, it shall not be possible to mark/unmark the dimmed item. The Mark and Unmark commands should not be available when a dimmed item is highlighted. Using the “Mark all” and “Unmark all” commands should not change the marking of a dimmed item.
In 3.1 enhancements have been made to the multiple select list box; mark mode is now enabled and the behavior of mark mode and its command placement is dependent on the Softkey variant that is in use.
Command placement for default Mark mode
Mark mode is entered when the mark command is selected in the More menu.
The placement of the “Mark”/”Unmark” command is different depending on the Softkey variant in use.
The priority of the commands is restored when the user exits Mark mode.
|
Applications using special mark mode solutions
There are a few variations of the default mark mode behavior that work in UIQ applications. These variations require the applications to tweak the List box’s mark related commands.
Application designers should be aware that implementing special/custom mark mode behavior on one variant of Softkey style may have impact when the application is used on a phone running the other Softkey variant.
The following variations of the default mark mode can be applied:
Initial mark mode
Done/mark mode
View with Done command
The list box is a very flexible UI Control that can be used in various situations. Below are some typical examples of when and how to use a list box.
This type of list is used to display user data. It is possible to navigate to an item and view details for the highlighted item by pressing the Action key, see section 10.1 for commonly used labels. The item that was opened is highlighted in the list when the user returns. This implies that you view a single item at a time.
The highlighted item can also be acted on via a command. If the list makes use of multiple selections it is possible to select several items and then apply a command on all of the selected items.
A Select-and-view list is used in both views and dialogs. A Select-and-view list should normally make use of the View dialog.
An example of Select and view used in a View is the List view in the Contacts application.
This list category is used to display system options where the user can select one option.
Use this list category when there is not any predefined option. The Select-and-continue list category can handle both few and several options and is functional when the number of options can change from time to time.
The Action key has the label “Select”.
Dialogs make use of this list category. The height of the list is adjusted to the number of options available in the list, at most 6 rows. If more items are available the list grows, but not the height of the control space. A Select-and-continue dialog could make use of the View dialog.
An example of Select one option and continue is the Send as dialog.
This list category is used to display user data. It is possible to navigate to and select one or several items at the time depending on if the list makes use of multiple select.
A Select-and-return list should make use of the View dialog which occupies the full screen.
An example of Select and return is the shared UI in the Contacts application.
Single select
In a Single-select dialog the label “Select” is displayed on the Action key label (Center softkey). The dialog is closed and the highlighted item is returned to the calling application when the Action key is pressed.
In mark mode the Done command selects all marked items and closes the dialog. When one or more items are selected the select command is renamed to “Done”.
A highlighted item that is not marked is not selected when “Done” is chosen.
The command placement for multiple select and the Done command differs within the two Softkey variants. The example below describes the command placement in 3SK.
Multiple select:
|
|
Tabs can hold text or icons to summarize the content of the tab page. Tabs are used to divide information when there is much information to display. The data does not have to be equally divided between the tabs. Keep in mind that data that is not displayed on the initial tab is more concealed. The most common use cases or the most important data should always be accessible on the initial tab. Less important use cases and data are placed on another tab.
If more tabs are placed on the screen than can be displayed at once, two navigation arrows are displayed allowing the user to scroll among available tabs. Scrollable tabs should be avoided, if possible, because of the lack of overview.
View tabs are used in Application Views and in View Dialogs.
To save space in views, icons are most commonly used. There are system-wide icons for the most common ways of breaking up information. Applications should use these icons if possible:
Main information
User notes
Attachments
If there is no data on a page for a particular item in, for example a detail view, the tab is normally not removed. It should be shown and when selected, opened to an empty area.
When saving information in a view with tabs, all information in the view is saved.
In dialogs, text is most commonly used on tabs to be as descriptive as possible. However, it is important to choose a short text to avoid scrollable tabs as much as possible.
When saving information in a View dialog with tabs, all information in the View dialog is saved.
|
An Infoprint is a message that appears for about three seconds in the top-right corner of the UIQ screen (or optionally another corner). This gives the user plenty of time to read it, but the user does not have to tap any button to dismiss it. Infoprints are sometimes referred to in Symbian OS literature as info-messages.
Do use Infoprints:
To confirm that something expected has happened when there is no other visual feedback. For example, an entry was copied to the clipboard.
To report that something that was expected happened/ has not happened when there is no other visual feedback.
To give instant error responses to something the user just did, for example, if the user pressed Save in a dialog without entering all the required information, or if some information is invalid.
Do not use Infoprints:
To notify the user of something that is not really obvious, for example, an unexpected system error that the user should know about and then confirm. Use an information dialog for this.
To say that something has happened if there is already some other obvious visual feedback on the screen, for example, when the user has just selected a menu command which launched a dialog.
General advice when using Infoprints:
Make it obvious whether an Infoprint is conveying good news or bad news.
An Infoprint can be displayed on several lines but it is a good rule to make Infoprints short. They are only displayed for three seconds and the user must have time to read the information. As a general rule, not more then 15 characters should be used.
Avoid pleasantries: “Enter a number” is better than “Please enter a number”.
Use “Not available - <reason>” if a feature is not available because the application is busy doing something else, or “Not available at this time” if the reason is too wordy or complicated.
|
A busy message is a flashing message. It appears in the middle of the screen, aligned to the right-hand side of the screen. It informs the user that the application cannot process user input at the moment.
Always give a reason. Use, for example, “Loading…”, rather than “Please wait” or “Busy”.
An ellipsis, “…”, at the end implies that the user has to wait, without saying so specifically.
It is recommended to use a progress dialog instead of a Busy message to indicate a long-running action. The reason for that is that a Progress dialog allows the user to select a Cancel or Stop option to interrupt the busy process if necessary, see section 7.4.3.
|
Scroll bars should only appear when scrolling in either direction is possible. They should be removed when not needed.
The thumb control is proportional to the amount of the content that can fit on the screen, that is, it has a dynamic size.
|
|
This section covers details about storing user data. There are two ways for an application to store user data, either in a database or in the file system. User data in databases should be organized using categories. User data stored as files should be stored in the predefined folder structure for files owned by the user. File folders are used to organize files. The concept of viewers is also presented in this section. Viewers provide users with a preview of received data and enable users to save it.
|
Categories are used to divide user data into user definable sets and act as filters in the application list view. Categories are used in applications that handle non-file-based items, for example, Contacts and Agenda. The default behavior of categories allows the user to ignore the category functionality altogether. By default, a new item should be assigned to the category Unfiled. This category cannot be renamed nor deleted. All items are visible in the All category. Depending on the application using categories, an item can be assigned to a single or multiple categories.
Example of Categories in the Agenda application
In the application list view, the name of the currently selected category is displayed in the application’s title bar instead of in the application name. The application name is displayed when the All category is selected. The name of the current application is always displayed in the detail view of the application.
Each application has its own set of categories. A category created in one application is not available in other applications.
Category names are not case sensitive. For example, if there is a category with the name “aAaA”, and the user tries to add/rename a category using the name “aaaa”, the new category will not be allowed because it is considered to have the same name as the existing category.
It is not possible to merge categories.
The category menu is not compulsory.
The View-category command is reached via the softkey menu.
“All” should always be placed at the top and “Unfiled” at the bottom. Folders created by the user should be sorted alphabetically between “All” and “Unfiled”.
The Edit-categories-menu command brings up a dialog to rename/ add/ delete categories.
When adding a new category the currently selected category remains selected.
If the currently selected folder is renamed, that folder stays selected and the name of the category is updated in the title bar. If a category that is not the currently selected one is renamed, the currently selected category stays selected.
If the currently selected category is deleted, the “All” option is displayed. When deleting a category that is not the currently selected one, the currently selected category stays selected.
Items are moved between categories using the Category-choice list displayed in the application space. When the user switches, for example, to “Business” the current item is moved to that category. If the application supports the functionality of putting an item in several categories, a list box is used to select/ unselect to which categories the item belongs.
The Unfiled category is always placed at the bottom. Folders created by the user are sorted alphabetically before the Unfiled category.
Example of a category menu:
All
Business
Friends
Personal
Unfiled
The category setting of the list view is persistent per application, even after reboot.
The currently selected category in a Base view should remain selected if the user opens the detail view, moves the entry to another category and then returns to the Base view.
The category selected in the base/ list view remains even when the user changes category in detail view.
A new item is created in the currently selected category. If the category All is selected, then a new item is created in the category Unfiled.
The base/ list view only supports pasting items. For example, text cannot be pasted into the view. The entry will be placed in the Unfiled category if the All option is selected.
|
Applications can choose to store user data as files. UIQ provides a set of predefined file folders for organizing user data: Images, Audio, Video, Documents and Other. This folder structure is available both on the mobile phone’s internal memory and on the memory card.
When saving a file the framework will suggest a default folder (based on the MIME type), for example the folder Images when saving an image. But users can choose to store the file in any folder.
Additional folders can be created both on the mobile phone’s internal memory and on a memory card. There is no restriction on the number of sub-folders that can be created.
Access to files and folders on the internal memory is limited to the predefined folder structure, whereas users are given full access to a memory card’s folder structure. Tabs are used to separate the internal memory from a memory card.
File Manager dialog
UIQ provides dialogs with basic file operations like saving, selecting and copying files.
The Select dialog can be launched in different modes depending of which file the calling application expects to receive. The Select dialog can support selecting single or multiple files, changing the sort order of the files and filtering the folders to only display files belonging to certain categories.
If the Select dialog, for example, is launched via the Add-attachment command in the Messaging application, multiple select will be enabled and no filtering of files will occur. When the Select file dialog is launched from the Contacts application with the purpose of selecting an image for a contact, the Select dialog will have a single select nature and only display files recognized as the category Images.
Select image dialog
DCIM (Digital Camera Images) is a standardized folder located on the root on the memory card. The DCIM folder is used by digital cameras, and the mobile phone’s onboard camera, to store photos. Files located under the DCIM folder are mirrored in a folder named Camera located in the Image and Video folders on the memory card.
|
Viewers are used to preview and save files. UIQ has a set of viewers for displaying information that is received on an UIQ mobile phone. These files can, for example, come to the mobile phone by downloading them with Web, as email attachments or via Bluetooth.
Viewers are not stand-alone applications, that is, they cannot be opened from the Application Launcher. Viewers operate as application-modal dialogs and appear in front of the application that launched them. When the viewer is closed, the user returns to the view from which it was launched, for example the detail view of an email.
Viewers for non-file-based items typically provide the option of saving information to the proper application, like the vCal viewer below that saves data to the Agenda application.
Viewer for non-file-based items
Pressing Save sends the data to the associated application and pressing Cancel does not. In either case, the user then returns to the place from which the viewer was launched.
Such viewers often include a View entry after save option. If this option is selected when Save is pressed the data will be saved to the associated application. The viewer will close and an application switch will take place so that the user ends up in the detail view of the correct application, viewing the data they just have saved.
When saving data to an application, no check is made to see if matching or similar data already exists. It is left to the user to resolve any duplication manually.
![[Top]](../../../../_stock/arrow_up_2.gif){kind=icon}
