[HN Gopher] Forms in modals: UX case
___________________________________________________________________
Forms in modals: UX case
Author : flothebre
Score : 59 points
Date : 2022-08-05 16:55 UTC (6 hours ago)
(HTM) web link (user-interface.io)
(TXT) w3m dump (user-interface.io)
| 1-more wrote:
| 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.
| karaterobot wrote:
| > 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.
| KerrAvon wrote:
| 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.
| spaetzleesser wrote:
| 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.
| arkitaip wrote:
| All of tech is like that.
| moistly wrote:
| It's job security.
| ypeterholmes wrote:
| 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.
| dang wrote:
| Title changed now. More at
| https://news.ycombinator.com/item?id=32359457
| rawoke083600 wrote:
| Pedantic if you ask me.
| jaywalk wrote:
| 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.
| gnabgib wrote:
| 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)
| derefr wrote:
| 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. :)
| tshaddox wrote:
| That's a wild misuse of language. It's semantic nonsense to
| say there's something you _must_ do but _should not_ do.
| derefr wrote:
| 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?
| tshaddox wrote:
| 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_."
| detaro wrote:
| ... you can't remove relevant words from a sentence and
| then complain it is semantic nonsense afterwards.
| lotw_dot_site wrote:
| 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
| m1117 wrote:
| Why not writing this article in a modal? Also, maybe rename
| Windows to Modals?
| subpixel wrote:
| 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.
| defanor wrote:
| 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.
| schwartzworld wrote:
| 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.
| defanor wrote:
| 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.
| Akcium wrote:
| YES
|
| Especially when the modal covers half of the page, with a
| form with dozens fields.
| collaborative wrote:
| 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
| deckard1 wrote:
| 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.
| collaborative wrote:
| 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)
| mypastself wrote:
| 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.
| isleyaardvark wrote:
| 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.
| Akcium wrote:
| 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.
| dang wrote:
| (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)
| jjoonathan wrote:
| 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.
| folkhack wrote:
| > 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
| jordanmorgan10 wrote:
| 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.
| Akcium wrote:
| 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)
| chomp wrote:
| 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.
| clairity wrote:
| 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...
| athenot wrote:
| 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
| janmarsal wrote:
| 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.
| butz wrote:
| > 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.
| zeptonix wrote:
| 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.
| encoderer wrote:
| 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.
| JLCarveth wrote:
| "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.
| cosmiccatnap wrote:
| Friends don't let friends commit modals
| nawgz wrote:
| 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.
| malfist wrote:
| The title here is misleading. Actual title is: "Forms in
| modals: UX case"
| debacle wrote:
| 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.
| micromacrofoot wrote:
| Users don't care if it's a modal or not, they just want it to
| work.
| msdrigg wrote:
| Exactly.
|
| Google calendar modals: excellent.
|
| Outlook web modals: gross
| petepete wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-05 23:02 UTC)