Forms in modals: UX case
user-interface.io
user-interface.io
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)
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...
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.
Google calendar modals: excellent.
Outlook web modals: gross
> 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.
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.
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. :)
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?
> 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.”
Title on HN needs to be changed.