Dialogs are temporary states that are used as part of the UI flow to prompt or inform the user about something related to what they are doing.

Can also be triggered outside the current flow and will be then displayed in the foreground, possibly interrupting the user's current flow. For example, a BT connection request dialog is shown on top of the current flow and the user is requested to either accept or reject the connection.

Dialogs are modal. User has to interact with the UI to dismiss the dialog, go back, or proceed with the flow.

Note: We recommend not using dialogs for presenting scrollable information. For large content that does not fit the screen and needs scrolling, consider using a separate view instead.

Spinner and progress dialogs expire after the process is completed. While a dialog is shown, users cannot interact with the background state.

Note: Pickers are modal but not classified as dialogs. Pickers are typically used for settings, enabling users to select a value. They are not temporary UI states like dialogs. They typically include status zone and the UI functions normally when they are displayed. Pickers can be scrollable or include scrollable elements.

Dialog interactions

Dialogs should follow the behavious described below:

Gesture/key press Behaviour
Back key , short press Dismisses the dialog and goes to the previous state. If dialog has a negative response button, back key functionality should be mapped to work in the same way.
Back key, long press Triggers the dialog "Do you want to close this app? [name of the app], with "Yes" and "No" buttons in it. This is a system pattern that cannot be overridden.
Side swipes Exits the application or flow and goes to a main screen. Thus, dismisses the dialog with the application exit. This is a system pattern that cannot be overridden.
Top and bottom swipes Disabled. No access to notification panel while dialog is displayed. Dialog never contains option menu. This is a system pattern that cannot be overridden.
Tapping a button inside the dialog Dismisses the dialog and either goes to previous state or proceeds with the flow with chosen action.
Tapping another element inside the dialog, e.g. check box Toggles the check box marked and unmarked.

Note: If you are implementing custom dialogs, make sure that their behaviour is aligned to these recommendations.

Below is an example of pressing Back key in a dialog.

When UI displays a banner, it is shown on top of the dialog. Top and bottom swipes are inactive when a dialog is displayed.

Dialog components

The main purpose of dialogs is to ask users to confirm an action.

Dialogs can also be used for:
  • Giving important information to the user.
  • Warning the user about possibly hazardous actions that they are about to take.

When the UI is halt for an ongoing process, you can illustrate the progress and keep the user informed about how the progress is proceeding by using a dialog with a progress bar or a spinner. Use a spinner if the duration of the process is unknown.

Note: Dialogs with spinner, progress bar and check box are not available as ready-made LWUIT components and have to be implemented as custom solutions.

Dialogs can contain the following elements (different combinations are possible based on the needs of the use cases):

Title text
  • Possible to add title text as a header for the dialog when it adds information that needs to stand out from other text.
  • Using title text should be avoided if it only repeats the information that can be described with the actual dialog (for example, the title is not needed if the title would be "import" and the text part would be "do you want to import all contacts?")


  • Always mandatory.
  • Should be concise to make it easy to grasp the meaning.
  • In dialogs showing the progress of a process, whenever possible it should give more information about the progress, e.g. showing the count of already processed items and how many are in total to be processed.
  • Should not be scrollable. If text is too long and needs scrolling support, consider using custom states instead of dialogs.


  • At least 1 button is always mandatory.
  • Max 3 buttons can be used.
  • Buttons are always placed on top of each other and shown at the bottom of the dialog.
  • One of the buttons can be highlighted.
  • Typical for confirmation dialogs: one button confirms the action, the other button declines the action.
  • In progress dialogs, typically one button is used to enable users to stop/cancel the process.
  • Can also be used for confirming or skipping an action when presented as part of a continuous flow.


  • Branded graphics can be used (e.g. icons for specific brands).
  • Generic icons like information, warning, error etc. should not be used.
  • No need to add e.g. thumbnails of contact or image to be deleted. User should know what he is deleting from previous state and by seeing name of the contact in the dialog.

Note: The following elements are not supported in LWUIT Dialogs, but can be implemented as custom solutions:
Check box
  • Can be added if there is a need to give users control for a setting, e.g. auto-connecting with a BT device that asks for pairing.
  • Is typically displayed above the button(s).
  • On/off settings can be presented as check boxes in temporary dialog states.
Progress bar
  • Should be used in dialogs used to show the progress of a process of known duration.
  • Should be used in dialogs used to show the progress of a process of unknown duration.

To keep the flow smooth and avoid legal issues, do not use confirmation dialogs that can be dismissed to make users read Terms & Conditions or statements that they need to agree to before continuing. Use UI state with body text and necessary button(s) on content area instead.

Tip: Try the following:
  • Whenever possible, avoid dialogs with a progress bar/spinner.
  • Embed progress bars on items (e.g., inside a list item). This will inform users that the item is unusable but it does not prevent them from carrying on with other tasks.

For more information, see the Progress indication guideline.

Sequential dialogs

Dialogs can be presented in a sequence if they form a logical flow. However, try to avoid repeating dialogs of the same type. This would give users the feeling of not being in control.

Below is an example of presenting dialogs in sequence.

Last updated 24 September 2013

Back to top