7 DIALOGS

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. For example, a 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/ button 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/ button 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. Do not leave this solely to the Cancel key.

Cancel is available via the Cancel key in Softkey style and as a Cancel button in Pen style. 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 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 Simple dialog uses the full screen width. The height is adjusted automatically according to the content of the dialog. A dialog is bottom aligned above the softkey bar in Softkey style and above the Status bar in Pen 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.

Multiple pages using tabs is not supported by Simple dialogs. As a rule of thumb, Simple dialogs should only accept a single user input, ask a single question or provide information. Basically this means that a Simple dialog should not have more than a couple 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.

In this section, some of the more commonly used standard dialogs are presented.

Information dialogs give information to the user and require nothing more than an acknowledgement. They have only a Continue option which is placed on the Action key. In Pen style, this is indicated by a prominent border around the Continue button.

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.

Examples of information dialogs

Softkey style Pen style Information dialog in softkey style Information dialog in pen style

Query dialogs ask the user a question. They have Yes and No options. Yes is assigned to the left softkey and No is assigned to the right softkey. The Action key is mapped to the Yes command and the Cancel hardware key is mapped to the No command. In Pen style this is indicated by a prominent border around the Yes button. The title text contains keywords that reflect the reason why the dialog is launched, for example, "Connect to Internet", but without a question mark.

The default behavior for Query dialogs is as if No has been pressed.

Examples of query dialogs

Softkey style Pen style Query dialog in softkey style Query dialog in pen 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.

Examples of progress dialogs:

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 softkey and the Cancel hardware key is mapped to the Cancel command.

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 softkey and Cancel hardware key is mapped to the Cancel command.

If the action cannot be cancelled or stopped, there are no options in the dialog. For example, a dialog informing the user that the database of an application is compressed has no options.