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

11–20 of 51 posts

Re: Forms in modals: UX case

#11

Post by Akcium »

schwartzworld wrote: post #10
defanor wrote: post #8

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 whateve…

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.

YES

Especially when the modal covers half of the page, with a form with dozens fields.

Re: Forms in modals: UX case

#13

Post by Akcium »

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.

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)

Re: Forms in modals: UX case

#14

Post by collaborative »

schwartzworld wrote: post #10
defanor wrote: post #8

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 whateve…

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.

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

Re: Forms in modals: UX case

#15

Post by JLCarveth »

"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.

Re: Forms in modals: UX case

#16

Post by jaywalk »

ypeterholmes wrote: post #6

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.

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.

Re: Forms in modals: UX case

#17

Post by debacle »

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.

Re: Forms in modals: UX case

#18

Post by gnabgib »

ypeterholmes wrote: post #6

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.

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)

Re: Forms in modals: UX case

#19

Post by derefr »

ypeterholmes wrote: post #6

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. :)

Re: Forms in modals: UX case

#20

Post by karaterobot »

> 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.

Post reply on HN