Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fullscreen mobile modal: how hard can it be?

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Fullscreen mobile modal: how hard can it be?

#21

Post by lucideer »

mattlondon wrote: post #2

"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. O…

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.

Re: Fullscreen mobile modal: how hard can it be?

#22

Post by chiefalchemist »

reaperducer wrote: post #13
dmitrygr wrote: post #5

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 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…

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

Re: Fullscreen mobile modal: how hard can it be?

#25

Post by Theodores »

Nadya wrote: post #11
Theodores wrote: post #8

Earlier quoted context omitted.

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

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?

Re: Fullscreen mobile modal: how hard can it be?

#26

Post by 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.

Re: Fullscreen mobile modal: how hard can it be?

#27

Post by 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.

Re: Fullscreen mobile modal: how hard can it be?

#28

Post by Nadya »

Theodores wrote: post #25
Nadya wrote: post #11

Earlier quoted context omitted.

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…

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 w…

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]

[0] https://www.growingwiththeweb.com/2013/01/let-me-pinch-to-zo...

[1] https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogE...

Re: Fullscreen mobile modal: how hard can it be?

#30

Post by DerJacques »

calibas wrote: post #14

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.

You can do that, but the visitor's scroll position would be reset, when the modal is closed.
Post reply on HN