Dialogs, Snackbars and Toasts
Dialogs should only be used in the following cases:
Permissions dialogs ask permission for location, notifications, camera, etc. These should only appear once the member performs an action that requires that permission. For example, we should only ask for camera permission once the user taps the barcode scanner.
Confirmation dialogs require users to explicitly confirm a choice, such as confirming a purchase or logging out. Confirmation dialogs can also be used during field entry – such as picking a date or choosing items from a list.
Informational dialogs are used to add context to a field when a member should not lose their work. A good example of this is CVV information in the sign up flow.
Alerts are urgent interruptions requiring acknowledgement – such as confirming loss of significant work. Use consistent language when confirming loss of work. Say “discard” when a member will lose work that’s not saved or published, and “delete” when a member removes published work.
We use bottom sheets when the member takes an action, but we need more information to continue. In this case, a bottom sheet will appear from the bottom of the screen. This should not be used when there is a crucial question we need the user to answer.
Examples of this include sharing badges to Connect and options on a post in Connect.
We use snackbars when the user takes a light action we want to confirm, and a further action is optional. We do not use toasts, as toasts allow for less copy and are not extensible.
Snackbars come from the bottom of the screen and are dismissed after a long or short period of time, depending on length of text. “Short” and “long” are programatically defined. Further actions should be light and relevant to the last action. For example, when a member takes an action that she can undo.
Where possible, show don’t explain to a member that she has completed an action. But if it would disrupt a flow to show and not explain, then use a snackbar to confirm.
Similarly, we use snackbars for warnings that don’t need to block the member’s workflow, like loss of internet connection.