[zamalek]

Modals that blocks focus to an entire browser window aren't really a good idea (I'm of the opinion that they are almost always a shitty idea, but that's harder to argue). People have multiple tabs open, and what if another tab contains information that your user needs to complete your dialog.

You also have to be incredibly careful about how much visual control you allow over an actual dialog - especially making it look like the host OS. People get bamboozled by shitty in-browser fake virus alerts all the time, now add a real dialog, with real looks, that the user is forced to interact with, and you have a slam-dunk.

[tredre3]

> Modals that blocks focus to an entire browser window aren't really a good idea (I'm of the opinion that they are almost always a shitty idea, but that's harder to argue).

Good news then, because alert/prompt/confirm do not block the window in any modern browser!

In Firefox it only blocks the viewport of the current tab, so it behaves exactly like a DIY modal. In Chromium browsers it does pop over part of the browser UI, but it still doesn't block the window; You interact with the tab bar, address bar, menu, etc.

[DaiPlusPlus]

> because alert/prompt/confirm do not block the window in any modern browser!

Correct: they don't block the browser's desktop UI thread - but they do block the web-page's thread - and for abvout the past decade we can't move alert/prompt/confirm prompts: Chrome forces them to appear at the very top, dead-centre, and you can't scroll the page while it's open.

[saagarjha]

I mean that's how alerts work on almost every other platform

[berkes]

As can be seen when attaching an image. When you have to look up something in another tab. I now have to first close the file picking modal, before I can use anything in the browser.

It might be Gnome/Firefox only, IDK. But this modal thing is very bad UX.

The alternative is also bad, TBH: where the file picker is now gone somewhere in the sea of open windows. Maybe the middle-ground, where the file-picker is "attached" to the one tab that opened it, and goes away once other tabs and window chrome is engaged, but I guess thats hard to do in a WM?

[quantadev]

If you don't think "Modals" are needed that just means you've never needed one yourself.

There are lots of cases where they're almost mandatory. I have an app where some interactions will end up with 4 to 5 layers of stacked modals. Like you edit a node, then you open the sharing dialog to share it, then you need pick a person to share to, then you need to add a new person, then you need to select who to add, etc. Most websites are trivial and thus don't need dialogs at all but there are some which are full featured apps (like mine) where Modals are a critical thing to have.

[Digit-Al]

I spent years designing interfaces for Windows Forms applications. There is no neccessity for sharing to be a dialog - it should be a wizard; and could even open in a new tab in a web application. Then the user can cancel either by pressing the cancel button (which would close the tab) or by just closing the tab. Selecting who to add, or adding a new person then just become pages in the wizard.

[quantadev]

Yeah everything theoretically could be done without dialogs, but the beauty of dialogs is that they can keep you from losing your place in what you're doing "behind" them, before they opened. Modal dialogs are less disorienting to users than just taking to some other "page", because they can tell what they're currently working on is still there behind the dialog.

[epcoa]

No idea why you think any of that should block the entire browser including all other tabs, but that sounds like awful design.

Furthermore, editing a node, a sharing interaction and adding a person all sound like they could be handled by modeless dialogs or independent editors. Frankly, modals are typically a hallmark of lazy design.

[quantadev]

I also went thru a phase years ago where I also claimed all dialogs should be modeless to free up users to do "anything at any time". But the problem with "anything any time" is that your state management becomes a nightmare, because you then have to start guarding against astronomically large numbers of ways users can create invalid states, create contradictory settings, or have the content of one dialog become invalid, because of work done in some other dialog etc.

Hallmark of good design is when the user is doing one thing at a time, and the dialog flow makes intuitive sense. Often being able to jump back to a prior dialog means you can then start a NEW branch of all the dialogs you've already opened (and that's confusing). Modals simplify not only the code, but the user experience.

[zelphirkalt]

Why would the state management get any more difficult? Any change a user would have input into a modal dialog only gets applied when that dialog is closed/done. Same can be done for any implementation using no modal dialog. You can have a "save changes" or whatever button that confirms the changes and only then they affect the state. There seems no inherent reason that it would become more complicated.

[quantadev]

The problem comes about when closing dialogs (i.e. their state change) in random order leads to invalid state. If the user is in a process of doing something where `A` depends on `B` and `B` depends on `C`, etc, for example, you can't just let them say "I'm done with A now" (before B and C), when the flow REQUIRES input from B and C in order to be valid.

I know people can argue endlessly that no process step should ever REQUIRE input from some other step, but that's the same as saying "There's no such thing as a multi-step process" which is obviously an incorrect statement.

Like if I'm editing a new CMS record, and adding an attachment/file to it, what if I clicked "cancel" on the new record WHILE the upload Dialog is open? Sure you can rationalize your way around that, and think your way out of how that can work with modeless dialogs, but you're just creating lots of unnecessary work for yourself if you do.

Modal dialogs have been around literally forever (even before the web) because they're needed. It's a signal to the user that they MUST complete something before moving forward.