Dialog boxes and toasts
Dialog boxes have many roles in BlackBerry 10. They can be used as notifications, display progress and activity, show errors, and help with deleting text or files. As useful and attention-getting as dialog boxes are, you should try to avoid implementing them whenever possible. They are modal, and interrupt the user's interaction with the UI flow.
When possible, present feedback and hints that you might normally add to a dialog box inline, in the context where the user is. This type of feedback doesn’t interrupt the user’s flow and doesn’t force them to act.
The goal of most dialog boxes is for the user to scan the information they contain and perform an action in just a few seconds.
Don't use up screen real estate. Dialog boxes should be less than half a screen in height and should never block important text or images that might help the user decide how to interact with the dialog box. If the information or complexity in your dialog box needs more space, consider using cards and sheets instead, which are more flexible.
Limit the number of buttons. Dialog boxes support one to four buttons that allow user input. Using four buttons should be uncommon, because they increase the complexity of the message and can burden the user. The buttons are placed next to each other horizontally, not stacked vertically one on top of the other.
Maintain consistency across associated dialog boxes. If multiple subsequent dialog boxes are needed to complete a flow, you must pay close attention to the placement of the buttons. If the purpose of the dialog boxes is similar, keep the buttons in the same general position on each dialog box to avoid unintentional actions.
Avoid using “Don’t show again” or “Always ask” check boxes. Many users lack the knowledge to decide if a notification dialog box should be shown to them always or never, so they choose the dialog box to be shown at each event. This choice slows the flow and undermines their experience. Think carefully about the frequency of these types of dialog boxes and consider instructing the user how to change app settings in the body of the dialog box instead of using these check boxes.
Use short, relevant titles. Short titles confirm for the user which application or function the dialog box is associated with.
Keep the body text brief. It should clearly summarize in no more than two sentences what the user is asked to do with the dialog box. If it is a confirmation, it should be formulated as a question. If it is a prompt, it should instruct the user.
Use clear, impactful, single-word actions on your buttons. The actions are the most important element and by using verbs such as “Delete” or “Cancel”, users can often select an action without reading the body of the dialog box.
A toast is a simple, non-modal pop-up message that allows an application to give brief feedback that disappears from the UI quickly. A basic toast can contain text, an icon, or a combination of the two (for example, displaying volume level or progress feedback).
Special intrusive toasts reserved exclusively for undoing a delete command can also be used. This toast includes an Undo button.
Since toasts are not as disruptive as dialog boxes, they are often the best choice to get a simple message across to users.
Toasts are short-lived. They should disappear in just 3 seconds, giving the user enough time to read but not be delayed by the message.
Keep context in mind. Toasts should appear close to where an action was performed. The top of the screen is the best spot for sheet actions such as Send or Cancel. The center is prime placement when the toast is not immediately connected to a part of the screen (for example, to indicate that sound has been muted). The bottom is suitable for toasts that are triggered by actions in the action bar.
Don't be verbose. Any text you add to a toast should be readable in less than 3 seconds. Try to limit yourself to single-sentence, single-line messages.