4 ms·

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

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 2y ago
> 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 2y ago
  > 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 2y ago
    I mean that's how alerts work on almost every other platform
quantadev 2y ago
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.
- epcoa 2y ago
  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 2y ago
    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 2y ago
      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.
berkes 2y ago
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?

tredre3 2y ago

> 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 2y ago
> 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 2y ago
  I mean that's how alerts work on almost every other platform

quantadev 2y ago

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.

epcoa 2y ago
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 2y ago
  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 2y ago
    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.

berkes 2y ago

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?