Collab space: Dialogue

This is an open space for collaborating on a dialogue pattern. To join in the conversation please add a comment below.

Overview

Dialogues make a user stop and think by presenting them with a critical action or piece of information required to continue.

When to use dialogues

Use dialogues to:

  • Notify a user of an immediate response required to continue
  • Confirm a user’s action when it cannot be undone
  • Notify a user of urgent information that affects their current process

Do:

  • Ensure the headline and buttons are clear and reflect the action
  • Clearly explain the potential consequences of the action
  • Use danger dialogues for destructive or irreversible actions
  • Where applicable, give the user an option which will close the dialogue with no change - ** Great to hear feedback on when a close button would be required/used over the secondary action button, or where they would perform different actions **

Do not:

  • Over use dialogues as this will cause disruption to the user

Types of dialogues

  • Transactional - Alert a user to urgent information they must acknowledge before continuing
  • Danger - Alert a user to a destructive or irreversible action they must confirm before continuing

Interaction Design & Usability Research

Dialogues should:

  • Have a clear message
  • Focus on a single task
  • Where possible, contain no more than two actions (primary and secondary).

UI Design

Accessibility

  • When a dialogue is opened, keyboard focus should move automatically to the dialogue container.
  • Keyboard focus should cycle through the dialogue content and should not leave until dialogue is closed.
  • Pressing the ESC key or selecting an action that cancels the process should close the dialogue and return user to the underlying page.
  • When closed, keyboard focus should return back to the component that launched the dialogue.

Credits

These awesome collaborators have contributed insights, knowledge, and time to the information above:
Future Friendly

3 Likes

Thank you, @amy.howard this looks great. I’m dropping a comment now to follow the progress. Will modal dialog include ways to prompt user entering more details before they choose an action?

Hi @tnafoo great! When it comes to users entering details, we would recommend using forms instead of a dialogue to collect user info. Once the details have been provided via a form, the dialogue would then be triggered in response to their action (“Submit” for example).

2 Likes

Hi @amy.howard Yes, I agree user should be entering details on a form not via a pop-up dialog box. Somehow, the vendor I’m working with tend to surface pop-up dialog box to enter details. I’m trying to encourage the use of forms more. Is there anywhere on digital.NSW design system website making recommendation on forms and not pop-up box? What are the pros and cons of using them? Or, any best practices you’re aware of that I can refer to?

Thank you again!

Hi @tnafoo sure thing! This is the guidance we’ve written so far to release along with the component. We haven’t written too much about capturing user info, mainly to avoid it and use forms. I hope this helps and eager to hear any feedback you have:

Usage

Dialogues display on top of the page content to alert a user to an action that must be completed in order to continue.

Use dialogues to:

  • notify a user of an immediate response required to continue
  • confirm a user’s action when it cannot be undone
  • notify a user of urgent information that affects their current process

Do:

  • ensure the headline and call to actions are clear and reflect the action or task
  • clearly explain the potential consequences of the action
  • use danger dialogues for destructive or irreversible actions
  • when required, give the user an option to close the dialogue with no change
  • use sparingly and only when necessary. Overuse can cause disruption to the user

Types of dialogues

Transactional - Alert a user to urgent information they must acknowledge before continuing
Danger - Alert a user to a destructive or irreversible action they must confirm before continuing

When to avoid

Do not use:

  • to display simple alerts, consider in-page alerts
  • to capture user details, consider simple forms
  • to display large amounts of information
1 Like

Quick question @amy.howard , Are there any insights as to Buttons being right aligned and its impact on Accessibility?

1 Like

Hi @Tee_tee01, apologies for the delay in my response. We haven’t come across any accessibly issues with the buttons being aligned to the right, however keen to hear if any have been raised. Buttons on the right is a strong and widely used design pattern, especially beneficial for mobile devices. We’ll also be building in best practice for assistive technologies and tab sequences to ensure the focus moves correctly on launch and close.

@amy.howard @Tee_tee01 I had the exact same question too about the position of the buttons. I have seen buttons centre-aligned but not so much right and left aligned. And I can’t really see the benefit doing this for mobile devices. It will be good to get specific about the pros and cons on this. What do you think?

1 Like

@tnafoo thanks for sharing! If you could share the centred button examples with us that would be great. Always very keen to incorporate additional learnings into our components.

When the device reaches the small viewport the buttons are set to stack by default for readability and selection. However if button text is short enough they may also work side by side.

iOS and Material both use a right aligned primary button approach for larger screens. Differing slightly on smaller devices where iOS goes full width side-by-side or stacked, and Material remains right aligned. This can be very dependant on the button text itself and number of call to actions. We hope that our base dialogue lends itself to the flexibility teams needs to adapt based on their content and user needs.

heya @tnafoo and @amy.howard.

We ended up with right aligned buttons for the dialogue design on desktop and stacked them on mobile, exactly like Amy’s examples. We have included larger padding and a smaller heading size.

In terms of use cases we had a lengthy discussion about this, we felt that users read left to right so it made sense to have the buttons on the right.

Only on form designs, do we left align buttons.

1 Like

Excited to announce the release of the NSW Design System Dialog component! You can check it out at NSW Digital Design System - Dialog

Hi @amy.howard :wave:, just thought I share something that came up in a recent accessibility audit organised by one of the team in Service NSW. The audit was done by Intopia. It’s to do with making the header and CTA area sticky which cause dialog content to be covered up or not having enough vertical space when the page is zoomed from 200%, and 400%. It’s marked as High severity.

Want to know if this is a false alarm or whether we should re-consider the sticky areas.

Hi @tris
Would you be able to share some further details of accessibility audit and maybe few links/screenshots to help us understand the issue better? Our header/nav is not sticky by default so I wonder if this is a result of a custom modification?

Hi @anna.yeshtukova - you’re right, your header is not sticky. Ours is a different component altogether but have very similar structure, so I thought I’d share the research finding. Not making it sticky may be enough to alleviate the issue.

Here’s the dialog in question btw: