In T321893#8386350, @RHo wrote:

I would expect in a new design of this with actions on the bottom, for the "back" to be next to the primary action here, and for the "Show options" button to be on the left close to where the "drawer" opens from, and/or possibly styled and placed differently altogether.

@RHo keep in mind that this task is just to design the large size dialog that becomes a fullscreen in mobile. For the specific Process Dialog we have this other task T315535. What if we move forward with the close button at the top right (as defined in option 1) and we leave the Back-Close buttons decision for the Process Dialog task T315535? I think the most important think now is to test the placement of the action buttons (if we want them to be grouped at the bottom or if we want to separate them moving the main button on top). Once we have made this decision we will have more clarity about the placement of the close button: if we decide to move the Primary button to the top right then the close button will need to be at the top left, and if we leave the buttons at the bottom then we can evaluate the best approach for the close and back button.

Since the fullscreen mobile dialog is the mobile version here of the large dialog, I would follow the most responsive behavior that is with the close button on top right (as in the rest of devices) and the buttons at the bottom. Then, if we can test the implementation to understand if it really works or not.

In T321893#8387643, @egardner wrote:

I spent some time this morning looking at how other big UI frameworks handle fullscreen dialog elements. Here are two takeaways:

1. The latest version of Google's Material Design framework features a full-screen dialog variant which places the "close affordance" at the top left and the primary action at the top right. Their Dialog guidelines also specify that the fullscreen dialog should transform into a simple dialog (with buttons at the bottom) as screen size changes. So Google at least has decided that everything I mentioned as a concern in my comment above is not an issue. There is no web implementation of this yet so I don't know how well this actually works, but their design guidelines are very clear on this point. Also, none of the fullscreen dialog examples show multiple actions in the header, just a single primary action and a close icon on opposite sides.
   

@egardner this is a great example, but as you comments they don't have any example with multi-step and more than one primary button in the fullscreen dialog, so not sure how it will work with Primary and Secondary buttons. I agree with the Primary button on top when there is only one action, it works well and of course it's more visible for users. The problem is when we have Primary and Secondary buttons since separate them one at the top and the other at the bottom is not a good solution since the user needs to jump from the top to the bottom to find all the available actions in the dialog.

In T321893#8388854, @bmartinezcalvo wrote:

In T321893#8386350, @RHo wrote:

I would expect in a new design of this with actions on the bottom, for the "back" to be next to the primary action here, and for the "Show options" button to be on the left close to where the "drawer" opens from, and/or possibly styled and placed differently altogether.

@RHo keep in mind that this task is just to design the large size dialog that becomes a fullscreen in mobile. For the specific Process Dialog we have this other task T315535. What if we move forward with the close button at the top right (as defined in option 1) and we leave the Back-Close buttons decision for the Process Dialog task T315535? I think the most important think now is to test the placement of the action buttons (if we want them to be grouped at the bottom or if we want to separate them moving the main button on top). Once we have made this decision we will have more clarity about the placement of the close button: if we decide to move the Primary button to the top right then the close button will need to be at the top left, and if we leave the buttons at the bottom then we can evaluate the best approach for the close and back button.

Since the fullscreen mobile dialog is the mobile version here of the large dialog, I would follow the most responsive behavior that is with the close button on top right (as in the rest of devices) and the buttons at the bottom. Then, if we can test the implementation to understand if it really works or not.

In T321893#8387643, @egardner wrote:

I spent some time this morning looking at how other big UI frameworks handle fullscreen dialog elements. Here are two takeaways:

1. The latest version of Google's Material Design framework features a full-screen dialog variant which places the "close affordance" at the top left and the primary action at the top right. Their Dialog guidelines also specify that the fullscreen dialog should transform into a simple dialog (with buttons at the bottom) as screen size changes. So Google at least has decided that everything I mentioned as a concern in my comment above is not an issue. There is no web implementation of this yet so I don't know how well this actually works, but their design guidelines are very clear on this point. Also, none of the fullscreen dialog examples show multiple actions in the header, just a single primary action and a close icon on opposite sides.
   

@egardner this is a great example, but as you comments they don't have any example with multi-step and more than one primary button in the fullscreen dialog, so not sure how it will work with Primary and Secondary buttons. I agree with the Primary button on top when there is only one action, it works well and of course it's more visible for users. The problem is when we have Primary and Secondary buttons since separate them one at the top and the other at the bottom is not a good solution since the user needs to jump from the top to the bottom to find all the available actions in the dialog.

I think if we want to treat process dialogs separately as you and @egardner say, it solves the problem for this task, since the implication (which we can make more explicit) is that multistep dialogs should use process dialogs (where there is a need for navigation and action controls).

After our DST Engineering/Design sync meeting we've decided to separate the Dialog component into two different components. Current version of the dialog T313773 will be used for the simple version of a dialog and we'll create another component for the complex version of the dialog (e.g. process dialogs, template dialogs)

If we separate the Dialog into 2 different components we'll be able to define in each one:

• Size: small / large / fullscreen
• Button placement
• Functionality and use of each component. Simple version of the dialog could be used just as an informative message for the user while complex version could be used when the user needs to perform an action (e.g. fill a form, edit and publish an article, etc.)

Suggested component name to separate the Dialog into different components:

• Option 1: Dialog (simple) / Modal (complex)
• Option2: MessageDialog (simple) / Modal (complex)
• Option3: Alert (simple) / Dialog (complex)

@bmartinezcalvo I was going back over the Commons MediasSearch feature (which Anne and I developed using early versions of what later became many of the Codex components). It turns out we actually have a mobile fullscreen dialog here (which is *not* a process dialog). We use this in two places (and only in Minerva skin).

1. The "Namespace Filter" dialog (displays a pretty complex set of radios and checkboxes to the user)
2. The mobile search results "quickview" feature appears inside a fullscreen modal dialog (on desktop this shows up in a sidebar). This is kind of a special case because it doesn't include any actions and the buttons are all custom as well. So maybe this could remain a one-off component.

I actually think that both of these scenarios would fit well with your idea of a "ComplexDialog" – the second use-case does not appear on desktop at all (we present the QuickView in a sidebar there). But for the first one, showing a large but not fullscreen dialog to the user would probably be fine. And

Below are screenshots of both dialogs in action. To see them yourself, follow this link (ideally on a mobile device, but even on a PC you can see the behavior): https://commons.m.wikimedia.org/wiki/Special:MediaSearch?type=image&search=cat

Namespace filter mobile fullscreen dialog

Search result preview mobile fullscreen dialog

Screen recordings:

In T321893#8432892, @bmartinezcalvo wrote:

After our DST Engineering/Design sync meeting we've decided to separate the Dialog component into two different components. Current version of the dialog T313773 will be used for the simple version of a dialog and we'll create another component for the complex version of the dialog (e.g. process dialogs, template dialogs)

Moving this task off the sprint board since we will work the fullscreen mobile when we design the Large/Complex/Process Dialog.

Hi,
I am working on T329037, as part of the Modernization of Growth Team web interfaces using Vue.js. We would like to use fullscreen mobile Dialog for addlink and addimage onboarding dialogs. Is it on your plans to start working on it anytime soon?

Hi @VYanez-WMF, the Design Systems Team is planning to prioritize investigating how we can support these more complex dialog use cases as part of our upcoming sprint. In general, we would like to collaborate with the Growth Team on exploring how we'd like to accomplish this: through expanding the functionality of the existing Codex dialog, introducing a new complex dialog that would support the design of the onboarding dialog, or whether it might make sense for Growth to build an onboarding-specific dialog (with the potential of upstreaming this into Codex).

Hey all, I've been testing some fullscreen mobile dialogs on iOS and Android devices and I'm adding here the devices and browsers where I found problems when the keyboard appears (also included them in the task description):

When the keyboard appears on mobile/tablet devices using Safari and Chrome, a scroll appears and the dialog header and footer stop being fixed so the action buttons placed at the fixed footer of the dialog will appear at the end of the scroll. Also, since the header will stop being fixed when the keyboard appears, the main button in the header will not be visible if the user is scrolling the dialog.

This is not a problem in the default browser on Android devices (Samsung Internet in my case).

Since the keyboard will be a problem in both Safari and Chrome on mobile/tablet devices, we need to decide which of the following solutions is favorable for the action buttons placement:

• Option 1: Group all action buttons at the bottom. Although they will be hidden when keyboard appears, at least both options will be grouped in the same place, so user will be able to find the secondary button easily. We find this behavior in other webs like Airbnb one where they place the main button at the fixed footer.
  
• Option 2: Place the main button on top and the secondary action/s at the bottom. When keyboard appears the main action will be visible, but the secondary one will be completely hidden within the scroll, so the user could guess that there is just one main action in the dialog.
  

I don't recommend Option 2 since, considering the keyboard will hide the fixed header and footer, any of the main or secondary actions will be visible when scrolling. So I think it's better to group all actions together rather than separate them. Also, as I commented before, when the keyboard is open is why the user is focused on typing the input, so I don't think in this step viewing the buttons is completely necessary. The buttons will be visible again once the keyboard is closed.

Aside from that, Option 1 would be better for unifying the placement of the buttons on Normal, Process and Onboarding mobile dialogs, as well as in other "conversational" components like the Modal Sheet. With this pattern we will unify:

• Close/Skip button on top left
• Action buttons at the bottom

cc: @KieranMcCann for visibility.

Based on https://blog.opendigerati.com/the-eccentric-ways-of-ios-safari-with-the-keyboard-b5aa3f34228 , T218414, and prior attempts at dealing with this problem, we (developers) should evaluate if it's feasible to resize the dialog when the keyboard opens. We should also explore if the new dynamic viewport height unit is useful for sizing the dialog to cover the entire screen.

However, @bmartinezcalvo it sounds like you favor option 1 even if we don't find a technical solution to those problems?

In T321893#8763671, @bmartinezcalvo wrote:

Hey all, I've been testing some fullscreen mobile dialogs on iOS and Android devices and I'm adding here the devices and browsers where I found problems when the keyboard appears (also included them in the task description):

Device and browser	Problem when keyboard appears
iPhone (Safari)	❌
iPad (Safari)	❌
Android (Samsung Internet)	✅
Android (Chrome)	❌

When the keyboard appears on mobile/tablet devices using Safari and Chrome, a scroll appears and the dialog header and footer stop being fixed so the action buttons placed at the fixed footer of the dialog will appear at the end of the scroll. Also, since the header will stop being fixed when the keyboard appears, the main button in the header will not be visible if the user is scrolling the dialog.

This is not a problem in the default browser on Android devices (Samsung Internet in my case).

I think the issue on iOS will be on *any* browser will have this issue as they all use Safari WebKit.

NOTE: The problem only occurs when the dialog contains an input where the user must type and the keyboard appears. So this will not occur in OnboardingDialogs or Dialogs that just have text/images.

---

Since the keyboard will be a problem in both Safari and Chrome on mobile/tablet devices, we need to decide which of the following solutions is favorable for the action buttons placement:

• Option 1: Group all action buttons at the bottom. Although they will be hidden when keyboard appears, at least both options will be grouped in the same place, so user will be able to find the secondary button easily. We find this behavior in other webs like Airbnb one where they place the main button at the fixed footer.
  
• Option 2: Place the main button on top and the secondary action/s at the bottom. When keyboard appears the main action will be visible, but the secondary one will be completely hidden within the scroll, so the user could guess that there is just one main action in the dialog.
  

I don't recommend Option 2 since, considering the keyboard will hide the fixed header and footer, any of the main or secondary actions will be visible when scrolling. So I think it's better to group all actions together rather than separate them. Also, as I commented before, when the keyboard is open is why the user is focused on typing the input, so I don't think in this step viewing the buttons is completely necessary. The buttons will be visible again once the keyboard is closed.

Aside from that, Option 1 would be better for unifying the placement of the buttons on Normal, Process and Onboarding mobile dialogs, as well as in other "conversational" components like the Modal Sheet. With this pattern we will unify:

• Close/Skip button on top left
• Action buttons at the bottom

cc: @KieranMcCann for visibility.

This needs a more discussion and review, since the keyboard hiding when there is an input element is the main reason for this task. It would be essential to do at minimum conduct usability testing with a use case where there is text input and the buttons being hidden if a design with this option being considered.

In T321893#8769400, @Catrope wrote:

Based on https://blog.opendigerati.com/the-eccentric-ways-of-ios-safari-with-the-keyboard-b5aa3f34228 , T218414, and prior attempts at dealing with this problem, we (developers) should evaluate if it's feasible to resize the dialog when the keyboard opens. We should also explore if the new dynamic viewport height unit is useful for sizing the dialog to cover the entire screen.

However, @bmartinezcalvo it sounds like you favor option 1 even if we don't find a technical solution to those problems?

@Catrope I mean, in both option 1 and option 2 any button placed at the bottom or in the header will be hidden when the keyboard appears (watch this video to check how main and secondary buttons disappear when keyboard displays). So keeping this in mind, I think that separating action buttons into 2 different places (main action on top and secondary one at the bottom) is less usable than grouping both them at the bottom. If they are going to disappear in both cases when the keyboard appears, I would at least group both of them so the user can easily find them in the same place.

But this is just my opinion and as @RHo commented, we will need to conduct usability testing to solve this.

In T321893#8770547, @bmartinezcalvo wrote:

In T321893#8769400, @Catrope wrote:

Based on https://blog.opendigerati.com/the-eccentric-ways-of-ios-safari-with-the-keyboard-b5aa3f34228 , T218414, and prior attempts at dealing with this problem, we (developers) should evaluate if it's feasible to resize the dialog when the keyboard opens. We should also explore if the new dynamic viewport height unit is useful for sizing the dialog to cover the entire screen.

However, @bmartinezcalvo it sounds like you favor option 1 even if we don't find a technical solution to those problems?

@Catrope I mean, in both option 1 and option 2 any button placed at the bottom or in the header will be hidden when the keyboard appears (watch this video to check how main and secondary buttons disappear when keyboard displays). So keeping this in mind, I think that separating action buttons into 2 different places (main action on top and secondary one at the bottom) is less usable than grouping both them at the bottom. If they are going to disappear in both cases when the keyboard appears, I would at least group both of them so the user can easily find them in the same place.

But this is just my opinion and as @RHo commented, we will need to conduct usability testing to solve this.

Testing is being conducted to help unblock this task - see T339369

Some weeks ago, we completed T339369: Component user testing: conduct pilot testing on Fullscreen Mobile Dialogs in which we conducted user testing with 5 users to test the new design proposal for the Codex Fullscreen Mobile Dialog where the buttons are fixed at the bottom of the dialog. To test this fullscreen mobile dialog in a real context, we created this prototype that participants accessed from their mobile devices and they needed to complete the "Create account" form within a fullscreen dialog.
This test specifically targeted users utilizing iOS Safari and Android Chrome browsers, where the keyboard covers the buttons when displayed as explained in the task description.

After analyzing the results of the test, these are the findings related with the dialog and its buttons placement:

• Testers didn't face significant challenges completing the "Create account" form within the fullscreen mobile dialog. Just minor issues were reported related to the "Create account" form.
• The entire number of participants encountered no issues finding the dialog button fixed at the bottom of the dialog, even with the keyboard displayed in these browsers.
• Overall, participants had a positive experience with the new design.
• While the button's placement was clear, one of the participants suggested exploring alternative positions, such as moving the button from the bottom right to the left or middle. So we could explore this in case we want to redesign the buttons position in forms and dialogs.

In case you need to review them, you can find the user testing results in these slides, where I documented the background, challenges, goals, findings, and insights.

Hey, just want to say that this work is great. Having buttons at the bottom brings another usability improvement: they are simply closer to the user in terms of finger movement etc. Material design guidelines, I think, are not really representative of actual usability trends: take, for example, their inputs, that have been weird for years now. At the same time, I have a related question: was the right-aligned placement of the buttons in desktop contexts in any way tested for accessibility? Because as far as I know, it is generally preferred to keep the buttons next to the input fields at least for one reason: in magnifier-related context user will be less likely to miss the buttons that are located close to what they are doing/reading (see https://axesslab.com/make-site-accessible-screen-magnifiers/ as an example post to that point). Thanks in advance for the answer.

In T321893#9609507, @stjn wrote:

Hey, just want to say that this work is great. Having buttons at the bottom brings another usability improvement: they are simply closer to the user in terms of finger movement etc. Material design guidelines, I think, are not really representative of actual usability trends: take, for example, their inputs, that have been weird for years now. At the same time, I have a related question: was the right-aligned placement of the buttons in desktop contexts in any way tested for accessibility? Because as far as I know, it is generally preferred to keep the buttons next to the input fields at least for one reason: in magnifier-related context user will be less likely to miss the buttons that are located close to what they are doing/reading (see https://axesslab.com/make-site-accessible-screen-magnifiers/ as an example post to that point). Thanks in advance for the answer.

@stjn thank you for your positive feedback about the redesign of buttons to be grouped at the bottom of the dialog.

Regarding the buttons side, we recently developed these guidelines for Buttons and Links where we defined that buttons in footers should be aligned to the leftmost edge of the overall container for LTR and the rightmost edge of the overall container for RTL. So we will revisit the Dialog's buttons in T358359: Dialog + Popover: evaluate updating buttons behavior to align it with this new button's guidelines.