Dialogs
Updated: Dec 18, 2024
Dialogs are transactional, temporary surfaces used to communicate with users, solicit user input, and provide access to common flows.
Figure 1: Dialog box that asks the user to confirm permissions.
Dialogs should convey information that requires a user response or input. Use them cautiously, as they can disrupt the user experience.
This guide highlights some current use cases:
- Providing users with essential system-level information, such as confirming that the device will restart or offering an app access to the user’s microphone.
- Allowing users to make selections, like choosing to update an app installation.
- Onboarding users to new features, such as the Voice Assistant NUX feature.
System Dialogs are available across contexts and are rendered on top of visible UI, Worlds, and panel applications.
- Blocking Behavior: System Dialogs are system blocking.
- Keyboard: System Dialogs are able to use the system keyboard for text input.
- Flows: System Dialogs can use single and multi step flows.
System dialogs are rendered using a single view that can be configured using a range of supported components.
Figure 2: System dialog anatomy
1. Key art |
2. Title |
3. Progress (optional) |
4. Body |
5. Info (optional), for legal notices |
6. Primary call to action |
7. Secondary call to action (optional, often Cancel) |
8. List header |
9. Media/colored icon (optional) |
10. Radio button (optional) |
Used when a header image or video is needed. Cannot be used with other components outside of basic actions due to height restrictions.
Figure 3: Header image used above the title.
Used when list selection is required. Lists can support single or multiple selections. If needed, body text can be placed above the list, although this is not recommended.
Figure 4: List option
You can use pin entry to unlock experiences that require a PIN.
Figure 5: Pin entry