Page MenuHomePhabricator

Add Dialogs to DSG
Closed, ResolvedPublic

Description

The goal of this task is to add “Dialogs” to Design Style Guide “Components” section.

Dialogs are a way to communicate and interact with a user. They are a type of modal or overlay that occurs on top of the site or app for two main reasons:

  1. Critical information to be shared or action that is needed before being able to proceed.
  2. A subset of information that helps perform a task

Dialogs can be presented in a wide range of sizes from small boxes with one sentence to full screen takeovers with more complex tasks.

For this task we will be focused on updating and improving upon the chrome of current OOUI dialogs but not specifying layouts or interactions for the wide range of content that can live within a dialog.

Related GitHub issue raised by volunteer:
https://github.com/wikimedia/WikimediaUI-Style-Guide/issues/376


WAI-ARIA 1.1 definition of a dialog:

A dialog is a descendant window of the primary window of a web application. For HTML pages, the primary application window is the entire web document, i.e., the body element.
Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. See related alertdialog.
[…]
Authors SHOULD ensure that all dialogs (both modal and non-modal) have at least one focusable descendant element. Authors SHOULD focus an element in the modal dialog when it is displayed, and authors SHOULD manage focus of modal dialogs.

And from WAI ARIA practices:

Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.

Event Timeline

To attempt to gain more context and clarity around this task, I've created a slide deck with definitions, current examples, and potential directions we might be able to take this work. So far we've gotten good feedback from the working group and the larger design team during a design review.

Notes from the design review:

Terminology - Dialog vs Modal vs Overlay vs …??

Prateek S: WSG guidelines consider dialogs as anything that is over the main window (so includes notification pop-ups, popovers, modals, etc)
https://www.w3.org/TR/wai-aria-practices/#dialog_modal
https://www.w3.org/TR/wai-aria-1.1/#dialog

Rita H: Salesforce’s design system follows the above definition as well
https://www.lightningdesignsystem.com/components/combobox/?variant=dialog
http://www.lightningdesignsystem.com/components/modals/
https://www.lightningdesignsystem.com/components/popovers/#site-main-content

Lucy B: Would you consider this as something above the surface?

Alex H: Good to find examples of “near misses” to help define what it is https://www.youtube.com/watch?v=uylHeDdlMrc

RH: Part of the confusion is some dialogs change from being over part of the window on Desktop, to being full screen on mobile.

Exploration of components
Position of CTAs
Visual design - updating to our visual metaphor for paper
Simple vs “Complex” or Multi-step dialogs

Alex H: Perhaps another way to approach this work would be to work from inside outwards. So figuring out the outside container visuals first before tackling the interior. Also consider providing counter-examples (don’ts) are really helpful

To the question brought up by @mwilliams in the design review on default button position in dialogs, there has been T128576: All of MediaWiki should use OOUI windows, or none, to achieve consistent dialog button placement filed a while ago. Adding here for completion.

mwilliams renamed this task from Add “Overlays/Modals” to DSG to Add Dialogs to DSG.Nov 10 2020, 3:55 PM

Update time!

There are a lot of use cases and variables that could be explored with this project but I'm really trying to keep the scope of this project as tight as possible in order to keep momentum and publish baseline guidelines to our design system before the end of the year. I expect this to be an evergreen project and evolution :)

We had a good design review yesterday discussing the current state of the project (Work presented is now in the index section of this presentation). The notes for that feedback can be found here. Some of the main points I took away from the conversations are:

  • There is a good amount of work left to figure out how these will work on mobile web and their relation to iOS and Android. Having the main buttons on the bottom can cause a lot of problems with keyboards. I'm going to focus on this next.
  • The background "screen" should be white. There will be need to be variables or exceptions to this rule as in cases like in VE, one needs to be able to see and interact with the content below.
  • Almost everyone thought that the buttons should be on the bottom right side (at least for desktop, mobile tbd).

Here is a screenshot of where we are at (for desktop) based off of the design review yesterday. Credit to @Sarai-WMDE for helping me move more towards a simplified typology, this image is based off of her help on this project.

Typology_Abstraction (3).jpg (1×2 px, 345 KB)

Small mobile update:

I've been exploring how the designs in my previous post might differ on mobile web and iOS/Android. You can see the update starting on slide 18 here.

The quick summary:

  • Considering two different mobile options. A simple bulletin type dialog and a full screen dialog.
  • The full screen design will need to diverge from desktop by having the actions in the top bar in order to not cause issues with the keyboard coming up
  • Still exploring what the ui and chrome of the full screen could look like.

bulletin_dialog_mobile.jpg (1×822 px, 187 KB)
Example of the simple dialog which maps to the desktop design

full_view_dialog_mobile.png (1×1 px, 150 KB)
Example of some possibilities for the full screen dialog on mobile. The current design handles a lot of actions really well and might be worth keeping. The other options include a text based action and a not full height button.

Screen Shot 2020-11-25 at 1.05.24 PM.png (1×1 px, 383 KB)
There are also a lot of these bottom sheet type dialogs found on mobile. I think bottom sheets are a valuable component that may deserve their own space or at least a subset of dialogs. Their behavior also seems to differ on mobile since they mostly directly affect the content above and don't use a white screen on top so one can see the changes they are making.

Small mobile update:

I've been exploring how the designs in my previous post might differ on mobile web and iOS/Android. You can see the update starting on slide 18 here.

The quick summary:

  • Considering two different mobile options. A simple bulletin type dialog and a full screen dialog.
  • The full screen design will need to diverge from desktop by having the actions in the top bar in order to not cause issues with the keyboard coming up
  • Still exploring what the ui and chrome of the full screen could look like.

Thanks for continuing work on this component Matthew! I did have a couple scenarios/quesitons about moving all actions to the top on mobile:

  1. What happens when there are multiple actions?

Some examples when there are actions at the top and bottom in VE:

Templates editor
image.png (1×750 px, 86 KB)
Website reference
image.png (1×732 px, 94 KB)
  1. What happens with dialogs with a persistent footer? Does that remain the same?

Example from Growth Suggested edits filter dialog:

image.png (1×728 px, 108 KB)

Thanks for the feedback @RHo! Here is an attempt to address your questions:

  1. What happens when there are multiple actions?

This is a tough one and I'm not totally sure the right path forward. Ideally we would find a way to keep all of the actions near each other like the changes we are making to desktop. I don't see multiple actions in the top bar fitting after we account for the title and various languages, so perhaps my previous post isn't the best path forward.

Currently any actions at the bottom of a dialog stayed fixed on top of the keyboard. Perhaps the main action could also live in this area (see screenshot below) This appears to be a functional answer but starts to leave very little room left in the viewport to work within. It also feels a bit counter to established iOS and Android patterns. Does anyone have any other potential solutions?

New Example 15.jpg (1×822 px, 145 KB)

  1. What happens with dialogs with a persistent footer?

The persistent footer in your example seems like it could remain the same and stay at the bottom. Are there examples of these where a keyboard would be needed or activated? Doesn't seem like the case in this screenshot but depending on the importance of the message it could live below the keyboard.

Thanks for the feedback @RHo! Here is an attempt to address your questions:

  1. What happens when there are multiple actions?

This is a tough one and I'm not totally sure the right path forward. Ideally we would find a way to keep all of the actions near each other like the changes we are making to desktop. I don't see multiple actions in the top bar fitting after we account for the title and various languages, so perhaps my previous post isn't the best path forward.

Currently any actions at the bottom of a dialog stayed fixed on top of the keyboard. Perhaps the main action could also live in this area (see screenshot below) This appears to be a functional answer but starts to leave very little room left in the viewport to work within. It also feels a bit counter to established iOS and Android patterns. Does anyone have any other potential solutions?

New Example 15.jpg (1×822 px, 145 KB)

Thanks @mwilliams I think this works fine placement-wise, though visually something about the full-bleed CTAs on either side of the footer doesn't look quite right visually, it feels like the footer is severed into 3 sections. It could just be an initial reaction though.
In terms of what happens when the text on button is long, perhaps we could provide an example overflow, actually much like in Material and OOUI, where the buttons go full width and stack on mobile:

OOUI message dialog (2 actions vs 2 actions, long)
image.png (370×1 px, 49 KB)
image.png (412×1 px, 57 KB)
Material design example
image.png (906×1 px, 372 KB)
from https://material.io/components/dialogs#usage
  1. What happens with dialogs with a persistent footer?

The persistent footer in your example seems like it could remain the same and stay at the bottom. Are there examples of these where a keyboard would be needed or activated? Doesn't seem like the case in this screenshot but depending on the importance of the message it could live below the keyboard.

You're right, in this particular case there is no virtual keyboard needed. So, if we want to move the action to to the footer then we could apply the same logic as above where long text in the footer would result in a stacking.

Moved actions to footer
image.png (1×740 px, 116 KB)
Quick example with long labels stacking footer
image.png (1×722 px, 115 KB)

Update time!

We had a good design review yesterday discussing the current state of the project (Work presented is now in the index section of this presentation). The notes for that feedback can be found here. Some of the main points I took away from the conversations are:

  • Almost everyone thought that the buttons should be on the bottom right side (at least for desktop, mobile tbd).

Here is a screenshot of where we are at (for desktop) based off of the design review yesterday. Credit to @Sarai-WMDE for helping me move more towards a simplified typology, this image is based off of her help on this project.

Typology_Abstraction (3).jpg (1×2 px, 345 KB)

Is the “almost” meant as agreement?
Current ProcessDialog looks in one example configuration like this

image.png (334×1 px, 21 KB)

It would be helpful to try layouts with a tough case (German language, at least two buttons, one cta, one normal).
What happens with three button dialogs (close button not included) at different canvas sizes?

This comment was removed by RHo.

So the original reason to move all the primary actions to the top was to make these dialogs "mobile safe", even though they felt slightly counter-intuitive on desktop.

Any solution that moves actions between top and bottom depending on mode (e.g. desktop/mobile, fullscreen/not) will introduce a lot of complexity, especially on dialogs that have footers.

In today's Design Systems meeting we've raised two different points to clarify and settle on.

  1. Button location (Primary aka call-to-action, secondary, tertiary buttons). Arguments for bottom right position of primary buttons (LTR languages):
    1. Progression – most important button as last button,
    2. Familiarity across other interfaces on the web
  2. Rounded borders – we were unclear if the roundedness was only schematic @mwilliams
    1. 2px border radius. We tried to find a balance between seriousness and elegance, while not looking to playful and a more natural feel. A second driver was the paper metaphor, to resemble paper cuts with the small border radius.

Thanks for all the feedback everyone, keep it coming! I'll try and organize this by subject instead of quotes.

Border Radius
Updated to 2px. After reviewing the systems & practices meetings, it seems this is nearly unanimous.

Button Location
I prefer the bottom right position and agree with the two arguments you've mentioned @Volker_E. Allowing for stacking as @RHo has suggested also seems super reasonable and useful. Those points aside, my big concern regarding button/action locations is Ed's point around implementation complexity. Question for @Esanders: currently in OOUI we already have primary actions that are in different places depending on the dialog type. For example the simpler dialogs have the actions below and the more involved ones have them above and below. (See screenshot below). I'm assuming that you mean that we will introduce complexity if a specific type of dialog changes depending on if it's on mobile or desktop as this would require: 1. Knowing when to show which design 2. Writing, testing, and maintaining 2x the code. Am I missing something there?

Screen Shot 2020-12-01 at 1.47.59 PM.png (660×1 px, 339 KB)

If that assumption is correct I see two possible options

  1. We leave the actions where they are currently in OOUI. This doesn't allow us to get all of the actions in one place, which is not ideal in my opinion. It also feels a bit weird and out of place to have them on top on desktop. That being said, it is also a lot less work since this project would mostly be reduced to some minor visual changes to what we already have in OOUI.
  2. We move all of the actions to the bottom and have them fixed to the top of the keyboard. We lose screen space and I obviously still need to explore a lot of use cases (Button text length, different languages, number of actions) to see if this would actually end up working. Something like this:
    Full-screen modal_kb-open.jpg (1×822 px, 174 KB)

I've created a handful of slides comparing the pro's and con's of the different action placement options in the slide deck, slides 15-22. Not going to attempt to replicate here in phab :)

Getting this question answered seems like the most important next step to keeping this project moving!

From meeting with @Esanders and @mwilliams:

  • Original decision decisions on why the buttons are located where they are in OOUI – at bottom fixed position is covered by virtual keyboard location design came from issues on iOS (maybe Android at times back 5y ago) and not so much from desktop design approach. Bottom position therefore is a continuous problem.
  • Evaluate guideline on limiting to secondary action and not enable tertiary actions in dialog chrome.

All actions on top is easiest, even when it's broken currently on iOS.

After meetings with designers, engineers, product managers, and anyone else I could track down and bother, I believe I have enough information to form an opinion and propose a direction forward for this component.

Disclaimers
The following idea and its documentation are aspirational and not something we could switch to immediately. I'm also sticking with these simplified graphics to represent the direction forward at this point. The proposed documentation will go into pixel and interaction detail and have real examples for critique.

The proposal
There are two basic forms a dialog can take: simple and complex (happy to adjust the naming because naming is hard).

  1. Simple
    • A simple dialog has a title, one or two lines of copy, one or two actions, and a close button. If the action text is too long, these can stack on top of each other.
    • The simple dialog will take the exact same shape and design on mobile web and desktop. Aside from a few visual details, this stays the same as our current OOUI design.

simple.png (1×1 px, 74 KB)

  1. Complex
    • A complex dialog requires more information and interaction from the user, which can be displayed in many forms: tables, tabs, lists, and any other layout found in our style guide. These dialogs take up the entire screen on mobile web.
    • On desktop, the main action goes at the bottom, the same as the simple dialog.

Screen Shot 2020-12-16 at 2.58.13 PM.png (1×1 px, 41 KB)

  • On mobile web, the main action goes at the top right in order to avoid any issues with the virtual keyboard.

complex_mobile.png (1×810 px, 38 KB)

  • What about a secondary action that won't fit in the top bar? Good question, after lots of searching, there appears to only be around three or four scenarios in production where we have a secondary action for a complex dialog. Currently, we place those in a fixed bar at the bottom of mobile web, but this implementation is a bit buggy on iOS. After spending time with the current examples, I believe there are multiple ways that these designs could be improved by placing the secondary action in context of the content, and not in the chrome of the dialog. This would eliminate the need for those actions and we would only support one confirmation action for these dialogs (similar to Material Design or the Human Interface Guidelines).

current_bottom_examples.jpg (948×2 px, 539 KB)

Why is this an improvement?
This isn't a huge shift from our current OOUI implementation of dialogs because all in all they are functioning well. A few improvements could include:

  • Placing actions in their conventional location, on the bottom on desktop and in the top right on mobile web. This maps more closely to iOS, Android, etc.
  • Moving away from the buggy and hard-to-maintain fixed buttons at the bottom of the screen. We can instead focus on improving the experience of the complex dialogs by placing related secondary actions where they can more easily be found in context.
  • Aligning the visual design (radius, shadows, spacing, typography) to our style guide
  • Adding the dialog to our design documentation, which is the first step to improving, testing, and iterating on these decisions over time.

What about iOS and Android?
Native should stick to their platform guidelines. If they want to deviate from those that would be a future addition to this component.

Thanks for the detailed explanation, Matthew! I think everything makes sense and agree with all the decisions made. Great job!

@mwilliams These seem all legitimate rules. I think we can start filling up DSG component page based on that outcome!
Two more clarifications needed on simple dialogs:

  • Do all those include a close button? Or should there be a differentiation between types of simple dialogs?
  • Do you propose to change the button layout on those? Including padding? Also the primary position on top when two buttons are below each other were a new (complexer) schema.

@Volker_E Good questions, here is an attempt to answer them :)

Do all simple dialogs include a close button

I think the close button could be replaced by a cancel button in certain scenarios. I would expect it to be a case by case scenario and the "X" to be a optional tool.

Do you purpose to change the button layout on those? Do you propose to change the button layout on those? Including padding? Also the primary position on top when two buttons are below each other were a new (complexer) schema.

Yes, was going to do some adjustments there including the padding. Will share those in my documentation draft I'm working on. In regards to the stacking buttons, I was thinking of having the confirming action on top and any secondary or dismissive actions below. Happy to chat if you have any ideas there.

Here is a very rough draft of the Dialog documentation, feel free to comment as I continue to work on it: https://docs.google.com/document/d/1UmldL2DWjFAERFpeEu6oSe2nq-vJqY3K3NUIc7_iolM/edit?usp=sharing

@mwilliams Looks good on first sight. I've added first round of comments. Mainly questioning one component page versus two (simple and complex), as it could be very content-heavy and possibly more confusing then helping. We could ensure to heavily interlink between them and split users with an extended intro paragraph. Let's keep this in mind.

@mwilliams and myself also agreed in latest 1:1 to put a note on soomewhat limited scope of currently outlined dialogs (only modal types) page with dialog-like interface elements like popovers.