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.
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 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
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.
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.
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
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!
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.
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.
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
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 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.
If Facebook, Twitter, Instagram, and Pinterest use modals, I'm going to use modals.
"What users expect" will almost always be the best UX.
> 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.
Especially when the modal covers half of the page, with a form with dozens fields.
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. :)
Title on HN needs to be changed.
