Add new dialog guidelines to create consistency

[matthiasdebaat]

Context

Our design language is based on the latest version of Material Design. These are the guidelines specific to dialogues. We described our interpretation of this on our design website.

Highlighted guidelines

• A best practice is to always use a title, even if it is optional by Material guidelines.
• People mainly read the title and a button. Put the most important information in those two.
• Try to avoid user generated content in the title, this could make the title unreadable long.
• If users become unsure, they read the description. Make sure this explains what will happen.
• Strive for minimalism.
• Keep the button labels short, for example Save, Delete, Enable.
• Destructive actions should be a red warning button.
• Alert or confirmation dialogs only have buttons and no X-icon.
• Try to avoid three buttons in one dialog. Especially when you leave the dialog task unfinished.

Current situation

This desktop screenshot show that a lot of our dialogs are inconsistent, with all kind of historic reasons. Some things I've noticed:

• We have dialogs with X-icons on the top left, top right or none at all.
• Grouped and ungrouped submit and cancel buttons. Or no cancel button at all.
• Different width sizes from 1000px to 400px.
• Not all can be closed with the escape key.
• Some got a hidden expand feature.

Proposal

Add the following guidelines to our design website, even if it deviates from Material Design:

• The close X-icon is on the top left, on all screen sizes. Except for alert and confirmation dialogs, they only have buttons and no X-icon.
• The submit button is grouped with a cancel button at the bottom right, on all screen sizes. Fullscreen mobile dialogs have them sticky at the bottom.
• Dialogs have a max width of 560x. Alert and confirmation dialogs got a fixed width of 320px. And splitscreen dialogs, for example add dashboard card, got a max width of 1000px.
• Extra icon buttons are on the top right, for example help, settings and expand dialog. More than 2 icon buttons, they will be in an overflow menu.
• Dialogs can't be closed with ESC or clicked outside of the dialog when there is a form that the user needs to fill out.

Consequences

• User muscle memory need relearn the X-icon, submit and cancel for some dialogs.
• We need to clean up a lot of dialogs.
• Some dialogs may need a redesign.

[matthiasdebaat]

In the screenshot, many dialogs can have the same width. Setting a maximum width keeps the smaller ones inconsistent, while they could use the extra space. How can we make them 560px without defining a hard rule?

[silamon]

Given the material specs, we tend to combine the dialog specs with the card specs...
Those actions in the right top corner are described in the card specs and not in the dialog specs.
Which may make you wonder if we don't use dialogs too much?

Some of them deserve a page on it's own in my opinion, for example those with the hidden expand feature.

[matthiasdebaat]

Fair point! Currently seeing three types of dialogs with extra actions:

1. Entity (more-info) dialogs, with history, settings and overflow menu in the top right corner and hidden expand function. These dialog exist for easy quick controls. Expand could go to the history page

2. Add/edit dashboard card with help button that link to the Home Assistant website documentation and hidden expand function. Its own page would require a bigger redesign.

3. Only help buttons that link to the Home Assistant website documentation. This could be fixed with a design pattern that got some small description in the dialog and a link to the website. Like we're using here:

[karwosts]

Do we have preferred guidance for how to handle dialogs as the window shrinks? Seems like we have some inconsistency here as well:

• Some don't handle it well and the dialog just overflows off of the visible screen
• Some change to "fullscreen" dialog at an arbitrary width like 450px. However this still can leave it broken in some screen widths if it has a min-width >450px.
• Some define a min-width of e.g. 560 only if the screen is wider than 560, and otherwise they don't specify a size, so we just get whatever it naturally would be.

E.g.:
#17382
#12856

What I did in #12856 is to force shrink the dialog to 95vw when the initial desired min-width doesn't fit, until cutting over to fullscreen at 450px. But I don't know if I should keep replicating that pattern in other places.

[matthiasdebaat]

As noted by @silamon, we're having to much features inside dialogs and that gives some troubles. Some of these examples might get fixed if we give them their own pages and use the responsive design of the page.

[Madelena]

The close X-icon is on the top left, on all screen sizes. Except for alert and confirmation dialogs, they only have buttons and no X-icon.

In Material 3, windowed dialogs have X-icon on the top right. With that said, we had top left X-icon for windowed dialogs for a long time, so it makes sense all of them will be standardized on the top left.

The submit button is grouped with a cancel button at the bottom right, on all screen sizes. Fullscreen mobile dialogs have them sticky at the bottom.

Agreed.

Dialogs have a max width of 560x. Alert and confirmation dialogs got a fixed width of 320px. And splitscreen dialogs, for example add dashboard card, got a max width of 1000px.

Let's indicate and categorize which of the existing dialogs are basic dialogs and which are alerts or confirmation dialogs.

Also, from your list of current dialog examples, the large dialogs and split screen dialogs are all used for editing the dashboard, so let's figure that out later.

Extra icon buttons are on the top right, for example help, settings and expand dialog. More than 2 icon buttons, they will be in an overflow menu.

Yes.

Dialogs can't be closed with ESC or clicked outside of the dialog when there is a form that the user needs to fill out.

When a user attempts to do that, we can show either "Are you sure to cancel this?" dialog, or highlight the fields that the user still needs to fill out.

[matthiasdebaat]

When a user attempts to do that, we can show either "Are you sure to cancel this?" dialog, or highlight the fields that the user still needs to fill out.

When you click outside of a dialog and you got a submit/cancel the dialog can animate "no" by a little shake.