8 ms·

Fullscreen mobile modal: how hard can it be?

56 points by stereobooster 8y ago

mattlondon 8y ago
"Full screen modal dialog" is just another way of saying "a page" right? So some HTML and you are done? I am not sure but from the name of the repo I am guessing this is referring to React JavaScript framework which I think is purely "single page application" deal which would explain the limitation of not being able to load a separate page. Shame we are reimplementing the wheel for such trivial and basic use-cases. Oh well.
- williamdclt 8y ago
  Not exactly "a page", as with a modal you are not messing with the browser history and you expect to keep the exact state of the page underneath the modal
  - djtango 8y ago
    I'm in two minds here - a set of tools/patterns exist for a reason so this is a useful write-up for the difficulties involved with doing modals. On the other hand, it is always a warning indicator when the browser/hardware is fighting against me. In this particular case I feel "modal" is an implementation detail - as long as you don't break the UX contracts (i.e. browser history is left unchanged and page state under modal is remembered) does it matter how you achieve the modal-like behaviour? In this particular case, it could be easier to render the modal using some HTML and/or CSS and hold onto whatever state was underneath - if you're using React, there's no reason to not transition to a different page and either pass the state to the next component OR use something like Redux so you can recall application state.
    - TeMPOraL 8y ago
      > as long as you don't break the UX contracts (i.e. browser history is left unchanged and page state under modal is remembered) does it matter how you achieve the modal-like behaviour? I feel like the hazard here is that many developers don't know, care about, or care about knowing, the full extent of the UX contract, and as a result implement something that's only halfway there. My go-to example of this is one of the Java UI toolkit of old, which reimplemented all controls but tried to make them look as if they were native. The end result was a set of controls that kind-of looked like native ones, except they didn't support appropriate context menus and less-known keyboard shortcuts.
- sebazzz 8y ago
  In some cases a replacement with window.open/target=_blank in combination with window.opener might be possible (especially if loading an iframe in the modal otherwise). It requires browser sniffing though, if you still want to keep the modal experience on desktop/tablet.
- codingdave 8y ago
  React works well for SPAs, but is not limited to them. Either way, though, this does feel like an odd problem to be trying to solve. If you already are a JS app, just handle the blur events to stop them from going to another part of your page. The browser will still let them close the page (or the entire browser), but you can control the UX within your own app. Whether or not that is a good idea is also a valid discussion. Because if you have to go to such lengths to get the UX you want on a mobile device, odds are you are going to end up with a sub-optimal UX, as mobile apps mostly match conventions.
- lucideer 8y ago
  If this is using React (it's not actually clear from the .md file, the only hint is the parent repo name), then this is very easily solved: replace the page with the modal. The solutions seem to be trying to solve this for a normal HTML page without changing page, which is a harder problem.
  - slow_donkey 8y ago
    > If this is using React (it's not actually clear from the .md file, the only hint is the parent repo name), then this is very easily solved: replace the page with the modal. > The solutions seem to be trying to solve this for a normal HTML page without changing page, which is a harder problem. This is a very good point. In an actual spa there is no reason to overlay the modal rather than create a new route
dmitrygr 8y ago
I miss the days when a form was just a form, and as a user I could decide its font size, I could zoom in on it, and I could scroll it as I wished.
- Theodores 8y ago
  ...but you were on a desktop machine then. You could press hot keys to zoom the fonts up a size and whizz up and down with a scroll wheel. On mobile it is different.
  - Nadya 8y ago
    Yeah - on mobile you pinch your fingers together and spread out as a gesture to zoom out. You can go up and down by flicking your finger on the screen. It's still the same. The input methods are different but they have equivalents that are more or less standardized by now. I feel like mobile design has slowly become "do it the designer's way or you're wrong" and give it another 5-10 years before it swings back around to "Oh god, what were we doing taking away the user's choice for all those years?"
    - Theodores 8y ago
      Not really. On desktop there are different ways of controlling the zoom level, it re-flows if you adjust the font size or if you change the desktop resolution. Sure you can root around in the menus on your mobile phone to make the font size bigger but nobody does that. We just zoom without the re-flow. Actually css-tricks did investigate how many people adjust font size on mobile and it wasn't quite 'nobody' but it was rounding error. When it comes to desktop an anecdotal walk around the office will give you the answer - lots of people change their desktop resolution to make it legible. With a full screen mobile modal you just want to get an interaction from the user of the yes/no variety, if keyboard needed then that will be for a simple code or name that is possibly auto-filled. There is no more to it than that - it is a modal. On the desktop the 'correct' tool for this job is actually the 'alert box' but these got abused and 'designers' complained that they could not 'style' the things. Hence we now have frontend developers load loads of useless libraries and spend however long styling these things so that people can subscribe to newsletters they will never read. Hence, for the use case of 'modal dialog boxes' the rules of regular content do not apply. You aren't going to get extra doodads that distract the user away from the task in hand. It is just not needed. What next, vending machines where, prior to buying your snack item you can choose fonts and colours of the 'insert coin' display?
IshKebab 8y ago
Interesting that it's so hard. But also this shows that you really really shouldn't do this - you need 4 horrible hacks to get it to work on one browser. What are the chances that it will work reliably on other browsers, or even the same browser but different versions or configurations? Pretty miniscule I'd say. Just use a separate page.
hamandcheese 8y ago
Even if you get full screen modals working well on mobile, they are a bad UX if only because of the trauma inflicted by all the broken attempts out there.
egfx 8y ago
this feels really weird on desktop
calibas 8y ago
What about just removing what you can't see from the DOM entirely, and load it in again when the dialog closes? Wouldn't be too hard with React or Vue. Just make it so either the page content or the modal is loaded.
- TekMol 8y ago
  Or just throw in a CSS rule that says 'Everything not in the modal is display: none'. You don't need React or Vue for that. Just a line of CSS.
- DerJacques 8y ago
  You can do that, but the visitor's scroll position would be reset, when the modal is closed.
  - calibas 8y ago
    Could save it and restore it, though that may create some other issues.
TekMol 8y ago
My feeling is that it's only hard because the author tried to create a solution that fits his needs by piling more and more external code on top of each other. I would expect that when you tinker a bit with plain CSS, you will find a simple solution.
deleted 8y ago
[deleted]
ifightcrime 8y ago
tabindex?
9dev 8y ago
Oh come on. This task isn't hard of itself, the author just seems to lack experience with the web platform. A responsive modal that goes full-screen on mobile isn't really complex. Just set vertical overflow on the main content element to hidden and auto on the modal container, so the user can only scroll that when its open. Then, focus the first input in the modal if any, or listen to keyup if you really messed with the tabindex. I've implemented this in a few projects, two of them with Vue. That sort of stuff isn't magic, just frontend work.
- chiefalchemist 8y ago
  Any chance you can share a link to a pen?
g_b 8y ago
I wish this full-screen modal feature would disappear. I've lost track on the number of times I pressed back to close a modal on mobile because I thought it was a new page. Please make it clear that a dialog is a dialog.
- slow_donkey 8y ago
  This is interesting, in a native app the modal would close but unintuitively most sites don't push modals to history.
  - TeMPOraL 8y ago
    In a native app, such modal would be pushed on the activity stack (on Android; I assume iOS has a similar pattern). It would essentially be a native equivalent of a new page. Modern web developers are, for some reason, more afraid of having multiple pages than they are of black death.
    - saagarjha 8y ago
      iOS does not push modals onto the navigation stack by default.
      - half-kh-hacker 8y ago
        To be fair, iOS doesn't have a universal 'back' button, so you wouldn't reach for it to exit a modal anyway.
        saagarjha 8y ago
        Sure, but the general guideline for modals is to have a "Cancel" or "Done" bar button item somewhere to exit. This is a different action than popping a view controller off the navigation stack.
- stereobooster 8y ago
  Thanks for this response, this is very helpful. I will update post with this concern
RyanShook 8y ago
What use case would this ever have?
- sseppola 8y ago
  It’s basically a way to have stack navigation on the web, so you can keep the context behind the content it spawned. This is used all the time in native apps, so why not on web? It seems so basic but it’s not straight forward at all to implement in a consistent way across browsers. After trying for a while myself, and not wanting to sink days into it, I’ve given up on finding the perfect solution for now. Going to try the 4th step here, but I believe there’s always a new modal bug waiting to be discovered.
  - RyanShook 8y ago
    I guess I just don’t understand the full screen part. I get why modules can be good but even in a native app you have some reference that you’re still on the same screen. Maybe I’m missing something still...
tdy721 8y ago
I think there is a reason this is hard. This is a security issue. You are masking the URL of the site, Imagine using an iframe inside the modal. This code is exactly what you would need to spoof users if you got JS execution on a host that isn't yours.
nerflad 8y ago
In the previous century when web technologies were more primitive, modal dialogs were created in new browser windows. We all remember pop-ups and what a horrid experience that was. Developers (and spammers) abused this behavior so much that browsers now reflexively prevent pages from opening new windows in most cases. I leave almost any site that interrupts me with a full screen modal dialog, especially if it's a prompt to subscribe to a newsletter. This abuse has become the norm. I have even seen desktop software adopting this behavior. A licensed copy of Guitar Pro 6 will interrupt you with a fullscreen ad for Guitar Pro 7. Unforgivable. Respect what the user is there for, and you might earn their business. Edit: I recognize that there are some positive, responsible uses for this technique (extending forms/controls; search suggestions, assist the user rather than interrupt) and good examples are shown here. Please excuse the Sunday rant.
- sdegutis 8y ago
  Sites do this because 90% of users don’t leave over modal popups and doing it increases engagement in enough cases to warrant keeping it. It’s completely reasonable for a product to advertise for a newer version. How else would you know there’s a new version that you might actually decide you want to buy? And you don’t have to buy it.
  - nerflad 8y ago
    > It’s completely reasonable for a product to advertise for a newer version. No argument from me there. A notice on the splash screen, even a tool tip at start-up would work fine, but it was a full screen advertisement, several minutes after start-up, which stopped playback (!) without warning. These interruptions are what I find completely unacceptable, and I believe they stem from fundamentally misunderstanding what the user is there for, or outright disrespect.
    - TeMPOraL 8y ago
      Notice on the splash screen, a tool tip at start up, a popup at startup (anyone remembers "Tip of the day" dialogs?), a modeline/status bar (like e.g. IntelliJ IDEA does), ... there are plenty of well-established UI patterns for placing such information unobtrusively. As you said, firing up a modal in the middle of your work is unacceptable, and outright disrespectful.
rhizome 8y ago
Not hard enough, apparently.

56 points by stereobooster 8y ago

"Full screen modal dialog" is just another way of saying "a page" right? So some HTML and you are done? I am not sure but from the name of the repo I am guessing this is referring to React JavaScript framework which I think is purely "single page application" deal which would explain the limitation of not being able to load a separate page. Shame we are reimplementing the wheel for such trivial and basic use-cases. Oh well.

williamdclt 8y ago
Not exactly "a page", as with a modal you are not messing with the browser history and you expect to keep the exact state of the page underneath the modal
- djtango 8y ago
  I'm in two minds here - a set of tools/patterns exist for a reason so this is a useful write-up for the difficulties involved with doing modals. On the other hand, it is always a warning indicator when the browser/hardware is fighting against me. In this particular case I feel "modal" is an implementation detail - as long as you don't break the UX contracts (i.e. browser history is left unchanged and page state under modal is remembered) does it matter how you achieve the modal-like behaviour? In this particular case, it could be easier to render the modal using some HTML and/or CSS and hold onto whatever state was underneath - if you're using React, there's no reason to not transition to a different page and either pass the state to the next component OR use something like Redux so you can recall application state.
  - TeMPOraL 8y ago
    > as long as you don't break the UX contracts (i.e. browser history is left unchanged and page state under modal is remembered) does it matter how you achieve the modal-like behaviour? I feel like the hazard here is that many developers don't know, care about, or care about knowing, the full extent of the UX contract, and as a result implement something that's only halfway there. My go-to example of this is one of the Java UI toolkit of old, which reimplemented all controls but tried to make them look as if they were native. The end result was a set of controls that kind-of looked like native ones, except they didn't support appropriate context menus and less-known keyboard shortcuts.
sebazzz 8y ago
In some cases a replacement with window.open/target=_blank in combination with window.opener might be possible (especially if loading an iframe in the modal otherwise). It requires browser sniffing though, if you still want to keep the modal experience on desktop/tablet.
codingdave 8y ago
React works well for SPAs, but is not limited to them. Either way, though, this does feel like an odd problem to be trying to solve. If you already are a JS app, just handle the blur events to stop them from going to another part of your page. The browser will still let them close the page (or the entire browser), but you can control the UX within your own app. Whether or not that is a good idea is also a valid discussion. Because if you have to go to such lengths to get the UX you want on a mobile device, odds are you are going to end up with a sub-optimal UX, as mobile apps mostly match conventions.
lucideer 8y ago
If this is using React (it's not actually clear from the .md file, the only hint is the parent repo name), then this is very easily solved: replace the page with the modal. The solutions seem to be trying to solve this for a normal HTML page without changing page, which is a harder problem.
- slow_donkey 8y ago
  > If this is using React (it's not actually clear from the .md file, the only hint is the parent repo name), then this is very easily solved: replace the page with the modal. > The solutions seem to be trying to solve this for a normal HTML page without changing page, which is a harder problem. This is a very good point. In an actual spa there is no reason to overlay the modal rather than create a new route

dmitrygr 8y ago

I miss the days when a form was just a form, and as a user I could decide its font size, I could zoom in on it, and I could scroll it as I wished.

Theodores 8y ago
...but you were on a desktop machine then. You could press hot keys to zoom the fonts up a size and whizz up and down with a scroll wheel. On mobile it is different.
- Nadya 8y ago
  Yeah - on mobile you pinch your fingers together and spread out as a gesture to zoom out. You can go up and down by flicking your finger on the screen. It's still the same. The input methods are different but they have equivalents that are more or less standardized by now. I feel like mobile design has slowly become "do it the designer's way or you're wrong" and give it another 5-10 years before it swings back around to "Oh god, what were we doing taking away the user's choice for all those years?"
  - Theodores 8y ago
    Not really. On desktop there are different ways of controlling the zoom level, it re-flows if you adjust the font size or if you change the desktop resolution. Sure you can root around in the menus on your mobile phone to make the font size bigger but nobody does that. We just zoom without the re-flow. Actually css-tricks did investigate how many people adjust font size on mobile and it wasn't quite 'nobody' but it was rounding error. When it comes to desktop an anecdotal walk around the office will give you the answer - lots of people change their desktop resolution to make it legible. With a full screen mobile modal you just want to get an interaction from the user of the yes/no variety, if keyboard needed then that will be for a simple code or name that is possibly auto-filled. There is no more to it than that - it is a modal. On the desktop the 'correct' tool for this job is actually the 'alert box' but these got abused and 'designers' complained that they could not 'style' the things. Hence we now have frontend developers load loads of useless libraries and spend however long styling these things so that people can subscribe to newsletters they will never read. Hence, for the use case of 'modal dialog boxes' the rules of regular content do not apply. You aren't going to get extra doodads that distract the user away from the task in hand. It is just not needed. What next, vending machines where, prior to buying your snack item you can choose fonts and colours of the 'insert coin' display?

IshKebab 8y ago

Interesting that it's so hard. But also this shows that you really really shouldn't do this - you need 4 horrible hacks to get it to work on one browser. What are the chances that it will work reliably on other browsers, or even the same browser but different versions or configurations? Pretty miniscule I'd say. Just use a separate page.

hamandcheese 8y ago

Even if you get full screen modals working well on mobile, they are a bad UX if only because of the trauma inflicted by all the broken attempts out there.

egfx 8y ago

this feels really weird on desktop

calibas 8y ago

What about just removing what you can't see from the DOM entirely, and load it in again when the dialog closes? Wouldn't be too hard with React or Vue. Just make it so either the page content or the modal is loaded.

TekMol 8y ago
Or just throw in a CSS rule that says 'Everything not in the modal is display: none'. You don't need React or Vue for that. Just a line of CSS.
DerJacques 8y ago
You can do that, but the visitor's scroll position would be reset, when the modal is closed.
- calibas 8y ago
  Could save it and restore it, though that may create some other issues.

TekMol 8y ago

My feeling is that it's only hard because the author tried to create a solution that fits his needs by piling more and more external code on top of each other. I would expect that when you tinker a bit with plain CSS, you will find a simple solution.

deleted 8y ago

[deleted]

ifightcrime 8y ago

tabindex?

9dev 8y ago

Oh come on. This task isn't hard of itself, the author just seems to lack experience with the web platform. A responsive modal that goes full-screen on mobile isn't really complex. Just set vertical overflow on the main content element to hidden and auto on the modal container, so the user can only scroll that when its open. Then, focus the first input in the modal if any, or listen to keyup if you really messed with the tabindex. I've implemented this in a few projects, two of them with Vue. That sort of stuff isn't magic, just frontend work.

chiefalchemist 8y ago
Any chance you can share a link to a pen?

g_b 8y ago

I wish this full-screen modal feature would disappear. I've lost track on the number of times I pressed back to close a modal on mobile because I thought it was a new page. Please make it clear that a dialog is a dialog.

slow_donkey 8y ago
This is interesting, in a native app the modal would close but unintuitively most sites don't push modals to history.
- TeMPOraL 8y ago
  In a native app, such modal would be pushed on the activity stack (on Android; I assume iOS has a similar pattern). It would essentially be a native equivalent of a new page. Modern web developers are, for some reason, more afraid of having multiple pages than they are of black death.
  - saagarjha 8y ago
    iOS does not push modals onto the navigation stack by default.
    - half-kh-hacker 8y ago
      To be fair, iOS doesn't have a universal 'back' button, so you wouldn't reach for it to exit a modal anyway.
      - saagarjha 8y ago
        Sure, but the general guideline for modals is to have a "Cancel" or "Done" bar button item somewhere to exit. This is a different action than popping a view controller off the navigation stack.
stereobooster 8y ago
Thanks for this response, this is very helpful. I will update post with this concern

RyanShook 8y ago

What use case would this ever have?

sseppola 8y ago
It’s basically a way to have stack navigation on the web, so you can keep the context behind the content it spawned. This is used all the time in native apps, so why not on web? It seems so basic but it’s not straight forward at all to implement in a consistent way across browsers. After trying for a while myself, and not wanting to sink days into it, I’ve given up on finding the perfect solution for now. Going to try the 4th step here, but I believe there’s always a new modal bug waiting to be discovered.
- RyanShook 8y ago
  I guess I just don’t understand the full screen part. I get why modules can be good but even in a native app you have some reference that you’re still on the same screen. Maybe I’m missing something still...

tdy721 8y ago

I think there is a reason this is hard. This is a security issue. You are masking the URL of the site, Imagine using an iframe inside the modal. This code is exactly what you would need to spoof users if you got JS execution on a host that isn't yours.

nerflad 8y ago

In the previous century when web technologies were more primitive, modal dialogs were created in new browser windows. We all remember pop-ups and what a horrid experience that was. Developers (and spammers) abused this behavior so much that browsers now reflexively prevent pages from opening new windows in most cases. I leave almost any site that interrupts me with a full screen modal dialog, especially if it's a prompt to subscribe to a newsletter. This abuse has become the norm. I have even seen desktop software adopting this behavior. A licensed copy of Guitar Pro 6 will interrupt you with a fullscreen ad for Guitar Pro 7. Unforgivable. Respect what the user is there for, and you might earn their business. Edit: I recognize that there are some positive, responsible uses for this technique (extending forms/controls; search suggestions, assist the user rather than interrupt) and good examples are shown here. Please excuse the Sunday rant.

sdegutis 8y ago
Sites do this because 90% of users don’t leave over modal popups and doing it increases engagement in enough cases to warrant keeping it. It’s completely reasonable for a product to advertise for a newer version. How else would you know there’s a new version that you might actually decide you want to buy? And you don’t have to buy it.
- nerflad 8y ago
  > It’s completely reasonable for a product to advertise for a newer version. No argument from me there. A notice on the splash screen, even a tool tip at start-up would work fine, but it was a full screen advertisement, several minutes after start-up, which stopped playback (!) without warning. These interruptions are what I find completely unacceptable, and I believe they stem from fundamentally misunderstanding what the user is there for, or outright disrespect.
  - TeMPOraL 8y ago
    Notice on the splash screen, a tool tip at start up, a popup at startup (anyone remembers "Tip of the day" dialogs?), a modeline/status bar (like e.g. IntelliJ IDEA does), ... there are plenty of well-established UI patterns for placing such information unobtrusively. As you said, firing up a modal in the middle of your work is unacceptable, and outright disrespectful.

rhizome 8y ago

Not hard enough, apparently.