Forms in modals: UX case(user-interface.io)
user-interface.io
Forms in modals: UX case
https://user-interface.io/why-you-probably-shouldnt-put-forms-in-modals/
50 comments
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)
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 <dialog> tag with a <form method="dialog"><button>Close</button></form> 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 <dialog>'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...
apparently <dialog>'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...
> 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
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
The same is true of iOS - they are used almost by default in many apps without considering the consequences. It’s a context switch, and developers often forget that.
Who turned the Ubuntu save dialog into a full screen modal? Is there a way to fix it?
It's so painful that I might even get of my ass and contribute, but knowing open source, it's equally likely that this is a politics problem, not a code problem.
It's so painful that I might even get of my ass and contribute, but knowing open source, it's equally likely that this is a politics problem, not a code problem.
(The submitted title was "You Shouldn’t Use Modals" but we changed it to the article title, which is less baity, per https://news.ycombinator.com/newsguidelines.html)
> What's the difference between a dedicated page that has a link "return back to the table", and a modal that you cannot close by clicking on the overlay. And the only way to close it is by clicking the close button/icon which in fact returns you back to the table as well?
You don't have to reload the table, for one thing. In the application I work on, we have to dig through a lot of data to build a given table, and we do it every time the page is shown. It can take 3-4 seconds, sometimes more. You also want to maintain your scroll position (as noted in the article), and to that I'd also add that you want to keep your sorting, filtering, and pagination selections too. I don't think that's very hard to store, but the article seems to think it is when it talks about linking to a modal, so I bring it up as a consideration.
There's also situations when a user just clicks on a button, wondering what it will do. If that takes them to another page, and they lose their context, that's not great. If it just opens a modal they can easily dismiss, that's much less anxious for them. "Safe exploration" is what I think Jakob Neilsen calls it.
I also don't think that hiding the background of a page behind a semi-opaque scrim is part of the definition of a modal, nor is being centered. The article says you can't really see the content of the page behind a modal, but that's just an implementation decision. A modal window is a window that blocks the user from taking other actions before input is given. You can easily show the user what's on the page and still be in a modal.
In general, I think that if you've got a big form with a lot of fields that doesn't require reference to some other page to fill out, you should send the user to another page, because it's probably easier for them. If you've got like, one or two questions to ask them, there's really nothing wrong with a modal window most of the time.
You don't have to reload the table, for one thing. In the application I work on, we have to dig through a lot of data to build a given table, and we do it every time the page is shown. It can take 3-4 seconds, sometimes more. You also want to maintain your scroll position (as noted in the article), and to that I'd also add that you want to keep your sorting, filtering, and pagination selections too. I don't think that's very hard to store, but the article seems to think it is when it talks about linking to a modal, so I bring it up as a consideration.
There's also situations when a user just clicks on a button, wondering what it will do. If that takes them to another page, and they lose their context, that's not great. If it just opens a modal they can easily dismiss, that's much less anxious for them. "Safe exploration" is what I think Jakob Neilsen calls it.
I also don't think that hiding the background of a page behind a semi-opaque scrim is part of the definition of a modal, nor is being centered. The article says you can't really see the content of the page behind a modal, but that's just an implementation decision. A modal window is a window that blocks the user from taking other actions before input is given. You can easily show the user what's on the page and still be in a modal.
In general, I think that if you've got a big form with a lot of fields that doesn't require reference to some other page to fill out, you should send the user to another page, because it's probably easier for them. If you've got like, one or two questions to ask them, there's really nothing wrong with a modal window most of the time.
That was a point I remembered from Apple's Human Interface guidelines. From the 1987 edition, on modal dialog boxes:
Because it restricts the user's freedom of action, you should use this type of dialog box sparingly. In particular, the user can't choose a menu item while a modal dialog box is up and therefore can do only the simplest kinds of text editing. For these reasons, the main use of a modal dialog box is when it's important for the user to complete an operation before doing anything else.
Source: https://andymatuschak.org/files/papers/Apple%20Human%20Inter... p.59
Because it restricts the user's freedom of action, you should use this type of dialog box sparingly. In particular, the user can't choose a menu item while a modal dialog box is up and therefore can do only the simplest kinds of text editing. For these reasons, the main use of a modal dialog box is when it's important for the user to complete an operation before doing anything else.
Source: https://andymatuschak.org/files/papers/Apple%20Human%20Inter... p.59
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.
Windows 95 is unironically the pinnacle of UX design.
It uses beveled borders and colors to allow users to consistently differentiate between:
* A button
* A focused button
* A depressed button
* An input field
* A scroll bar
* A menu item
* A selected menu item
Each has a distinct and unmistakable visual identity that borrows from items and metaphors every human has encountered. Widgets are large enough to press. You don't need to guess or pixel hunt. Many buttons have both icons and labels.
It's a marvel of ingenuity and something I've not seen accomplished in any UI framework from this side of 2010.
It's especially stark in comparison to interfaces that look like this: https://imgur.com/IHjQEzM
Like, why do I need to hover over something to figure out if it is a button? Why do buttons look like menus? Why are there buttons in the input field? Is it an input field? I can barely tell, everything is nearly the same shade of grey. And why are all the buttons so incredibly tiny and why don't they have labels? I have a 4K screen. I have plenty of pixels.
You maniacs! You blew it up!
It uses beveled borders and colors to allow users to consistently differentiate between:
* A button
* A focused button
* A depressed button
* An input field
* A scroll bar
* A menu item
* A selected menu item
Each has a distinct and unmistakable visual identity that borrows from items and metaphors every human has encountered. Widgets are large enough to press. You don't need to guess or pixel hunt. Many buttons have both icons and labels.
It's a marvel of ingenuity and something I've not seen accomplished in any UI framework from this side of 2010.
It's especially stark in comparison to interfaces that look like this: https://imgur.com/IHjQEzM
Like, why do I need to hover over something to figure out if it is a button? Why do buttons look like menus? Why are there buttons in the input field? Is it an input field? I can barely tell, everything is nearly the same shade of grey. And why are all the buttons so incredibly tiny and why don't they have labels? I have a 4K screen. I have plenty of pixels.
You maniacs! You blew it up!
If I had a dollar for every time I encountered a modal, tried to close it with `esc`, and fired up the settings for the SquareSpace site I unknowingly was visiting, I'd be able to fill up a tub with bills and roll around in them.
"On the one hand we might save the data that they have just inputted. But what if the user selects another row? We should display data related to the row selected. Thus, it won't work."
At least in React, upon initializing the Modal state is passed to the modal through props. If the user clicks out of the modal, a single value in the state is changed, the rest of the data the user entered in the modal is still there. If the user opens another row, new data should be loaded into the modal. Perhaps I am not seeing the problem with this specific use case.
At least in React, upon initializing the Modal state is passed to the modal through props. If the user clicks out of the modal, a single value in the state is changed, the rest of the data the user entered in the modal is still there. If the user opens another row, new data should be loaded into the modal. Perhaps I am not seeing the problem with this specific use case.
It's like popup windows all over again. I bet once we cure the internet from modals the next gen will just come up with something equally annoying.
The title of the article is "Forms in modals: UX case". Nowhere in the article does it say you shouldn't use modals as an absolute.
> 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.
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.
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
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
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.
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.
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.
I hate modals. I think they're bad UX. I think they're antiquated. I think they have all the problems outlined in this essay.
If Facebook, Twitter, Instagram, and Pinterest use modals, I'm going to use modals.
"What users expect" will almost always be the best UX.
If Facebook, Twitter, Instagram, and Pinterest use modals, I'm going to use modals.
"What users expect" will almost always be the best UX.
Users don't care if it's a modal or not, they just want it to work.
I will read the article, but I must say first. As a UI developer, modals have many good purposes, and make it a lot simpler to develop flows where you just need to briefly redirect focus or make a confirmation. Generating new layouts where you can correctly and efficiently draw user attention & find screen space is not always easy, so I will be interested what recommendations are given in such situations.
The title here is misleading. Actual title is: "Forms in modals: UX case"
I'm annoyed by modals on web pages (along with any excessive JS) as much as the next person, but:
> What's the difference between a dedicated page that has a link "return back to the table", and a modal that you cannot close by clicking on the overlay. And the only way to close it is by clicking the close button/icon which in fact returns you back to the table as well?
I think they tend to happen because (for whatever reason) people make SPAs, which is precisely about having everything on a single page; then opening a new one is slow (thanks to multi-megabyte JS) and contrary to the whole approach. And when you propose to avoid SPAs, it's met with "but Google does that", "that's modern", and so on.
Edit: Actually I've misinterpreted the article (and "dedicated page") and mixed up modals with SPAs, as pointed in one of the replies.
> What's the difference between a dedicated page that has a link "return back to the table", and a modal that you cannot close by clicking on the overlay. And the only way to close it is by clicking the close button/icon which in fact returns you back to the table as well?
I think they tend to happen because (for whatever reason) people make SPAs, which is precisely about having everything on a single page; then opening a new one is slow (thanks to multi-megabyte JS) and contrary to the whole approach. And when you propose to avoid SPAs, it's met with "but Google does that", "that's modern", and so on.
Edit: Actually I've misinterpreted the article (and "dedicated page") and mixed up modals with SPAs, as pointed in one of the replies.
There's not reason you can't have a "dedicated page" with a back button (or even respecting the real back button) in an SPA. Modals are created by lazy designers, devs only implement them.
Indeed, my bad, and it makes more sense upon re-reading it with just SPAs in mind (instead of picturing/comparing a modals-heavy SPA and a regular bunch of pages). I just have a strong association of modals with SPAs, but they don't necessarily go together.
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 canvas when they were switching over to the canvas. And, of course, that DOM structure has to be in sync with canvas.
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 canvas when they were switching over to the canvas. And, of course, that DOM structure has to be in sync with canvas.
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)
YES
Especially when the modal covers half of the page, with a form with dozens fields.
Especially when the modal covers half of the page, with a form with dozens fields.
It might be better now but for years forms in modals were a huge pain in the ass on tablets. Basically the modal pops up, focuses the form, which opens the keyboard, which pushes half your modal off screen.
Why not writing this article in a modal?
Also, maybe rename Windows to Modals?
Modals are a tool. Like any tool, they may or may not be the right tool for any particular situation, and it is possible to over- or underuse. Pretty easy, really.
Friends don't let friends commit modals
If you do modals MAKE SURE you capture focus correctly. You should not be able to tab to controls behind the backdrop. There is so much you have to do for modal controls.
Title is misleading. The article basically covers specific cases where modals aren't a great solution, but the title suggests they are NEVER useful. Clickbaity if you ask me.
It doesn't suggest that they're never useful. It says you that you shouldn't use them — i.e. that using them is bad.
There are lots of things that you generally shouldn't do, but sometimes must do under certain circumstances. Doing something you shouldn't because you must, doesn't excuse you from the fact that you're doing something "bad"; it just means that "doing something bad" is the best/only option you have at that point.
Compare/contrast: jerking a dog's collar to pull it back from running in front of a car. You shouldn't abuse animals; but in that specific case, you "must" do something that will hurt the dog a small amount, to prevent it from experiencing much greater harm. Doesn't mean you're not doing something bad, though! It'd be better to have planned ahead so you wouldn't be in the situation where you'd have to jerk the dog's collar in the first place.
You shouldn't use modals. Sometimes you end up in a situation where you must. That doesn't mean they're "not bad" in that situation; they're still bad! And as such, it'd be better to plan your UX, so that you don't end up in a situation where modals are the best/only solution to your problem. :)
There are lots of things that you generally shouldn't do, but sometimes must do under certain circumstances. Doing something you shouldn't because you must, doesn't excuse you from the fact that you're doing something "bad"; it just means that "doing something bad" is the best/only option you have at that point.
Compare/contrast: jerking a dog's collar to pull it back from running in front of a car. You shouldn't abuse animals; but in that specific case, you "must" do something that will hurt the dog a small amount, to prevent it from experiencing much greater harm. Doesn't mean you're not doing something bad, though! It'd be better to have planned ahead so you wouldn't be in the situation where you'd have to jerk the dog's collar in the first place.
You shouldn't use modals. Sometimes you end up in a situation where you must. That doesn't mean they're "not bad" in that situation; they're still bad! And as such, it'd be better to plan your UX, so that you don't end up in a situation where modals are the best/only solution to your problem. :)
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 action, "it would be best to" conveys a relative utility-ranking of actions presented as (perhaps implicit) options.
Something can be the best option in some scenarios (= relative contextual ranking), but still a bad option in global static ranking (= absolute judgement), and so would be something you "shouldn't" do.
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. But it's still anti-recommended as a course of action. You should avoid any series of choices that results in you having to climb an electrified fence, because even when it's the best course of action, any future where you have chosen to climb an electrified fence, is going to suck compared to one where you didn't have to do so.
You should brush your teeth before sleeping. In the situation where you're hiding up a tree from the aforementioned bear, it would be best to not do so. But that doesn't remove the general recommendation that you "should" be brushing your teeth; and doesn't remove the twinge of regret you get for not being able to do the thing you "should" be doing.
(I think you might be confusing "should" for the similar word "shall" — a thing you must do but shall not do would indeed be semantic nonsense.)
Alternately, if your argument is that you need the words "in general" in the statement to make it true — no, you don't. "In general" is the default context for "should" statements, and especially ones not addressed to a specific speaker. If a "should" statement is made without reference to/knowledge of you or your specific context, how could that statement possibly be in reference to what you specifically should do in your situation — vs. being a generally-agreed-upon context-free absolute value-judgement of the concept?
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 action, "it would be best to" conveys a relative utility-ranking of actions presented as (perhaps implicit) options.
Something can be the best option in some scenarios (= relative contextual ranking), but still a bad option in global static ranking (= absolute judgement), and so would be something you "shouldn't" do.
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. But it's still anti-recommended as a course of action. You should avoid any series of choices that results in you having to climb an electrified fence, because even when it's the best course of action, any future where you have chosen to climb an electrified fence, is going to suck compared to one where you didn't have to do so.
You should brush your teeth before sleeping. In the situation where you're hiding up a tree from the aforementioned bear, it would be best to not do so. But that doesn't remove the general recommendation that you "should" be brushing your teeth; and doesn't remove the twinge of regret you get for not being able to do the thing you "should" be doing.
(I think you might be confusing "should" for the similar word "shall" — a thing you must do but shall not do would indeed be semantic nonsense.)
Alternately, if your argument is that you need the words "in general" in the statement to make it true — no, you don't. "In general" is the default context for "should" statements, and especially ones not addressed to a specific speaker. If a "should" statement is made without reference to/knowledge of you or your specific context, how could that statement possibly be in reference to what you specifically should do in your situation — vs. being a generally-agreed-upon context-free absolute value-judgement of the concept?
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.”
> 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.”
... you can't remove relevant words from a sentence and then complain it is semantic nonsense afterwards.
Yep, and it got me. I clicked thinking "how can they say you shouldn't use modals when there are definitely great use cases for them?" and of course, they're not saying that at all.
Title on HN needs to be changed.
Title on HN needs to be changed.
The editorialized title by @flothebre you mean, as @KerrAvon points out.. that's not the current title (nor possibly the prior one based on slug, it looks like the article was last updated July/22)
Title changed now. More at https://news.ycombinator.com/item?id=32359457
Pedantic if you ask me.
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.