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