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.
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.
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.
"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.
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
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.
> 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.
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.
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.
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.
> 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
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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).
...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.
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?"
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?
On the smaller screens - I take the lack of reflowing as good design. I wouldn't want to the site to reflow when all I was trying to do was bump up the font size to read something easier as it would make it impossible to tell where on the site I am. Horizontally panning on a phone isn't nearly as annoying as it is on desktop - and the difficulty of horizontal scrolling is why page reflow is a good thing for desktop: it prevents the need to scroll horizontally.
I'd never adjust my phone's font size - I pinch zoom, literally, every page I visit that allows me to do so on my phone because it's a very selective zoom. It allows me to focus on one part of the site, read small text in just one section (where the text in other sections might be fine), or makes it easier to click a link, button, or what have you. I'm not talking about adjusting font size - I'm talking about zooming. Almost nobody mucks around with settings, it's something like 5%~ of people change the default settings and the other 95%~ never change a thing.
Being able to change the font size of a modal is about usability [0]. If I can't zoom in on the tiny font because they've broken pinch zooming in order to place the modal on the page I'm closing the site.
ps. The actual proper way to do this is with a dialog modal [1]
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.
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...
Please make it clear that a dialog is a dialog.