Components
Toast
Toasts are messages containing confirmations, notifications, and acknowledgments that require minimal user interaction.
Types of toasts
Type | Icon | Description |
---|---|---|
Info | Used when neutral information is being communicated. | |
Success | Used to communicate to the user when some action is successful. | |
Warning | Used to communicate to the user when extra care should be taken. | |
Error | Used to communicate to the user when something has gone wrong. |
In addition to these types, toasts can also be timed or persistent. Persistent toasts remain on the screen until the user has taken the desired action, or until they manually dismiss the toast. These toasts are useful for things like a billing failure, out of date credit card information, etc. Persistent toasts should be used sparingly to limit showing more than one on screen at a time.
Timed toasts, which are the default, automatically dismiss after 6 seconds (4 seconds on mobile). When using timed toasts, do not display more than 3 toasts on screen at one time. Toasts are delayed until the oldest leaves the screen. If three toasts are present on screen, the toasts are ordered oldest to newest, with the most recent toast appearing at the bottom of the stack.
Use the type of toast that best corresponds to the event driving the toast.
Toast contents
Toasts can contain any combination of the following three items depending on the desired functionality.:
- Title
- Body
- Link
Use the following tool to toggle the title, body, and link on/off and then fire a toast to see the result.
Toasts with links
For better accessibility, toasts with links should be persistent. This is so users using assistive technologies, especially keyboards, have enough time to navigate to the links inside toasts.
Best practice would be to avoid using links at all in toasts. If you need to use a toast with a link, it should:
- Persist on the screen until dismissed manually.
- Be triggered by scenarios like errors e.g. billing failures, out of date credit card information, etc.
- Not be triggered by common actions or workflows as this might result in many duplicate toasts displaying on screen at a time.
Questions to ask when considering the use of Toasts
- What will the volume of these toasts be in the app? Avoid overwhelming the user with toasts.
- What action will trigger the toasts? Be considerate of the user, question whether the action warrants a toast at all? Could a lighter method of feedback be used instead or is feedback even necessary?
- Is it a destructive action? If so, consider using a confirmation modal as a secondary confirmation of the destructive action instead of a toast.
- Does the toast merely provide a shortcut to a workflow that already exists in the app? Consider not using toasts in this scenario. Focus instead on the existing workflow and improve it.
Mobile considerations
When using toasts on mobile devices, there are some additional guidelines to consider:
- Only one toast appears on the screen at a time. New toasts are delayed until the previous one leaves the screen.
- The user is able to take action on the screen while the toast is still visible.
- Toast disappears when the user navigates away from the current screen.
iOS
Toasts on iOS devices appear by dropping down from the top of the screen, and disappear by moving up and off of the screen. Toasts are placed near the top of the screen, mirroring the position of system push notifications, and can be manually dismissed by swiping up.
Android
Toasts on Android devices appear by moving up from the bottom of the screen, and disappear by moving down and out of the screen. They can be manually dismissed by swiping down.
Android Toasts follow the Google material Snackbar designs.