
Fullscreen mobile modal: how hard can it be? - stereobooster
https://github.com/stereobooster/react-modal-experiment
======
g_b
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
This is interesting, in a native app the modal would close but unintuitively
most sites don't push modals to history.

~~~
TeMPOraL
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
iOS does not push modals onto the navigation stack by default.

~~~
half-kh-hacker
To be fair, iOS doesn't have a universal 'back' button, so you wouldn't reach
for it to exit a modal anyway.

~~~
saagarjha
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.

------
mattlondon
"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
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
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
> _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.

------
nerflad
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
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
> 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
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.

------
hamandcheese
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.

------
IshKebab
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.

------
tdy721
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.

------
TekMol
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.

------
calibas
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.

~~~
DerJacques
You can do that, but the visitor's scroll position would be reset, when the
modal is closed.

~~~
calibas
Could save it and restore it, though that may create some other issues.

------
9dev
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
Any chance you can share a link to a pen?

------
dmitrygr
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.

~~~
reaperducer
_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._

I am blessed to work for a company where web standards, accessibility, and
page load speed are considered more important than the whims of my millennial
boss, or the marketing department.

That's not to say I don't have my share of "I want this to look like a web
site that I would want to visit" and "Can you do this cool thing like TMZ?"
moments. I remind them that we don't make web sites for them or me, but for
our visitors.

If that doesn't work, I pull out the memos showing that the legal department
is on my side, and somehow groks the whole web bloat problem.

Can't wait to finally deploy the new site and replace the old JS/SPA + library
+ framework + polyfill + jquery + ... + ... + ... site the last guy built.

~~~
chiefalchemist
Good website are harder, but it's people (with a lack of empathy for the
actual users / visitors) that make it even harder; sometimes even impossible
(i.e., project fails).

------
rhizome
Not hard enough, apparently.

------
RyanShook
What use case would this ever have?

~~~
sseppola
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
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...

------
egfx
this feels really weird on desktop

------
ifightcrime
tabindex?

