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

Forms in modals: UX case

user-interface.io

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Forms in modals: UX case

#41

Post by peterangular »

Akcium wrote: post #9

It's my article. I just got a traffic spike, so I noticed it's here. I guess the person who posted it checked out the URL that I have, and previously I indeed called it something like stop using modals. The thing is that they are really OVERused. And right now I'm working on a project where we have modals inside modals and sometime even popup as a third layer. I cannot influence these decisions, but it's TOO much.

> right now I'm working on a project where we have modals inside modals

I know this is just expressing my frustration into the void... but how does that even get past a professional review?

I've always been under the impression that best practices for modals is to never nest them, and/or never have multiples open at the same time because at that point you're effectively making a nesting doll UIX, or worse... creating a window manager in the browser.

Been seeing this happen more and more with the advent of the SPA - people jamming way too much functionality into modals because god forbid our users experience page navigation /s

Re: Forms in modals: UX case

#42

Post by petepete »

msdrigg wrote: post #37
micromacrofoot wrote: post #22

Earlier quoted context omitted.

Users don't care if it's a modal or not, they just want it to work.

Exactly. Google calendar modals: excellent. Outlook web modals: gross

Even in Google Calendar they're not ideal. And the 'create an appointment wherever you click' and 'click the screen outside of the modal to close it' features don't get along.

Re: Forms in modals: UX case

#43

Post by arkitaip »

spaetzleesser wrote: post #4

I feel the UI/UX guys are slowly rediscovering issues that desktop operating system like Windows and Mac solved 25 years ago. But instead of using a standard implementation everybody rolls their own version with its own of quirks.

All of tech is like that.

Re: Forms in modals: UX case

#44

Post by tshaddox »

derefr wrote: post #40
tshaddox wrote: post #28

Earlier quoted context omitted.

That’s a wild misuse of language. It’s semantic nonsense to say there’s something you must do but should not do.

A general "should" statement in English — e.g. "you shouldn't use modals" — recommends (assigns utility weight to) a concept; it's not an imperative command to do (or not do) that thing, right now, in the specific situation you're in. This is in contrast to "it would be best to do X" when used in equivalent contexts. While "you should" conveys an absolute judgement on the general / global / context-free utility of an…

I’m not confused about what any of these words mean.

> You shouldn't climb over an electrified fence. You might have to — it might be best to do so — if you're being chased by a bear.

And in that case you should climb over the electric fence. It’s nonsense to say that you “must” or “have to” climb over the electric fence but that you “should not.” The first sentence is, as is abundantly clear to all English speakers, a shorthand for “you shouldn’t climb over an electric fence except for very rare cases where it will be obvious to you that you’re encountering an exception.”

Re: Forms in modals: UX case

#45

Post by butz »

> Now, in some browsers and OS the scroll is not not visible until you hover the modal or even until you don't try to scroll its content.

Why? I understand in some cases screen estate might be limited, but when OS is hiding scrollbars on huge 1920px or wider screen where input is mouse and/or keyboard - that's just mean.

Re: Forms in modals: UX case

#46

Post by clairity »

chomp wrote: post #31
Akcium wrote: post #13

Earlier quoted context omitted.

I even remember I made a tweet for fun https://twitter.com/vponamariov/status/1528758532182515714 when I started working on a project that had up to 3(!!) modals inside. It's not only hard for users, it's hard for developers, when they have scroll issues, when they should update each other, when you should keep track of URL (what if user hits F5 or wants to share these...modal hell)

I personally also find it hard getting accessibility to work right. Depending on the modal and js library used to generate it, getting aria tags to work right always feels difficult.

the new-ish tag with a Close inside, combined with styling the pseudo-element ::backdrop, comes very close to being javascript-less built-in solution for modals. you still need js to trigger opening the dialog though, but that can be as simple as document.querySelector('#dialog').showModal()

apparently 's still needs some accessibility/interaction improvements to be a first-class solution, but it's getting there: https://nolanlawson.com/2022/06/14/dialogs-and-shadow-dom-ca...

Re: Forms in modals: UX case

#47

Post by lotw_dot_site »

So, this is about popups inside of browser windows, is it? And not about popups in Windows/Mac/Linux desktops? Because I couldn't start making up my mind until close to the end of the article.

FWIW, I do make some use of modals in Linux on the Web (source code, admittedly somewhat sloppy: https://github.com/linuxontheweb/LOTW/blob/main/root/code/mo...). In fact, I just tried to make a post about a new app I'm working on (that happens to use them) called "HackerNotify": https://news.ycombinator.com/item?id=32358782

Re: Forms in modals: UX case

#48

Post by isleyaardvark »

mypastself wrote: post #23

Not necessarily disagreeing with the post’s thesis, but if we remove the overlay click behavior and keep the close button, doesn’t this resolve the whole “accidental background row click” issue? Losing the input by accidentally clicking a single button on the page is fine - you’re just as likely do the same thing on a separate page.

I largely agree with the article but that example wasn't a great one.

I don't remember the last time I've seen a modal where it was possible to have an "accidental background row click". Industry standard has been: modals have a modal on top and a full screen modal overlay between the modal and the content (usually darkening the content). Click events are handled by the overlay and do not make it through to the content underneath, and the only thing the overlay does onClick is close out the modal. It's so common I don't know any user who would expect different behavior. If they've used a modal before they would expect clicking on the overlay would close it out without saving the data. Modals are pretty big, I don't think an accident like that would be common.

Re: Forms in modals: UX case

#49

Post by collaborative »

deckard1 wrote: post #27
collaborative wrote: post #14

Earlier quoted context omitted.

Actually there is. HTML5 Canvas state gets lost. It's the only case, but I know from experience that it can be very significant depending on the application

you're still in the SPA. You generally need some sort of painters algorithm to repaint the canvas anyway. When the canvas comes back you would just repaint it from JS memory. Canvas in particular has issues web devs have to deal with beyond their "normal" duties. Accessibility is simply not even a thing in canvas. Google Docs had to implement an entire parallel invisible DOM structure to emulate what they draw on the…

Sure. But in that case I think a modal makes more sense. A page with a complex canvas that has state ideally should be the last page in the SPA navigation. Nothing should be able to "go back" to that page. What you describe is more a way to "go forward" to that page, since you're essentially reloading the canvas (which is fine but adds overhead in terms of state and response time)

Re: Forms in modals: UX case

#50

Post by moistly »

arkitaip wrote: post #43
spaetzleesser wrote: post #4

I feel the UI/UX guys are slowly rediscovering issues that desktop operating system like Windows and Mac solved 25 years ago. But instead of using a standard implementation everybody rolls their own version with its own of quirks.

All of tech is like that.

It’s job security.
Post reply on HN