Of course, the article would probably be better with “might not” rather than “don’t” here, because as you say, it’s not a hard and fast rule. I wouldn’t discredit the article as mere clickbait, it’s got some pretty solid suggestions.
I’d add, when using React, react-router is pretty commonly used, and making a URL-safe modal can be const { hash } = useLocation();, and displaying the modal dependent on the content of the hash. { hash === 'modal1' && <Modal>...</Modal> }, modulo bugs.
you have an web app, and not a web site (think figma) and you just don’t change pages because there are no pages
you have very non tech saavy users, and they can’t use the back button properly, but closing a modal is alright (more common that you would think)
you want the visual cue of the modal that tell the user you are in this context, but nothing can be done before you move or cancel this, which a page transition doesn’t convey
you want a modal for part of the page, blocking only a subset of it
you don’t have a backend, but don’t have an SPA either, so switching to a new page for something would not work
Like many opinionated articles about design this one has the implicit suffix “…in a web app.”
A modal window would be a better UI in many circumstances. Why make everything else on the screen vanish just to display this detail?
The reasons given against it seem to be technical issues with web browsers and web APIs. To the extent that’s true, my response is “suck it up, buttercup.” The user’s experience is more important than how much work you had to put into implementing it. (I speak as one who had to implement stuff in the hugely awkward classic Mac OS Toolbox.)
Calling a modern web browser a “document browser” is denial at best.
The web was released in 1991, Google maps in 2005 (14 years), it’s now 2023 (18 years). Web browsers have been application platforms for the majority of their existence, and these days a lot of desktop apps are just a browser with different decor (electron, various phone app web view widgets, arguably react native).
This isn’t a bad thing. I can write a webpage once and as long as i color in the lines, it will really run everywhere. Also, I’d much rather have some app devs code running in a tried and tested sandbox than giving their installer root on my box. Especially given that app developers’ incentives are often not aligned with my best interests.
Remember installing apps and getting bonzi buddy or 10 obnoxious toolbars you can’t uninstall? I do, and I don’t miss it. Web as an app platform is what really killed it. It’s time to let go of “browsers are document viewers”
It “isn’t a bad thing” compared to the even worse alternative you present, but that’s not the only alternative. I see no reason to think we would be stuck with that if the dominant application platforms weren’t built on abstractions designed for browsing documents.
I’m not sure how somethings provenance has anything to do with what it’s good at 30 years later (IBM PCs were designed to run boring business applications, yet here we are in a world with cyberpunk 2077 and photoshop) or what a better system than “punch a web address into literally any device and poof, app” would look like. A walled garden app store? 10 people managing packages in different distro repos for one piece of software in varying degrees of not-quite-up-to-date? C was designed to make UNIX, so should we poopooh people who use it on windows or macos? Is Elixir the wrong tool for writing anything other than telephone switches because that’s what the VM was originally made for? Should we have from-scratch rewritten operating systems in the mid 2000s because at the time all consumer OSs had been built for single-processor machines?
No web abstraction built in the last 20 years has been focused on browsing documents, and evolving in generality is what useful software does.
There are good HCI reasons to avoid modal interactions, except when you need to capture the user’s attention for an important decision.
The main one is that modal dialogs block interaction with, and also often a view of, the rest of the screen. If you place the pop-over inline/on a new page, then the user can switch how they like by looking at the rest of the page/the other tab-or-window.
(Edit: link now goes to web page. I had submitted the link as a (now-deleted) Lobsters story, because I felt it was a worthy submisssion in its own right. It turns out that such submissions should nonetheless be comments.)
Agreed, and it’s not even about technical issues. Some of the things are just plain wrong.
The first two items “you can’t bookmark/open in the new tab” - wrong
“Back button confusing” - perhaps, depends if you only use modals for non-bookmarkable things (“your comment has been saved”) or the “details page” from the exaple. If you mix the two, then yes, it might be confusing.
accessibility: like every other thing on your page, this is solely on the app developer, not on the modal.
“webapps should compensate for slow page load” - I don’t see how modals do or do not affect this. Performance is not a related topic - although, you might be using some weird pattern where refreshing a page with a modal is less performant for some reason. I assume the author means open in new tab? Then it’s a performance topic, not UI topic.
“it seems easy” - what? I should not use modals because they’re easy to use?
“looked good in a mockup” - again… what?
I guess this is either a clickbait or a troll article.
Why make everything else on the screen vanish just to display this detail?
This is why I’m pretty well against all modals (web or otherwise) - why make everything else on the screen frustratingly unusable just to display this detail? Want to refer to the information under it? Sometimes works, often too bad. Want to select some text out from under it to copy/paste? Rarely works. Etc.
There’s little more annoying to me than a window dinging when I try to click on it. I’d rather have independent actions that happen when you click ok and go away when you click cancel, but otherwise don’t block your other access.
For web, using a separate page can be a better experience. Modals require JS, lots of JS is slow to load. Modals can often be complete garbage on mobile, especially if they cause the mobile browser to zoom, or parts of them render outside the viewport. I’ve seen loads of modals that could have just been a <form>, and I would have greatly preferred it.
It even has a ::backdrop pseudo-selector, and I think it sets inert on the rest of the body elements so that it doesn’t require a bunch of aria fiddling for proper a11y.
Dialog elements still need JS to be opened as modals. Also, there’s quite a few people still on older browsers who won’t be able to use the element without a polyfill.
The amount of JS needed for a modal is probably less than 1kb, which is less than loading a new page. In terms of UX, losing your entire interaction context, or having the page redraw, is worse than a few ms of latency.
For web, using a separate page can be a better experience.
I think is highly contextual. If you’re linking to one specific page somewhere, then yes. In the context of a single page, then no javascript is likely better then some javascript.
But if this is a part of a web app, then your users are usually not opening a modal in a new tab, then going back to the first one to continue working in the app. Apps like that have javascript cost anyway, but it can still be optimized to look fast.
I still like your comments, waaay better then I do the original article. Yes, they can be tricky to get right on mobile. People use huge libraries just to get some fancy modals. To get them right requires a lot of attention to details.
That’s not to say that using a separate page can’t be a better experience, I just think this is contextual.
The only good modal is a dead modal, if you ask me.
In my younger and more time rich days, I once laccomplished two goals:
No focus stealing popups (patched my WM)
No blocking modal windows (patched a lot of apps)
The second job was the hard one, of course. Replace save dialogues with auto-save and template files. Replace error windows with error alerts. And so many programs pull the dick move of opening their main window to then immediately have a sequence of modals— eating up a bunch of screen.
Then I had basically two layouts: golden ratio spiral and full screen.
My day job has an application that used a selection carousel instead of a standard tag. It drives me nuts since the option I need to use is like the 5th position and it is so hard to reach. I often can’t even read the whole option as it doesn’t fit in the window.
I objected, why would you ever use that? Apparently it is some built in thing to Angular…. yikes.
I’m annoyed looking at local McDonald’s / Pizza chains online because the current special is always buried in a carousel. If the just stacked them, I could get the info I needed a lot faster and without executing JavaScript (because while they could work without, the developers never care). If there isn’t an intriguing deal, these places are just too expensive relative to local food.
Modals are very useful when you want to keep visual context. You may not need them, but that argument reeks of Turing tarpit similarity. We don’t technically need GUIs either, but they are pretty popular.
Are you perhaps thinking of an inline or foldout UI element/dialog/form? The definition of a modal UI element is that it covers, and prevents interaction with, the main interface. The UI is temporarily in a different mode where you can only interact with the modal element, hence the name.
Modals often cover only a portion of the screen, and leave the lower layer of the UI visible. So no, I’m talking about modals. They still keep visual context because you can see the screen behind them, even if you can’t interact with it.
Ah, right. I interpret ‘keep visual context’ as ‘all of the parent page remains visible, the dialog does not cover anything you might want to cross-reference’.
Do you mean ‘keep visual context’ as ‘edges of the parent page remain visible, so you have a hint of what you were doing before’?
Yes, that hint of visual context is a point in favour of modal dialogs. My ‘but’ is that I’ve had some bad experiences with (web) modal dialogs, that to me weigh heavier than the visual context.
In desktop UIs, I’ve had many bad experiences with modal dialogs: I’d open the dialog; then I’d realise I needed to look something up in the main UI; but because the dialog was modal I couldn’t access the rest of the program; so I would have to close the dialog to look up what I needed know, and then reopen it to do what I needed to do. Things like “I have a PDF open, I want to Save As, I want to copy the title to use in the filename — oops, the dialog is modal, better close it first, copy the title, then reopen Save As.”
In websites, I’ve had bad experiences with accidentally closing modals because I clicked on something outside it. I’ve also had many, many, bad experiences with web ‘pages’ that I couldn’t reach via a URL, only via a sequence of instructions like ‘go to this URL, search for this keyword, then click here, there, and there’.
These problems can all be smothered, but there are other web techniques where the problems do not even arise. Normal web pages always have URLs. Forms that fold out inline never cover anything.
I don’t mind modal navigation menus, though. Probably because when I open them, I want to go somewhere else anyway. (But the menu had better stay open when I hit Ctrl-F / Find in Page.)
One thing you can do here is have clicking expand a modal, but Ctrl/shift-click does a new page. [0]
Implementation wise you send a header depending on the action, and get either a snippet or a full page.
Reloading page state or toggling between tabs when you want to just peek at something is also unfriendly UX! But I think that you can sort of tackle this problem in a pretty principled way to get the best of both worlds.
I like documents and simple pages, but on the occasions that we can offer better UX pretty easily, it feels like it’s worth trying out!
[0] please don’t be pedantic about mobile devices. Something should happen there of course
Maybe “modal window” means something slightly different from the usual term within UI applications, but I can’t remember seeing such a window on the web. Is there a site utilizing them that I can visit to see them in action?
Clickbait.
You don’t need a modal windows for this particular interaction (maybe), but there are plenty of good reasons to have them.
For context, the title follows the structure of quite a few minimalist webdev/JS evangelism articles:
You don’t need moment.js
You don’t need jQuery
You don’t need Bootstrap
You might not need JQuery
You might not need lodash
You might not need JS
Of course, the article would probably be better with “might not” rather than “don’t” here, because as you say, it’s not a hard and fast rule. I wouldn’t discredit the article as mere clickbait, it’s got some pretty solid suggestions.
I’d add, when using React, react-router is pretty commonly used, and making a URL-safe modal can be
const { hash } = useLocation();, and displaying the modal dependent on the content of the hash.{ hash === 'modal1' && <Modal>...</Modal> }, modulo bugs.what are some of the good reasons to have them?
Like many opinionated articles about design this one has the implicit suffix “…in a web app.”
A modal window would be a better UI in many circumstances. Why make everything else on the screen vanish just to display this detail?
The reasons given against it seem to be technical issues with web browsers and web APIs. To the extent that’s true, my response is “suck it up, buttercup.” The user’s experience is more important than how much work you had to put into implementing it. (I speak as one who had to implement stuff in the hugely awkward classic Mac OS Toolbox.)
Alternately, maybe we shouldn’t be building applications using a document browser.
Calling a modern web browser a “document browser” is denial at best.
The web was released in 1991, Google maps in 2005 (14 years), it’s now 2023 (18 years). Web browsers have been application platforms for the majority of their existence, and these days a lot of desktop apps are just a browser with different decor (electron, various phone app web view widgets, arguably react native).
This isn’t a bad thing. I can write a webpage once and as long as i color in the lines, it will really run everywhere. Also, I’d much rather have some app devs code running in a tried and tested sandbox than giving their installer root on my box. Especially given that app developers’ incentives are often not aligned with my best interests.
Remember installing apps and getting bonzi buddy or 10 obnoxious toolbars you can’t uninstall? I do, and I don’t miss it. Web as an app platform is what really killed it. It’s time to let go of “browsers are document viewers”
It “isn’t a bad thing” compared to the even worse alternative you present, but that’s not the only alternative. I see no reason to think we would be stuck with that if the dominant application platforms weren’t built on abstractions designed for browsing documents.
I’m not sure how somethings provenance has anything to do with what it’s good at 30 years later (IBM PCs were designed to run boring business applications, yet here we are in a world with cyberpunk 2077 and photoshop) or what a better system than “punch a web address into literally any device and poof, app” would look like. A walled garden app store? 10 people managing packages in different distro repos for one piece of software in varying degrees of not-quite-up-to-date? C was designed to make UNIX, so should we poopooh people who use it on windows or macos? Is Elixir the wrong tool for writing anything other than telephone switches because that’s what the VM was originally made for? Should we have from-scratch rewritten operating systems in the mid 2000s because at the time all consumer OSs had been built for single-processor machines?
No web abstraction built in the last 20 years has been focused on browsing documents, and evolving in generality is what useful software does.
This is one better alternative; another would be like the web but built from the ground up to handle interaction rather than documents.
Sometimes abstractions built for one purpose are suitable for another, and sometimes they aren’t.
no.
:)
Thank you for this comment.
King Ferdinand and Queen Isabella would like to point out that ship’s already sailed some years ago…
There are good HCI reasons to avoid modal interactions, except when you need to capture the user’s attention for an important decision.
The main one is that modal dialogs block interaction with, and also often a view of, the rest of the screen. If you place the pop-over inline/on a new page, then the user can switch how they like by looking at the rest of the page/the other tab-or-window.
(Edit: link now goes to web page. I had submitted the link as a (now-deleted) Lobsters story, because I felt it was a worthy submisssion in its own right. It turns out that such submissions should nonetheless be comments.)
Agreed, and it’s not even about technical issues. Some of the things are just plain wrong.
I guess this is either a clickbait or a troll article.
This is why I’m pretty well against all modals (web or otherwise) - why make everything else on the screen frustratingly unusable just to display this detail? Want to refer to the information under it? Sometimes works, often too bad. Want to select some text out from under it to copy/paste? Rarely works. Etc.
There’s little more annoying to me than a window dinging when I try to click on it. I’d rather have independent actions that happen when you click ok and go away when you click cancel, but otherwise don’t block your other access.
For web, using a separate page can be a better experience. Modals require JS, lots of JS is slow to load. Modals can often be complete garbage on mobile, especially if they cause the mobile browser to zoom, or parts of them render outside the viewport. I’ve seen loads of modals that could have just been a
<form>, and I would have greatly preferred it.Not anymore they don’t:
https://caniuse.com/dialog
It even has a
::backdroppseudo-selector, and I think it setsinerton the rest of the body elements so that it doesn’t require a bunch of aria fiddling for proper a11y.EDIT: They may also get support for back buttons!
Dialog elements still need JS to be opened as modals. Also, there’s quite a few people still on older browsers who won’t be able to use the element without a polyfill.
The amount of JS needed for a modal is probably less than 1kb, which is less than loading a new page. In terms of UX, losing your entire interaction context, or having the page redraw, is worse than a few ms of latency.
I think is highly contextual. If you’re linking to one specific page somewhere, then yes. In the context of a single page, then no javascript is likely better then some javascript.
But if this is a part of a web app, then your users are usually not opening a modal in a new tab, then going back to the first one to continue working in the app. Apps like that have javascript cost anyway, but it can still be optimized to look fast.
I still like your comments, waaay better then I do the original article. Yes, they can be tricky to get right on mobile. People use huge libraries just to get some fancy modals. To get them right requires a lot of attention to details.
That’s not to say that using a separate page can’t be a better experience, I just think this is contextual.
The only good modal is a dead modal, if you ask me.
In my younger and more time rich days, I once laccomplished two goals:
The second job was the hard one, of course. Replace save dialogues with auto-save and template files. Replace error windows with error alerts. And so many programs pull the dick move of opening their main window to then immediately have a sequence of modals— eating up a bunch of screen.
Then I had basically two layouts: golden ratio spiral and full screen.
I miss that serenity, ever day.
Pairs great with thoughts about carousels: https://shouldiuseacarousel.com
My day job has an application that used a selection carousel instead of a standard tag. It drives me nuts since the option I need to use is like the 5th position and it is so hard to reach. I often can’t even read the whole option as it doesn’t fit in the window.
I objected, why would you ever use that? Apparently it is some built in thing to Angular…. yikes.
I’m annoyed looking at local McDonald’s / Pizza chains online because the current special is always buried in a carousel. If the just stacked them, I could get the info I needed a lot faster and without executing JavaScript (because while they could work without, the developers never care). If there isn’t an intriguing deal, these places are just too expensive relative to local food.
Modals are very useful when you want to keep visual context. You may not need them, but that argument reeks of Turing tarpit similarity. We don’t technically need GUIs either, but they are pretty popular.
Are you perhaps thinking of an inline or foldout UI element/dialog/form? The definition of a modal UI element is that it covers, and prevents interaction with, the main interface. The UI is temporarily in a different mode where you can only interact with the modal element, hence the name.
Modals often cover only a portion of the screen, and leave the lower layer of the UI visible. So no, I’m talking about modals. They still keep visual context because you can see the screen behind them, even if you can’t interact with it.
Ah, right. I interpret ‘keep visual context’ as ‘all of the parent page remains visible, the dialog does not cover anything you might want to cross-reference’. Do you mean ‘keep visual context’ as ‘edges of the parent page remain visible, so you have a hint of what you were doing before’?
Exactly. I’m not saying it’s great. I’m just saying that you lose all visual context when moving to a totally different page.
Yes, that hint of visual context is a point in favour of modal dialogs. My ‘but’ is that I’ve had some bad experiences with (web) modal dialogs, that to me weigh heavier than the visual context.
In desktop UIs, I’ve had many bad experiences with modal dialogs: I’d open the dialog; then I’d realise I needed to look something up in the main UI; but because the dialog was modal I couldn’t access the rest of the program; so I would have to close the dialog to look up what I needed know, and then reopen it to do what I needed to do. Things like “I have a PDF open, I want to Save As, I want to copy the title to use in the filename — oops, the dialog is modal, better close it first, copy the title, then reopen Save As.”
In websites, I’ve had bad experiences with accidentally closing modals because I clicked on something outside it. I’ve also had many, many, bad experiences with web ‘pages’ that I couldn’t reach via a URL, only via a sequence of instructions like ‘go to this URL, search for this keyword, then click here, there, and there’.
These problems can all be smothered, but there are other web techniques where the problems do not even arise. Normal web pages always have URLs. Forms that fold out inline never cover anything.
I don’t mind modal navigation menus, though. Probably because when I open them, I want to go somewhere else anyway. (But the menu had better stay open when I hit Ctrl-F / Find in Page.)
One part that really bothered me was the point about “you’re not designing a Figma artboard.”
Sure, but I am implementing a Figma artboard as the designers who are trained in design asked me to implement it…
http://nomodes.com/Larry_Tesler_Consulting/CV_files/NOMODES.jpg
The back button doesn’t work right on android firefox…
One thing you can do here is have clicking expand a modal, but Ctrl/shift-click does a new page. [0]
Implementation wise you send a header depending on the action, and get either a snippet or a full page.
Reloading page state or toggling between tabs when you want to just peek at something is also unfriendly UX! But I think that you can sort of tackle this problem in a pretty principled way to get the best of both worlds.
I like documents and simple pages, but on the occasions that we can offer better UX pretty easily, it feels like it’s worth trying out!
[0] please don’t be pedantic about mobile devices. Something should happen there of course
Maybe “modal window” means something slightly different from the usual term within UI applications, but I can’t remember seeing such a window on the web. Is there a site utilizing them that I can visit to see them in action?
See here: https://react.semantic-ui.com/modules/modal/
Click the buttons to see examples