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).
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).
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?
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
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?
@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.
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.
Hi @amy.howard, 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.
, 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.