The problem problem with modals in a web page context is that they go against the statelessness of the html request/response model. They end up building up a lot of local state in the client, both model state as well as UI state, that eventually need to be reconciled with the server. If the user closes the modal, is the data saved for later? Does the form reset? Does the server know anything about it? If it is a wizard, were previous steps saved? And so on.
After many years of working on and with intercoolerjs/htmx, I now typically prefer inline editing and wizards, to a modal solutions. It fits better with the web model, allows for proper URLs, etc.
The inline-edit demo from htmx is a good example of something that might be implemented as a modal by some developers, but works very well as an inline-edit UI instead:
I’ll try to condense it more. If you play a video game and a modal pops up, it takes you out of the experience. It’s the same as (hypothetically) me having to go into my HN profile to find a list of comments I upvoted to then go ahead and downvote (versus just having the downvote button next to the post).
Can’t teach this stuff, you basically need to be confronted by tons of bad UI in software, games, physical printed forms, processes, until you get a good sense of taste.
I can’t teach HN devs that my thumb covers both the upvote and downvote button on mobile. Can’t teach it.
Imagine you're playing a game and you click "Options" and a modal window pops up with the options you can tweak. Or an endless image gallery where clicking an image enlarges it inside a modal that you can dismiss to resume scrolling without losing your place.
It didn't wrongfully force you out of experience, it's what you wanted.
Seems like we're talking about getting in the way of users where crappy modals are just one way of doing that. Navigating to a new page seems even more jarring in TFA examples.
Yes but have you seen software - almost anything that's been developed since the growth of mobile platforms has basically done the exact opposite of what that field of science teaches.
The problem problem with modals in a web page context is that they go against the statelessness of the html request/response model. They end up building up a lot of local state in the client, both model state as well as UI state, that eventually need to be reconciled with the server. If the user closes the modal, is the data saved for later? Does the form reset? Does the server know anything about it? If it is a wizard, were previous steps saved? And so on.
After many years of working on and with intercoolerjs/htmx, I now typically prefer inline editing and wizards, to a modal solutions. It fits better with the web model, allows for proper URLs, etc.
The inline-edit demo from htmx is a good example of something that might be implemented as a modal by some developers, but works very well as an inline-edit UI instead:
https://htmx.org/examples/click-to-edit/
(NB: I was lazy and did not make the URL update as I should have)