10 ms·

Don’t open the details in a modal window, have it be a separate page

HL33tibCe7 3y ago
I guarantee this was written by somebody who has never worked as a professional UI/UX designer It’s the kind of bold, blanket statement that sounds really great and is a fun opinion to hold, but when confronted with reality crumbles (as many statements of that kind do).
- zuprau 3y ago
  > somebody who has never worked as a professional UI/UX designer Such as the Nielsen Norman Group. > "Do not use modal dialogs for nonessential information that is not related to the current user flow." > From https://www.nngroup.com/articles/modal-nonmodal-dialog/ https://www.nngroup.com/articles/modal-nonmodal-dialog/ Nonessential information such as, let's say, "details." I'd say that this minisite is exactly on point.
sva_ 3y ago
For some reason I thought this was someone complaining about those German windows we have in our houses, that open two ways.
- NeoTar 3y ago
  Why would anyone want to complain about those?
  - deleted 3y ago
    [deleted]
  - afandian 3y ago
    Most glaziers probably don't care about modal dialogue boxes.
dvh 3y ago
Yes I do. Not every software is cathedral built on a green field with unlimited budget. Sometimes you just need to smack an alert() or confirm() or prompt() in the middle of code and move on to more important stuff.
- aembleton 3y ago
  Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: Alerts Confirmation dialogs Forms for creating/updating entities
spaceman_2020 3y ago
I disagree. Modal windows are great if the information is small enough that it can be digested in a single glance. Making me open up a new tab to view a paragraph of text is just plain annoying.
- vaylian 3y ago
  Then just create a new <div> that shows the information inline.
ThatMedicIsASpy 3y ago
I click on the examples and it throws the page back to the top. I refuse to read anything that is said after the example being useless.
throwawaaarrgh 3y ago
ThisIsAShittyClickbaitArticleWhyIsItAnEntireWebsite.dev
gloryless 3y ago
Most of this post is trying to declare rules that just aren't true. Even Asana will deep link a modal, it's just another piece of state in the url
golergka 3y ago
Details pages with a lot of information? Bad fit. Small messages that need to be brought to the user's attention and a simple "OK"/"Cancel" button? Yes, this is a good fit. That's what modal windows were originally created for.
- PaulHoule 3y ago
  I think the first article I saw complaining about modals was in BYTE magazine circa 1981.
- ceejayoz 3y ago
  The end of the article says exactly that.
- pornel 3y ago
  I've seen confused users who missed/ignored the tiny OK window, and through the app froze, because the large parent window stopped reacting to clicks.
  - dieulot 3y ago
    iOS ⩽ 6 used a radial gradient effect to make it clear that the modal is what’s to be interacted with.
  - YurgenJurgensen 3y ago
    MS Outlook is very good at opening modals that block interactivity with the main window. And opening them on a different monitor to the original window (even if said monitor is full-screening a different application so the modal actually opens on a currently-invisible workspace) so it's not even obvious why.
  - dspillett 3y ago
    For a HTML based presentation you probably have a backing element that covers the rest of the page to trap clicks anyway. Make this partially opaque instead of transparent and the modal becomes much more obvious. Or if you want to be a bit more fancy and can rely on the user having a browser newer than July 2022 perhaps use backdrop-filter to apply a blur instead of just being partially opaque. You can do the same on a desktop app too, but it is less commonly done. To further avoid confusion, try make sure the pop-up modal appears over the parent window that it is blocking input for (this may mean coding your own window instead of the platform default alert/confirmation box, if the call to open one doesn't allow positioning information to be specified). I've seen alerts/confirmations pop-up on a different screen to the one that the parent window is on which makes missing it much easier (especially if the other screen is away from the main one, perhaps it is being projected at a wall for a demo). To further help: if the user clicks the disabled parent, move the pop-up to where they clicked – usually the title-bar or other chrome on the pop-up flashes in this case, but that isn't helpful if it is on screen 2 and the user is staring intently at screen 1.
efitz 3y ago
People who implement modal windows are antisocial. And, there is a special place in hell for people who implement system modal windows.
- GoToRO 3y ago
  It happens like this: some manager just wants a simple modal to show some details (see, he is not just a failed developer, he knows words, like modal). Do we need it to have it's own url? No. Do we need to edit the data? No! Just a simple modal! Why are you asking all these questions? The thing gets implemented and the users like how fast the data is shown. But can we just add some action buttons like Accept and Reject instead of the Ok button? Why close the modal and then hit an action button when you can have them right there? The buttons get implemented, the users love it. Manager comes back, but can we edit one or two fields? Sure. Some of the fields will open a modal to let users select the value. Should we reimplement it as a regular page so we don't have a modal in another modal? Manager: No, that will take forever. Validation, error messages, scrollbars? The manager refuses to fix it because he burned through all the allocated time and he doesn't want to have a difficult discussion with the stakeholders. And anyway, in these meetings the developers are not invited and he can just blame the developers because everybody knows how entitled they are.
extasia 3y ago
Love your username, OP.
qwertox 3y ago
Above all, please respect that a middle mouse button is supposed to open a link in a new tab.
- worldsayshi 3y ago
  Oh, I always use ctrl click. Ditto.
  - Akronymus 3y ago
    Too often, links are just buttons that navigate you to the url when you click on it. It just ignores modifiers. It makes me furious
    - worldsayshi 3y ago
      Yeah as a user I'm annoyed how often modifiers are circumvented. As a developer I'm annoyed at how often I end up in a situation where I have to reinvent 'click to follow a link' and where it's really tedious to also reimplement modifiers.
- Alifatisk 3y ago
  And on mouspads or touch?
  - gramvoir 3y ago
    On mousepad its the same same. If yours misses the middle button either switch to a real one (Thinkpad) or use left+right.
    - Alifatisk 3y ago
      Totally forgot about left + right!!!
  - deleted 3y ago
    [deleted]
  - 3y ago
huhtenberg 3y ago
> Don't open the details in a modal window. Have it be a separate page. This will worsen the UX more often than not. Guaranteed. All complaints on the page are ultimately grievances against poorly thought-through implementations and as such they are rooted in the wrong thing. It's trivial to complement every modal window with a standalone version, in which case it's possible to bookmark them, middle-click on the links and what have you. Start with the user experience, craft your implementation around that and all will be fine. Including the modal windows.
- reaperducer 3y ago
  This will worsen the UX more often than not. Guaranteed. You must use "telemetry" instead of actually talking to your users. My company requires me to talk to the people who use the web sites I build. (I has a session just yesterday.) They hate modal windows. They even still refer to them as "pop-ups."
  - oefrha 3y ago
    Your company requires you to talk to users, yet it seems you still haven’t gotten the memo that you shouldn’t make blanket assumptions without talking to people about actual use cases. “Users hate modal windows” is about as meaningless as “users hate open in new tab” without context.
    - reaperducer 3y ago
      You pontificate, but didn't get the memo about not making things up. I never made any blanket assumptions and never wrote "Users hate modal windows." Reading is fundamental.
      - oefrha 3y ago
        [flagged]
        reaperducer 3y ago
0xedb 3y ago
Next.js 13 has a neat solution: parallel routes (https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#modals https://nextjs.org/docs/app/building-your-application/routin...)
- worldsayshi 3y ago
  I tried Next.js very briefly and I initially found this concept really nice. However I bounced back and gave up on the framework for some related reason. I felt like I gave up control to much, maybe due to the routing model. Feels like some common problems were made much harder because of it.
  - scrollaway 3y ago
    I implemented it in a bookkeeping app I’m working on. It works nicely but the documentation is very poor; I had to constantly refer to a third party example. Once you get how it works it’s neat.
nologic01 3y ago
The Treachery of Modals: Ceci n'est pas une page
amelius 3y ago
Yes. Why does nobody use alert() anymore?
- ExtremisAndy 3y ago
  I always use it while developing a new web app, but admit that I always switch it to something "fancier" in production, mainly because I find alerts rather ugly. But, goodness gracious, it would simplify so many things! I've just sort of assumed that default browser alerts were considered a big no-no these days, but that assumption comes from the fact that I simply don't see them being used much. I guess I should look into this more. Sure would shorten dev times!
tobr 3y ago
Counterpoint: This is a little like arguing that you should use GOTO instead of call stacks. Like a function call, with a modal you keep your place and know you will be able return to where you were. No risk of getting lost. Linking to a separate page is like GOTO control flow. You leave it up to the user to figure out where to go from there, but the user usually doesn’t know the full sequence of steps that are part of a task. It’s your responsibility to guide them.
ab_goat 3y ago
I used to feel this way and would make everything linkable, but then I realized that modals are really good at preventing users from getting lost by adding context instead of swapping context. For example, a user may want to edit a few items items in a list Rather than forcing the user to a new page to do each edit, you can pop up a modal and edit in place. With new pages, the user loses the context of the original list. The page swapping is very disruptive.
- l5870uoo9y 3y ago
  I concur. I think this page[1] illustrates it quite well. [1]: https://gwern.net/index https://gwern.net/index
  - EnergyAmy 3y ago
    That's actually a super weird implementation. I can hover over a link and open a modal preview, and then hover over a link in that modal to open another modal, ad infinitum. I ended up with 20 modals covering the page, and then moved my mouse a little too much and they all disappeared at once. Also, if you click on something in the modal, you end up getting redirected to a new page anyways, which kind of supports the anti-modal argument. OTOH, I like Wikipedia's hover previews just fine, so sometimes they're OK.
- kypro 3y ago
  There are normally better approaches to a modal popup. In this case I'd consider expanding the item on the page when preforming an edit. That way it's clear to the user they're on the same page so won't be tempted to click back and you won't need to worry about confusing keyboard / screen reader users. Alternatively if you absolutely need to use a modal consider a slide out instead. Slide outs tend to look less like new pages and reduce the likelihood of a user clicking back to "go back" to whatever they were previously looking at. With a slide out the original content is still in view, but now you have some extra options to the side. You still have all the accessibility issues of course, but the UX is slightly better most of the time.
- e1g 3y ago
js8 3y ago
The worst modal window is the save dialog in Firefox. Often I need to see something in the page to put into filename, and the save dialog blocks it.
- aendruk 3y ago
  A few years ago GNOME started doing this all over the place. Modals are spatially coupled to the parent window so moving the modal moves the parent too. Drives me crazy that I can’t refer to the information underneath.
  - smeagull 3y ago
    GNOME is a lost cause. Once they started shadowing keybindings from readline they failed at UX.
- deleted 3y ago
  [deleted]
yawnxyz 3y ago
If your page loads are slower than 200ms, I'd actually suggest having modals. Or at least some way of progressively showing more information (toggles, accordions, etc.) that stay on page. SPA page loads can get really slow, which can frustrate or disorient users. Having too many page loads to sequentially drill down your info architecture can get really annoying for users. If your pages are 1 or 2 layers deep in your architecture, and the rest is shown in some way within the page (again, modals are one way to do it), as a piece of "fleeting information", your users will appreciate it.
- arghwhat 3y ago
  For an SPA, there is no difference in loading time between a modal and non-modal view. The (annoying) SPA penalty is initial page load, which is a one-time cost. The location changes are virtual through the history API, with a reload just causing the SPA to start from that location instead of from the root/home view.
  - thecopy 3y ago
    >there is no difference in loading time between a modal and non-modal view AWS Management Console begs to differ:)
    - arghwhat 3y ago
      Okay fair: there is no technical reason for any such difference, but bad web apps be bad. :P
- quickthrower2 3y ago
  Jira has slow loading modals
EduardoBautista 3y ago
> Modal windows can't be bookmarked or shared as links. Modals can definitely be bookmarkable if they are dependent on a certain path or query param to appear.
NavyG 3y ago
> Modal windows can't be bookmarked or shared as links We use modal windows specifically for this reason (for our payment application's checkout page). Also using a modal significantly improves the checkout experience in case of SDK flows for payment methods like Klarna, Google pay etc. Personally I feel modal windows are better aligned to the user's flow of attention. We also have redirection flows for these payment methods to open the authentication page in a new tab but we pick the modal flow ever single time for a better experience. You can get a feel of what I'm talking about over here: https://demo-hyperswitch.netlify.app/checkout https://demo-hyperswitch.netlify.app/checkout
sureglymop 3y ago
Modal Windows absolutely can be shared with a link if done well. Open the modal as an overlay and set the url with javascript. Then also have a noscript tag which contains a link to that (modal) page. On the server side you just need to make sure that you can render that page and serve it. This is pretty much how imo. modern SSR frameworks like sveltekit are intended to be used. Of course if non-js users aren't a concern, you can do this with an SPA too, the client side routing just needs to be programmed right and the server needs to serve the bundle correctly.
Gabrys1 3y ago
Last paragraph says this: > Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: > [...] > Forms for creating/updating entities Wow, in my opinion this a perfect example where a separate page IS still superior to a modal: how much better a "create issue" jira PAGE is vs the modal?
- deniz-a 3y ago
  If users are expected to spend a long time and use many tools to compose something, then I agree a full page form is best. For something like adding to a todo list, or where users are expected to add many items one after the other, a modal is better. You can also take a hybrid approach: many calendar apps have a small popup for adding an event that the user can expand into a whole (nonmodal) window for editing all the details.
deleted 3y ago
[deleted]
physicsguy 3y ago
The issue is that as web software becomes more and more complex and desktop-esque, it needs features that were common in desktop software. It's a poor user experience to open a new window for lots of things in the browser, but that sort of functionality is still needed sometimes. If I think about the engineering product I work on and where they do have modals, none of them would work with a separate page. It's things like "Load one or more of your saved graphs (which you can search and filter) into this existing page of graphs"
kypro 3y ago
> Modal windows are hard to get right. The "final boss of accessibility" Lmao, I was making this point at work yesterday. It's really difficult to justify using a modal if you care about accessibility. It's not that it's impossible to do correctly, but even when it's done "correctly" it can still be confusing for users navigating with keyboards / screen readers. So modals are almost always either too much effort to do right, or just not the best approach. Another thing I'd add to this list is that there are some people who browse without JS enabled. I know it's unpopular to care about those folks these days, but it is another reason to avoid modals where possible.
- lelandfe 3y ago
  I would like to care about JS-disablers, but it is a disproportionally large amount of work for something a few people are choosing to do. I try to give it a best effort, but won’t e.g. rebuild a menu as an HTML checkbox just because some folks are hardliners about running Javascript.
  - tvararu 3y ago
    "Everyone has JS, right?" https://www.kryogenix.org/code/browser/everyonehasjs.html https://www.kryogenix.org/code/browser/everyonehasjs.html
    - lelandfe 3y ago
      Only one part of this, which we're already talking about, is relevant here.
- pavlov 3y ago
  Modals and accessibility was a completely solved problem in 1990s desktop UIs. If anything modals were considered the “easy mode” of UI design. (You can see this in applications like Photoshop that retain some of the original early ‘90s modal-centric design.) It’s crazy how much the web platform’s lack of UI expressivity has set us back. Everything is constantly getting desperately reinvented out of a handful of text markup tags cobbled together by scripts, but it doesn’t solve any of the underlying issues.
jcmontx 3y ago
Bootcamp React developers discover MPAs
jasonlotito 3y ago
Modal Windows: If you put up a modal window, and it blocks content beneath it, and I can't at least move it out of the way, then it 100% is anti-user behavior. There is NO good reason for blocking the user from seeing content that might be relevant to the modal window. This is true for both websites and apps. Compare Safari's Open File to Chrome's Open File. Chrome's Open File modal cannot be moved. Safari's can. If you have a modal, and it blocks content, you have to be willing to say "I want to prevent my users from seeing this content while dealing with the modal. The content that is being blocked is not important, and it serves NO purpose."
vaylian 3y ago
Modals disempower the user. That's why they are so popular with mandatory Cookie selection dialogs.
quickthrower2 3y ago
I was thinking this today as I was using JIRA. I would live JIRA to be a boring and more RESTful web app. I hit a bug where if I closed the popup (for a ticket on a board) it just reopened! And some ticket links don’t work. All these bugs and complexity for what? Maybe the browsers should have a built in “open link as popup” for the rare times you want that. And the sites just make it a new page always.
- dan-robertson 3y ago
  I think Jira performance already seems to be dominated by roundtrips to the servers. Making it more like what you describe may make it even worse.
  - quickthrower2 3y ago
    Yeah they need to sort their app performance out. That said the modal load is just as slow.
    - throwawaaarrgh 3y ago
      Actually Jira has multiple examples of "new page over modal" and it's the worst UX in Jira. If you try to perform bulk edits, it'll bring you to a brand new page with all the items you want to modify, and ask you to click some things ("what kind of X should I do to these tickets"). You click stuff and hit Submit, and it goes to yet another new page with all the tickets and asks you to select more things. Then you click Submit, and it brings you to yet another new page where you click another set of things, and hit Submit. 3 entirely new page loads, and then you go back to the original page. You can't hyperlink to any of these pages because they're part of a bulk edit applying to many items in intermediate states. Each page load takes at least 5 seconds. You can't see any of the context of where you were before, and when you go finally go back, you lose some of what you were doing/displaying before. A modal would be much faster because the entire page wouldn't need to reload 3 times, you already can't bookmark specific sections in the new pages, and if you wanted to cancel the operation you could get back to the original page much faster (technically you're already on it), with the original context of the original page still intact.
nfRfqX5n 3y ago
I've seen tons of feedback directly from customers which indicate the opposite, losing context is super annoying
- layer8 3y ago
  That's orthogonal to modals.
  - sowbug 3y ago
    In defense of those customers, the back button has become a game of Russian roulette. Most of the time it takes you back to the page or UI state you were on. The rest of the time it breaks the JS, takes you to an awful "before you go" page you never navigated to, displays the mysterious "confirm form resubmission" dialog, or in the case of the infamous Treasury Direct site, marks your account as disabled until you perform a new kind of corporeal signing ritual that your local bank branch manager has never even heard of but apparently must now perform with you. It's sadly reasonable not to expect users to trust, or even try, the back button.
projektfu 3y ago
THANK YOU OMG I have lots of frustration with modal views that: 1. block me from seeing the things that I probably need to enter into the view 2. disappear when you accidentally click outside them 3. don't scroll properly 4. don't allow scrolling of the page behind 5. don't play well with reasonable browser extensions (uBlock, but other things as well like Disconnect) or even the tracking prevention build into browsers. 6. store data in a weird place so that a second window of the same site in a different location opens the same (now incorrect) data in the modal. These things are becoming super common in line-of-business apps, where they interrupt workflow. Better options: 1. New page, as recommended by this link 2. Expanding a region of interest to allow the form to fit 3. Making the page more interactive in other ways so that a modal doesn't seem like the best way to do the interaction
deleted 3y ago
[deleted]
dadalorian 3y ago
Ironic that the popover API was just announced 2 days ago. https://developer.chrome.com/en/blog/introducing-popover-api/ https://developer.chrome.com/en/blog/introducing-popover-api...
000ooo000 3y ago
youdontneedadomainforyouronepagepedantry.com
- 000ooo000 3y ago
  Cheap shots aside, this was a very unconvincing set of arguments. Would it have not been a better use of ones time, both the author and reader's, to have documented both the pros and cons of modals instead of this lame, "trendy", You don't need takedown?
- DonHopkins 3y ago
  you-do-need-dashes-between-the-words-in-the-domain-name-of-your-one-page-pedantry-because-then-you-can-clearly-communicate-your-message-without-actually-requiring-people-to-click-on-the-link-or-even-bothering-registering-the-domain-or-putting-up-a-web-site-unless-of-course-you-are-just-publishing-click-bait-to-sell-ads-in-which-case-fuck-off.com
marcofiset 3y ago
Phoenix LiveView handles all of those concerns extremely well and pretty much for free. All of my modals are tied to a live action in a given live view. You can bookmark them, use the browser back button to close them and the state "under the modal" is a complete non-issue. It's just loaded as part of the live view and a modal is shown only on specific actions. That may sound like gibberish if you're not familiar with Phoenix LiveView, but it all makes sense and it just works.
nicbou 3y ago
What are good alternatives? I like <details> and collapsible panels.
2bitlobster 3y ago
[flagged]
DonHopkins 3y ago
We use too many damn modals (2018) (modalzmodalzmodalz.com) https://modalzmodalzmodalz.com/ https://modalzmodalzmodalz.com/ MODALZMODALZMODALZ.COM >We use too many damn modals. Let's just not. Help >The bad news: Modals are the crutch of the inarticulate designer and developer. [...] https://news.ycombinator.com/item?id=23645447 https://news.ycombinator.com/item?id=23645447 >bedatadriven on June 25, 2020 | next [–] >I was just about to share this our designer, who is always talking me down from modals, when I reached the bottom and discovered that our designer is in fact the author. >I seriously can't say enough for this message. Adrian helped us redesign our app 2 years ago, dispatching many many modals in the process, and delivering a huge increase in usability that our customers and users very much do care about.
chakintosh 3y ago
As a UX designer, I wholeheartedly disagree. > Modal windows can't be bookmarked or shared as links Why would the user want to bookmark or share a "modal". I believe the author is confusing a modal with a details page (a customer's details page in a CRM for example) on that we can agree that that kind of content is best shown on a separate page. A modal serves a specific function within a web page, be it a website or a web app. Its main function is to allow the user to perform certain tasks within a page, and those tasks will immediately reflect on the underlying page upon submission (or validation/confirmation ..etc). So I fail to understand why the author thinks a user would want to bookmark that modal. > Modal windows can't be opened in a new tab Nor should they. Modals, as mentioned above, are one layer above an underlying page, and they either show complimentary information related to an element within that page, or they allow to user to performa task. So they should inherently be accessible within the same tab, not a new one. > Modal windows make the Back button confusing Aside from the Close/Abort button inside the modal, a lot of interaction designers and front-end developers are now developing the modals in a way they would close if you press the back button of your browser. No confusion there in my opinion. > Modal windows are hard to get right[...]if you need to support older browsers, good luck. Can't find the date this article was published but I assume it's old because almost all new browsers support at least <dialog> element [1] Modals are a double edged sword, like any UI component or UX pattern really. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... Further reading: https://www.nngroup.com/articles/modal-nonmodal-dialog/ https://www.nngroup.com/articles/modal-nonmodal-dialog/
- monooso 3y ago
  > I believe the author is confusing a modal with a details page It sounds like you agree with the article, at least according to my reading. The author states that you should not use a modal for something “bookmarkable”, such as a details page. They also state that a modal is suitable for performing an action that does not warrant a “resource URL”, such as a “create resource” form.
  - teawrecks 3y ago
motoboi 3y ago
I like the azure portal solution, where everything opens in a modal, in the form of a panel. When the link is followed, the panel opens as the main window.
ptx 3y ago
I think the author's objections can all be addressed by using history.pushState() and treating the modal window like navigation to a subpage/route (in an SPA-style app). This way the modal will have a URL, so it can be bookmarked, can be opened in a new tab (if it's opened through a link) and the back button will work (closing the modal).
- roblh 3y ago
  This works, except when it doesn’t. I’m not sure about react, but Vue router has some funny and unintuitive interactions when you do this which will often result in unnecessary page reloads, either when you push state or when the back button pops it again. Maybe react behaves better but my experience with it has made me not want to directly mess with history unless I have a particularly good reason to.
  - ptx 3y ago
    It seemed to work well in Angular in the tiny app where I tried it, but to be clear I didn't directly mess with the history API – I used the navigation mechanisms of the Angular framework to manage this. Calling the browser history API directly could probably confuse the framework.
- aflukasz 3y ago
  > and the back button will work (closing the modal). Which opens a whole new can of worms! What is the meaning of pressing "back" when modal window is shown? Is it "cancel"? What if I already changed something within the modal? What if "back" causes losing some input within the modal? Should we... show another modal for confirmation of going back? Same with navigation via "back"/"forward" into a modal (which is now present on the history stack) - if this was modal with some action... can I execute it again? Did I just execute it by navigating into it?
myth2018 3y ago
I would expand my criticism to elements such as material design drawers and similar ones. Regardless of the support provided by the platform (`<dialog>`, convenient APIs etc), you may still find yourself fighting with the resulting state -- for instance, when the screen must adjust its behavior and/or content according to dialog's content or state. The requirements in such situations can get overwhelming quite quickly. > Because it looked good in the mockup Indeed, tools like Figma can create a dangerous illusion of simplicity. I wonder how much time and effort has been wasted during the actual software development process, despite the initial, marginal savings in mockup design. One must also take in account that the hourly rates for developers are typically higher than those of UI designers, so that it doesn't make much sense to increase productivity of the latter at the expense of the former.
micheljansen 3y ago
... for pages! Modals are often fine for dialogs and fleeting interactions that happen within the context of the page you are on. Those often don't need their own URL. Don't need to persist after a page refresh, shouldn't be shared, confusingly pollute browser history and benefit from instant loading. I mostly agree with the author in their examples. If it walks like a page and it talks like a page, it probably should be a page. No need to throw the baby out with the bathwater otherwise.
- gwbas1c 3y ago
  From TFA: > Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: - Alerts - Confirmation dialogs - Forms for creating/updating entities
revskill 3y ago
Written by a confusing developer who love to reinvent the wheel all the time.
jmbwell 3y ago
Commenters may wish to note the last section of the article: > Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: > Alerts > Confirmation dialogs > Forms for creating/updating entities
j3th9n 3y ago
I want it to close when I click outside of the window.
mbostleman 3y ago
I hate separate pages because I lose all the context in the background. More often that not, I find myself needing info from the main page and often have to go back to it. Same thing happens on modals that you can't grab the title bar and drag it around.
- prmoustache 3y ago
  That is only a problem on mobile where you can hardly have 2 windows open on the same screen. But then modals suck on mobile too.
davidthewatson 3y ago
The whole subject of modality in design is a long story but the short story is that we should not mistake the need for ease of implementation with the need for clarity of design. They are orthogonal. There is no question that a design gets easier to parse for users when it is serialized by modality. Likewise, serialization is dramatically easier for implementors since it eliminates the need for concurrent execution. Context matters. Those choices have strong historical reasons for their existence in operating systems and their user interfaces. However, they have little place for being emulated on the web. Why? Because they give rise to all manner of bad implementation such as the fact that linking structures have not grown at the pace they should have, particularly as it relates to documentation. All you have to do is look at Amazon's constant proxy to "click here, click there" as a sad excuse for why HCIs don't scale at the same rate as APIs and you can condemn a large portion of the last two decades of design on the internet since these patterns have been copied ad nauseum but only exist because we've employed tools that automated their creation when a link has always been worth a thousand words of "click here, click there". REST applies to HCIs as much or more than APIs.
dncornholio 3y ago
Disagree, you can put the info in whatever box you want. Just make it so that you can copy-paste the URL and you will see the same page with the same modal openen.
deleted 3y ago
[deleted]
mrpelz 3y ago
1. you can certainly implement good user interface accessibility in both page-based websites and single-page applications, the latter requiring time, knowledge, and proper prioritization within the project 2. once again, there is a failure here to recognize which use cases are best served by a website (i.e., a set of web pages that use native browser navigation) or by a single-page application (which takes native UI paradigms such as multiple windows and modals and implements them using web technologies) 3. blanket criticism for single-page applications often comes from people who have no real understanding of web development and harbor nostalgia for the "good old days" when browsers acted only as display devices for server-generated HTML strings; those people aren't worth arguing with, I don't have time for them, I'd rather spend my time improving web technologies so that more people can implement applications that feel "native" yet work across different architectures, devices, screen sizes, languages, and writing directions, built on top of a platform that is privacy-centric by default, and not controlled by a single company
jrochkind1 3y ago
"To compensate for slow page load" is probably my main use (still rare), and, hey, sometimes you've got slow page load. Another reason might be to avoid losing state on the underlying page. If you have a "SPA" style app, it might obviate both of these reasons. In an SPA app (ideally one with good URL and back button behavior of course) the difference between a modal window and a separate page perhaps becomes _only_ one of UX, which presentation is better? But in a more traditional server-side-rendered app with minimal UI-focused JS, other considerations still exist which are legitimate, it seems to me.
- konha 3y ago
  > In an SPA app (ideally one with good URL and back button behavior of course) Those are rare. So much easier to mess up than to match native browser UX.
notatoad 3y ago
This is one of those things that sounds good when presented like this. But it's just the opinion of some guy. Run it through user testing and see how your users actually react to new windows being opened all the time. A lot of them are going to be confused, and not be able to make it back to your site. Modals are popular because they work
- padjo 3y ago
  I think they’re saying you should use a new “page”, not a new window.
  - notatoad 3y ago
    sure, that works if you can use a new page. but usually if i'm throwing up a modal, it's because i need to preserve some context on the existing page that might be lost by navigating away from it. so the choice is a new window, or a modal. and at least in my use, the modal is always the better choice there. especially since the advent of <dialog>
davedx 3y ago
> Forms for creating/updating entities Sprinting along delightfully, getting everything right, every piston firing... then falls on face at the last hurdle. No, don't put forms in modals, gah!
1337shadow 3y ago
When external pages can show in modals or separately because you are using Unpoly.js then it's perfect
ibejoeb 3y ago
It seems like a lot of people don't really consider what it really means to be "modal," and when it comes up, I describe it something like this: A modal is not, in itself, an overaly, window, frame, etc. Generally, it really shouldn't even be used as a noun. Modal describes the state of the interface. Most interfaces allow for multiple user interactions originating from the broader interface, i.e., it is multi-modal. Sometimes, it is necessary to put the UI into a single-purpose state, so, in a single mode. This is required when two interactions can interfere with one another. When one interaction must not be interrupted by another, we must go modal. The author seems to be chiefly complaining about unnecessary modality and the way that gives rise to clunky UIs that don't allow for things like linking. That's rooted in conflating on-screen, 3D elements like overlay dialog boxes with the concept of one of some interface being modal. An example of this would be an interface with a item list that, on item selection, conjures a modal overlay dialog box with the item details. In the base case, there is no dependency problem here, i.e., it's an entirely acceptable design to allow a user to view the details of two items at the same time, and therefor it doesn't call for a modal detail interface.
- ericyd 3y ago
  Modal is a common term for a UI element, as used in the site. I'm not saying you're wrong, per se, but I think you're missing the point, or perhaps missing context into modern UI design terminology
  - ibejoeb 3y ago
    I'm willing to hear your argument. I could have done without you telling me that maybe I'm just out of the loop, because there's a point to be made here. But let me entertain the notion. What is a modal?
    - eropple 3y ago
      "A modal" is a specific term of art referring to set of UI elements that floats over other content, compels focus, and disallows interaction with UI elements behind it. That's it. That's what it is. You're arguing with accepted terminology. "Well actually, do ships really have beams, isn't that a light thing?" doesn't really get far either.
deleted 3y ago
[deleted]
nonethewiser 3y ago
> Modal windows can't be bookmarked or shared as links. Deep linking can be added to modals, but it's complex. What will show up in the background when the link is followed? How much application state needs to be restored? How will the user be confident that it will work? Why is there a completely untested assumption that everything should be linkable?
asynchronous 3y ago
While I agree with the author, I can’t actually think of an example where a modal is being misused in this context? Every application I’ve worked on with a ‘resource detail’ component had a open in new tab hyperlink.
derekzhouzhen 3y ago
I'd even argue all html modals are bad designs; including alerts, forms, and confirmations. HTML modals are poor emulations of native dialog boxes; they try to address rendering performance problems that no longer exist.
corry 3y ago
The article seems to pay scant attention to THE main reason modals make sense to me: they allow for a discrete bit of work to be completed within the greater context of the app, without losing state or position. Loading a new page, new tab, or simply navigating fully away to a new editing screen are all pretty heavy disorienting actions for something that could be pretty light. But it's related to the amount of work being done in the modal. For a very small amount of work (e.g. editing a single text field), inline-editing would be best; for a lot of work (e.g. composing a bunch of textboxes and including other data, etc) a dedicated page is best. A modal belongs somewhere in-between - editing a few things at once, in context of other things. "Can this modal be an inline-edit?" <-- first question I'd ask. If the answer is No: "Will the work being done on the modal take more than 2 minutes to do?" <--- then I'd consider a separate page. But things in-between seem perfect for a modal.
- ericyd 3y ago
  No disagreement. In my experience though, modals are used in far too many places. I think if your criteria were applied diligently to every design, this site (and the motivation behind it) wouldn't exist
- deleted 3y ago
  [deleted]
  - deleted 3y ago
    [deleted]
- hombre_fatal 3y ago
  I'd go even further and say that modals make sense in almost any context where there's some underlying state whether it's a game, form, or even just scroll position in a forum thread. And I don't see why the modal needs to be limited to quick jobs like inline edits. It could be the place where the bulk of the tasks are done. Modals done well can remove anxiety and uncertainty from the user. One example that comes to mind having just bought plane tickets is that the plane ticket flow could be an underlying all-on-one-page UI (flight -> seats -> payment) where each section opens as a form modal on top of that state. You can close modals, open previous sections, edit completed sections, where the modals communicated that you're not losing state by navigating between forms. One of the best UX aspects of the modal is seeing the underlying state behind it and behind able to click out of the modal to return to it. Meanwhile, when buying tickets 30 min ago, the airline website had a sequence of pages where, I found out, going back to make an edit on a previous page reset the state of the subsequent pages. Obviously they could improve that without modals, but modals communicate state preservation by their nature. Modals get too much hate just because they can be done poorly. Most UX is done poorly and that's not a reason to wash your hands of it.
andix 3y ago
I hate them, but our UX designers use them everywhere. I try to fight back, but their "usability studies" always comeback in favour of modals. I really don't get it. We're doing mostly SPAs, so any back-button would be as fast as closing the modal.
bob1029 3y ago
I mostly agree with this. I've been refactoring some "modals" that have 30+ fields. Ultimately, I prefer the idea of subdividing a gigantic web app resource into smaller pieces whenever it isn't entirely catastrophic for the UX. For example: /MyResource/123 (all operations happen here as various "Modes") vs /MyResource/123/View /MyResource/123/Export /MyResource/123/EditPropertyA /MyResource/123/EditPropertyB /MyResource/123/Delete etc... This doesn't work for all things, but I mostly build internal admin dashboards when I am doing web development. One other benefit to using full routable pages for your various views is that you can subdivide the work a lot more easily. Assuming you have some common layout/style system (which you absolutely should), you can realistically part out the dev work at the grain of a URL at a time. We still have a few modals, but they are all of the "confirm scary operation XYZ" variety.
KevinChen6 3y ago
I think whether to use modal window or not should be case-by-case basis. I once refactored a web application for a data analysis platform using a front-end framework that I developed myself, and many of the prompts and information display functions in this framework are implemented through modal windows. When we showed the system to customer, we still gained a little acceptance. Of course, this internal private system doesn't need to do SEO optimization and indexed by search engines, if there is such a demand, using modal windows may not be the best way.
usrbinbash 3y ago
> You don't need a modal window You don't need most of the cruft that clutters "modern" webpages. While not solely responsible, ever more "clever design" has certainly contributed to the status quo, where we load upwards 30MB of garbage to display <10 lines of information.
hk1337 3y ago
Like with a lot of things, modals get overused then people get sick of seeing modals everywhere and go anti-modal. Bootstrap probably helped contribute to that. Modals have their use and function. Don't overdo it and maybe even provide non-modal options in addition to the modal.
zuprau 3y ago
Preach. You don't even necessarily need to place it in a new page, probably you can just expand it inline. Most modals are just lazy. "Where should I put this piece of UI/information?" "Just place it above everything else." With SPAs you don't even have an excuse that "a full-page reload will take longer" because you can change the whole page/layout instantly.
zethus 3y ago
A part of me wishes the "Bonus: RESTful UI" section at the bottom opened a "Coming soon" modal
ulrischa 3y ago
Plus: Not accessible
b1nj0y 3y ago
A stupid post

I guarantee this was written by somebody who has never worked as a professional UI/UX designer It’s the kind of bold, blanket statement that sounds really great and is a fun opinion to hold, but when confronted with reality crumbles (as many statements of that kind do).

zuprau 3y ago
> somebody who has never worked as a professional UI/UX designer Such as the Nielsen Norman Group. > "Do not use modal dialogs for nonessential information that is not related to the current user flow." > From https://www.nngroup.com/articles/modal-nonmodal-dialog/ https://www.nngroup.com/articles/modal-nonmodal-dialog/ Nonessential information such as, let's say, "details." I'd say that this minisite is exactly on point.

sva_ 3y ago

For some reason I thought this was someone complaining about those German windows we have in our houses, that open two ways.

NeoTar 3y ago
Why would anyone want to complain about those?
- deleted 3y ago
  [deleted]
- afandian 3y ago
  Most glaziers probably don't care about modal dialogue boxes.

dvh 3y ago

Yes I do. Not every software is cathedral built on a green field with unlimited budget. Sometimes you just need to smack an alert() or confirm() or prompt() in the middle of code and move on to more important stuff.

aembleton 3y ago
Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: Alerts Confirmation dialogs Forms for creating/updating entities

spaceman_2020 3y ago

I disagree. Modal windows are great if the information is small enough that it can be digested in a single glance. Making me open up a new tab to view a paragraph of text is just plain annoying.

vaylian 3y ago
Then just create a new <div> that shows the information inline.

ThatMedicIsASpy 3y ago

I click on the examples and it throws the page back to the top. I refuse to read anything that is said after the example being useless.

throwawaaarrgh 3y ago

ThisIsAShittyClickbaitArticleWhyIsItAnEntireWebsite.dev

gloryless 3y ago

Most of this post is trying to declare rules that just aren't true. Even Asana will deep link a modal, it's just another piece of state in the url

golergka 3y ago

Details pages with a lot of information? Bad fit. Small messages that need to be brought to the user's attention and a simple "OK"/"Cancel" button? Yes, this is a good fit. That's what modal windows were originally created for.

PaulHoule 3y ago
I think the first article I saw complaining about modals was in BYTE magazine circa 1981.
ceejayoz 3y ago
The end of the article says exactly that.
pornel 3y ago
I've seen confused users who missed/ignored the tiny OK window, and through the app froze, because the large parent window stopped reacting to clicks.
- dieulot 3y ago
  iOS ⩽ 6 used a radial gradient effect to make it clear that the modal is what’s to be interacted with.
- YurgenJurgensen 3y ago
  MS Outlook is very good at opening modals that block interactivity with the main window. And opening them on a different monitor to the original window (even if said monitor is full-screening a different application so the modal actually opens on a currently-invisible workspace) so it's not even obvious why.
- dspillett 3y ago
  For a HTML based presentation you probably have a backing element that covers the rest of the page to trap clicks anyway. Make this partially opaque instead of transparent and the modal becomes much more obvious. Or if you want to be a bit more fancy and can rely on the user having a browser newer than July 2022 perhaps use backdrop-filter to apply a blur instead of just being partially opaque. You can do the same on a desktop app too, but it is less commonly done. To further avoid confusion, try make sure the pop-up modal appears over the parent window that it is blocking input for (this may mean coding your own window instead of the platform default alert/confirmation box, if the call to open one doesn't allow positioning information to be specified). I've seen alerts/confirmations pop-up on a different screen to the one that the parent window is on which makes missing it much easier (especially if the other screen is away from the main one, perhaps it is being projected at a wall for a demo). To further help: if the user clicks the disabled parent, move the pop-up to where they clicked – usually the title-bar or other chrome on the pop-up flashes in this case, but that isn't helpful if it is on screen 2 and the user is staring intently at screen 1.

efitz 3y ago

People who implement modal windows are antisocial. And, there is a special place in hell for people who implement system modal windows.

GoToRO 3y ago
It happens like this: some manager just wants a simple modal to show some details (see, he is not just a failed developer, he knows words, like modal). Do we need it to have it's own url? No. Do we need to edit the data? No! Just a simple modal! Why are you asking all these questions? The thing gets implemented and the users like how fast the data is shown. But can we just add some action buttons like Accept and Reject instead of the Ok button? Why close the modal and then hit an action button when you can have them right there? The buttons get implemented, the users love it. Manager comes back, but can we edit one or two fields? Sure. Some of the fields will open a modal to let users select the value. Should we reimplement it as a regular page so we don't have a modal in another modal? Manager: No, that will take forever. Validation, error messages, scrollbars? The manager refuses to fix it because he burned through all the allocated time and he doesn't want to have a difficult discussion with the stakeholders. And anyway, in these meetings the developers are not invited and he can just blame the developers because everybody knows how entitled they are.

extasia 3y ago

Love your username, OP.

qwertox 3y ago

Above all, please respect that a middle mouse button is supposed to open a link in a new tab.

worldsayshi 3y ago
Oh, I always use ctrl click. Ditto.
- Akronymus 3y ago
  Too often, links are just buttons that navigate you to the url when you click on it. It just ignores modifiers. It makes me furious
  - worldsayshi 3y ago
    Yeah as a user I'm annoyed how often modifiers are circumvented. As a developer I'm annoyed at how often I end up in a situation where I have to reinvent 'click to follow a link' and where it's really tedious to also reimplement modifiers.
Alifatisk 3y ago
And on mouspads or touch?
- gramvoir 3y ago
  On mousepad its the same same. If yours misses the middle button either switch to a real one (Thinkpad) or use left+right.
  - Alifatisk 3y ago
    Totally forgot about left + right!!!
- deleted 3y ago
  [deleted]
- 3y ago

huhtenberg 3y ago

> Don't open the details in a modal window. Have it be a separate page. This will worsen the UX more often than not. Guaranteed. All complaints on the page are ultimately grievances against poorly thought-through implementations and as such they are rooted in the wrong thing. It's trivial to complement every modal window with a standalone version, in which case it's possible to bookmark them, middle-click on the links and what have you. Start with the user experience, craft your implementation around that and all will be fine. Including the modal windows.

reaperducer 3y ago
This will worsen the UX more often than not. Guaranteed. You must use "telemetry" instead of actually talking to your users. My company requires me to talk to the people who use the web sites I build. (I has a session just yesterday.) They hate modal windows. They even still refer to them as "pop-ups."
- oefrha 3y ago
  Your company requires you to talk to users, yet it seems you still haven’t gotten the memo that you shouldn’t make blanket assumptions without talking to people about actual use cases. “Users hate modal windows” is about as meaningless as “users hate open in new tab” without context.
  - reaperducer 3y ago
    You pontificate, but didn't get the memo about not making things up. I never made any blanket assumptions and never wrote "Users hate modal windows." Reading is fundamental.
    - oefrha 3y ago
      [flagged]
      - reaperducer 3y ago

0xedb 3y ago

Next.js 13 has a neat solution: parallel routes (https://nextjs.org/docs/app/building-your-application/routing/parallel-routes#modals https://nextjs.org/docs/app/building-your-application/routin...)

worldsayshi 3y ago
I tried Next.js very briefly and I initially found this concept really nice. However I bounced back and gave up on the framework for some related reason. I felt like I gave up control to much, maybe due to the routing model. Feels like some common problems were made much harder because of it.
- scrollaway 3y ago
  I implemented it in a bookkeeping app I’m working on. It works nicely but the documentation is very poor; I had to constantly refer to a third party example. Once you get how it works it’s neat.

nologic01 3y ago

The Treachery of Modals: Ceci n'est pas une page

amelius 3y ago

Yes. Why does nobody use alert() anymore?

ExtremisAndy 3y ago
I always use it while developing a new web app, but admit that I always switch it to something "fancier" in production, mainly because I find alerts rather ugly. But, goodness gracious, it would simplify so many things! I've just sort of assumed that default browser alerts were considered a big no-no these days, but that assumption comes from the fact that I simply don't see them being used much. I guess I should look into this more. Sure would shorten dev times!

tobr 3y ago

Counterpoint: This is a little like arguing that you should use GOTO instead of call stacks. Like a function call, with a modal you keep your place and know you will be able return to where you were. No risk of getting lost. Linking to a separate page is like GOTO control flow. You leave it up to the user to figure out where to go from there, but the user usually doesn’t know the full sequence of steps that are part of a task. It’s your responsibility to guide them.

ab_goat 3y ago

I used to feel this way and would make everything linkable, but then I realized that modals are really good at preventing users from getting lost by adding context instead of swapping context. For example, a user may want to edit a few items items in a list Rather than forcing the user to a new page to do each edit, you can pop up a modal and edit in place. With new pages, the user loses the context of the original list. The page swapping is very disruptive.

l5870uoo9y 3y ago
I concur. I think this page[1] illustrates it quite well. [1]: https://gwern.net/index https://gwern.net/index
- EnergyAmy 3y ago
  That's actually a super weird implementation. I can hover over a link and open a modal preview, and then hover over a link in that modal to open another modal, ad infinitum. I ended up with 20 modals covering the page, and then moved my mouse a little too much and they all disappeared at once. Also, if you click on something in the modal, you end up getting redirected to a new page anyways, which kind of supports the anti-modal argument. OTOH, I like Wikipedia's hover previews just fine, so sometimes they're OK.
kypro 3y ago
There are normally better approaches to a modal popup. In this case I'd consider expanding the item on the page when preforming an edit. That way it's clear to the user they're on the same page so won't be tempted to click back and you won't need to worry about confusing keyboard / screen reader users. Alternatively if you absolutely need to use a modal consider a slide out instead. Slide outs tend to look less like new pages and reduce the likelihood of a user clicking back to "go back" to whatever they were previously looking at. With a slide out the original content is still in view, but now you have some extra options to the side. You still have all the accessibility issues of course, but the UX is slightly better most of the time.
e1g 3y ago

js8 3y ago

The worst modal window is the save dialog in Firefox. Often I need to see something in the page to put into filename, and the save dialog blocks it.

aendruk 3y ago
A few years ago GNOME started doing this all over the place. Modals are spatially coupled to the parent window so moving the modal moves the parent too. Drives me crazy that I can’t refer to the information underneath.
- smeagull 3y ago
  GNOME is a lost cause. Once they started shadowing keybindings from readline they failed at UX.
deleted 3y ago
[deleted]

yawnxyz 3y ago

If your page loads are slower than 200ms, I'd actually suggest having modals. Or at least some way of progressively showing more information (toggles, accordions, etc.) that stay on page. SPA page loads can get really slow, which can frustrate or disorient users. Having too many page loads to sequentially drill down your info architecture can get really annoying for users. If your pages are 1 or 2 layers deep in your architecture, and the rest is shown in some way within the page (again, modals are one way to do it), as a piece of "fleeting information", your users will appreciate it.

arghwhat 3y ago
For an SPA, there is no difference in loading time between a modal and non-modal view. The (annoying) SPA penalty is initial page load, which is a one-time cost. The location changes are virtual through the history API, with a reload just causing the SPA to start from that location instead of from the root/home view.
- thecopy 3y ago
  >there is no difference in loading time between a modal and non-modal view AWS Management Console begs to differ:)
  - arghwhat 3y ago
    Okay fair: there is no technical reason for any such difference, but bad web apps be bad. :P
quickthrower2 3y ago
Jira has slow loading modals

EduardoBautista 3y ago

> Modal windows can't be bookmarked or shared as links. Modals can definitely be bookmarkable if they are dependent on a certain path or query param to appear.

NavyG 3y ago

> Modal windows can't be bookmarked or shared as links We use modal windows specifically for this reason (for our payment application's checkout page). Also using a modal significantly improves the checkout experience in case of SDK flows for payment methods like Klarna, Google pay etc. Personally I feel modal windows are better aligned to the user's flow of attention. We also have redirection flows for these payment methods to open the authentication page in a new tab but we pick the modal flow ever single time for a better experience. You can get a feel of what I'm talking about over here: https://demo-hyperswitch.netlify.app/checkout https://demo-hyperswitch.netlify.app/checkout

sureglymop 3y ago

Modal Windows absolutely can be shared with a link if done well. Open the modal as an overlay and set the url with javascript. Then also have a noscript tag which contains a link to that (modal) page. On the server side you just need to make sure that you can render that page and serve it. This is pretty much how imo. modern SSR frameworks like sveltekit are intended to be used. Of course if non-js users aren't a concern, you can do this with an SPA too, the client side routing just needs to be programmed right and the server needs to serve the bundle correctly.

Gabrys1 3y ago

Last paragraph says this: > Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: > [...] > Forms for creating/updating entities Wow, in my opinion this a perfect example where a separate page IS still superior to a modal: how much better a "create issue" jira PAGE is vs the modal?

deniz-a 3y ago
If users are expected to spend a long time and use many tools to compose something, then I agree a full page form is best. For something like adding to a todo list, or where users are expected to add many items one after the other, a modal is better. You can also take a hybrid approach: many calendar apps have a small popup for adding an event that the user can expand into a whole (nonmodal) window for editing all the details.

deleted 3y ago

[deleted]

physicsguy 3y ago

The issue is that as web software becomes more and more complex and desktop-esque, it needs features that were common in desktop software. It's a poor user experience to open a new window for lots of things in the browser, but that sort of functionality is still needed sometimes. If I think about the engineering product I work on and where they do have modals, none of them would work with a separate page. It's things like "Load one or more of your saved graphs (which you can search and filter) into this existing page of graphs"

kypro 3y ago

> Modal windows are hard to get right. The "final boss of accessibility" Lmao, I was making this point at work yesterday. It's really difficult to justify using a modal if you care about accessibility. It's not that it's impossible to do correctly, but even when it's done "correctly" it can still be confusing for users navigating with keyboards / screen readers. So modals are almost always either too much effort to do right, or just not the best approach. Another thing I'd add to this list is that there are some people who browse without JS enabled. I know it's unpopular to care about those folks these days, but it is another reason to avoid modals where possible.

lelandfe 3y ago
I would like to care about JS-disablers, but it is a disproportionally large amount of work for something a few people are choosing to do. I try to give it a best effort, but won’t e.g. rebuild a menu as an HTML checkbox just because some folks are hardliners about running Javascript.
- tvararu 3y ago
  "Everyone has JS, right?" https://www.kryogenix.org/code/browser/everyonehasjs.html https://www.kryogenix.org/code/browser/everyonehasjs.html
  - lelandfe 3y ago
    Only one part of this, which we're already talking about, is relevant here.
pavlov 3y ago
Modals and accessibility was a completely solved problem in 1990s desktop UIs. If anything modals were considered the “easy mode” of UI design. (You can see this in applications like Photoshop that retain some of the original early ‘90s modal-centric design.) It’s crazy how much the web platform’s lack of UI expressivity has set us back. Everything is constantly getting desperately reinvented out of a handful of text markup tags cobbled together by scripts, but it doesn’t solve any of the underlying issues.

jcmontx 3y ago

Bootcamp React developers discover MPAs

jasonlotito 3y ago

Modal Windows: If you put up a modal window, and it blocks content beneath it, and I can't at least move it out of the way, then it 100% is anti-user behavior. There is NO good reason for blocking the user from seeing content that might be relevant to the modal window. This is true for both websites and apps. Compare Safari's Open File to Chrome's Open File. Chrome's Open File modal cannot be moved. Safari's can. If you have a modal, and it blocks content, you have to be willing to say "I want to prevent my users from seeing this content while dealing with the modal. The content that is being blocked is not important, and it serves NO purpose."

vaylian 3y ago

Modals disempower the user. That's why they are so popular with mandatory Cookie selection dialogs.

quickthrower2 3y ago

I was thinking this today as I was using JIRA. I would live JIRA to be a boring and more RESTful web app. I hit a bug where if I closed the popup (for a ticket on a board) it just reopened! And some ticket links don’t work. All these bugs and complexity for what? Maybe the browsers should have a built in “open link as popup” for the rare times you want that. And the sites just make it a new page always.

dan-robertson 3y ago
I think Jira performance already seems to be dominated by roundtrips to the servers. Making it more like what you describe may make it even worse.
- quickthrower2 3y ago
  Yeah they need to sort their app performance out. That said the modal load is just as slow.
  - throwawaaarrgh 3y ago
    Actually Jira has multiple examples of "new page over modal" and it's the worst UX in Jira. If you try to perform bulk edits, it'll bring you to a brand new page with all the items you want to modify, and ask you to click some things ("what kind of X should I do to these tickets"). You click stuff and hit Submit, and it goes to yet another new page with all the tickets and asks you to select more things. Then you click Submit, and it brings you to yet another new page where you click another set of things, and hit Submit. 3 entirely new page loads, and then you go back to the original page. You can't hyperlink to any of these pages because they're part of a bulk edit applying to many items in intermediate states. Each page load takes at least 5 seconds. You can't see any of the context of where you were before, and when you go finally go back, you lose some of what you were doing/displaying before. A modal would be much faster because the entire page wouldn't need to reload 3 times, you already can't bookmark specific sections in the new pages, and if you wanted to cancel the operation you could get back to the original page much faster (technically you're already on it), with the original context of the original page still intact.

nfRfqX5n 3y ago

I've seen tons of feedback directly from customers which indicate the opposite, losing context is super annoying

layer8 3y ago
That's orthogonal to modals.
- sowbug 3y ago
  In defense of those customers, the back button has become a game of Russian roulette. Most of the time it takes you back to the page or UI state you were on. The rest of the time it breaks the JS, takes you to an awful "before you go" page you never navigated to, displays the mysterious "confirm form resubmission" dialog, or in the case of the infamous Treasury Direct site, marks your account as disabled until you perform a new kind of corporeal signing ritual that your local bank branch manager has never even heard of but apparently must now perform with you. It's sadly reasonable not to expect users to trust, or even try, the back button.

projektfu 3y ago

THANK YOU OMG I have lots of frustration with modal views that: 1. block me from seeing the things that I probably need to enter into the view 2. disappear when you accidentally click outside them 3. don't scroll properly 4. don't allow scrolling of the page behind 5. don't play well with reasonable browser extensions (uBlock, but other things as well like Disconnect) or even the tracking prevention build into browsers. 6. store data in a weird place so that a second window of the same site in a different location opens the same (now incorrect) data in the modal. These things are becoming super common in line-of-business apps, where they interrupt workflow. Better options: 1. New page, as recommended by this link 2. Expanding a region of interest to allow the form to fit 3. Making the page more interactive in other ways so that a modal doesn't seem like the best way to do the interaction

deleted 3y ago

[deleted]

dadalorian 3y ago

Ironic that the popover API was just announced 2 days ago. https://developer.chrome.com/en/blog/introducing-popover-api/ https://developer.chrome.com/en/blog/introducing-popover-api...

000ooo000 3y ago

youdontneedadomainforyouronepagepedantry.com

000ooo000 3y ago
Cheap shots aside, this was a very unconvincing set of arguments. Would it have not been a better use of ones time, both the author and reader's, to have documented both the pros and cons of modals instead of this lame, "trendy", You don't need takedown?
DonHopkins 3y ago
you-do-need-dashes-between-the-words-in-the-domain-name-of-your-one-page-pedantry-because-then-you-can-clearly-communicate-your-message-without-actually-requiring-people-to-click-on-the-link-or-even-bothering-registering-the-domain-or-putting-up-a-web-site-unless-of-course-you-are-just-publishing-click-bait-to-sell-ads-in-which-case-fuck-off.com

marcofiset 3y ago

Phoenix LiveView handles all of those concerns extremely well and pretty much for free. All of my modals are tied to a live action in a given live view. You can bookmark them, use the browser back button to close them and the state "under the modal" is a complete non-issue. It's just loaded as part of the live view and a modal is shown only on specific actions. That may sound like gibberish if you're not familiar with Phoenix LiveView, but it all makes sense and it just works.

nicbou 3y ago

What are good alternatives? I like <details> and collapsible panels.

2bitlobster 3y ago

[flagged]

DonHopkins 3y ago

We use too many damn modals (2018) (modalzmodalzmodalz.com) https://modalzmodalzmodalz.com/ https://modalzmodalzmodalz.com/ MODALZMODALZMODALZ.COM >We use too many damn modals. Let's just not. Help >The bad news: Modals are the crutch of the inarticulate designer and developer. [...] https://news.ycombinator.com/item?id=23645447 https://news.ycombinator.com/item?id=23645447 >bedatadriven on June 25, 2020 | next [–] >I was just about to share this our designer, who is always talking me down from modals, when I reached the bottom and discovered that our designer is in fact the author. >I seriously can't say enough for this message. Adrian helped us redesign our app 2 years ago, dispatching many many modals in the process, and delivering a huge increase in usability that our customers and users very much do care about.

chakintosh 3y ago

As a UX designer, I wholeheartedly disagree. > Modal windows can't be bookmarked or shared as links Why would the user want to bookmark or share a "modal". I believe the author is confusing a modal with a details page (a customer's details page in a CRM for example) on that we can agree that that kind of content is best shown on a separate page. A modal serves a specific function within a web page, be it a website or a web app. Its main function is to allow the user to perform certain tasks within a page, and those tasks will immediately reflect on the underlying page upon submission (or validation/confirmation ..etc). So I fail to understand why the author thinks a user would want to bookmark that modal. > Modal windows can't be opened in a new tab Nor should they. Modals, as mentioned above, are one layer above an underlying page, and they either show complimentary information related to an element within that page, or they allow to user to performa task. So they should inherently be accessible within the same tab, not a new one. > Modal windows make the Back button confusing Aside from the Close/Abort button inside the modal, a lot of interaction designers and front-end developers are now developing the modals in a way they would close if you press the back button of your browser. No confusion there in my opinion. > Modal windows are hard to get right[...]if you need to support older browsers, good luck. Can't find the date this article was published but I assume it's old because almost all new browsers support at least <dialog> element [1] Modals are a double edged sword, like any UI component or UX pattern really. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog#browser_compatibility https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di... Further reading: https://www.nngroup.com/articles/modal-nonmodal-dialog/ https://www.nngroup.com/articles/modal-nonmodal-dialog/

monooso 3y ago
> I believe the author is confusing a modal with a details page It sounds like you agree with the article, at least according to my reading. The author states that you should not use a modal for something “bookmarkable”, such as a details page. They also state that a modal is suitable for performing an action that does not warrant a “resource URL”, such as a “create resource” form.
- teawrecks 3y ago

motoboi 3y ago

I like the azure portal solution, where everything opens in a modal, in the form of a panel. When the link is followed, the panel opens as the main window.

ptx 3y ago

I think the author's objections can all be addressed by using history.pushState() and treating the modal window like navigation to a subpage/route (in an SPA-style app). This way the modal will have a URL, so it can be bookmarked, can be opened in a new tab (if it's opened through a link) and the back button will work (closing the modal).

roblh 3y ago
This works, except when it doesn’t. I’m not sure about react, but Vue router has some funny and unintuitive interactions when you do this which will often result in unnecessary page reloads, either when you push state or when the back button pops it again. Maybe react behaves better but my experience with it has made me not want to directly mess with history unless I have a particularly good reason to.
- ptx 3y ago
  It seemed to work well in Angular in the tiny app where I tried it, but to be clear I didn't directly mess with the history API – I used the navigation mechanisms of the Angular framework to manage this. Calling the browser history API directly could probably confuse the framework.
aflukasz 3y ago
> and the back button will work (closing the modal). Which opens a whole new can of worms! What is the meaning of pressing "back" when modal window is shown? Is it "cancel"? What if I already changed something within the modal? What if "back" causes losing some input within the modal? Should we... show another modal for confirmation of going back? Same with navigation via "back"/"forward" into a modal (which is now present on the history stack) - if this was modal with some action... can I execute it again? Did I just execute it by navigating into it?

myth2018 3y ago

I would expand my criticism to elements such as material design drawers and similar ones. Regardless of the support provided by the platform (`<dialog>`, convenient APIs etc), you may still find yourself fighting with the resulting state -- for instance, when the screen must adjust its behavior and/or content according to dialog's content or state. The requirements in such situations can get overwhelming quite quickly. > Because it looked good in the mockup Indeed, tools like Figma can create a dangerous illusion of simplicity. I wonder how much time and effort has been wasted during the actual software development process, despite the initial, marginal savings in mockup design. One must also take in account that the hourly rates for developers are typically higher than those of UI designers, so that it doesn't make much sense to increase productivity of the latter at the expense of the former.

micheljansen 3y ago

... for pages! Modals are often fine for dialogs and fleeting interactions that happen within the context of the page you are on. Those often don't need their own URL. Don't need to persist after a page refresh, shouldn't be shared, confusingly pollute browser history and benefit from instant loading. I mostly agree with the author in their examples. If it walks like a page and it talks like a page, it probably should be a page. No need to throw the baby out with the bathwater otherwise.

gwbas1c 3y ago
From TFA: > Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: - Alerts - Confirmation dialogs - Forms for creating/updating entities

revskill 3y ago

Written by a confusing developer who love to reinvent the wheel all the time.

jmbwell 3y ago

Commenters may wish to note the last section of the article: > Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: > Alerts > Confirmation dialogs > Forms for creating/updating entities

j3th9n 3y ago

I want it to close when I click outside of the window.

mbostleman 3y ago

I hate separate pages because I lose all the context in the background. More often that not, I find myself needing info from the main page and often have to go back to it. Same thing happens on modals that you can't grab the title bar and drag it around.

prmoustache 3y ago
That is only a problem on mobile where you can hardly have 2 windows open on the same screen. But then modals suck on mobile too.

davidthewatson 3y ago

The whole subject of modality in design is a long story but the short story is that we should not mistake the need for ease of implementation with the need for clarity of design. They are orthogonal. There is no question that a design gets easier to parse for users when it is serialized by modality. Likewise, serialization is dramatically easier for implementors since it eliminates the need for concurrent execution. Context matters. Those choices have strong historical reasons for their existence in operating systems and their user interfaces. However, they have little place for being emulated on the web. Why? Because they give rise to all manner of bad implementation such as the fact that linking structures have not grown at the pace they should have, particularly as it relates to documentation. All you have to do is look at Amazon's constant proxy to "click here, click there" as a sad excuse for why HCIs don't scale at the same rate as APIs and you can condemn a large portion of the last two decades of design on the internet since these patterns have been copied ad nauseum but only exist because we've employed tools that automated their creation when a link has always been worth a thousand words of "click here, click there". REST applies to HCIs as much or more than APIs.

dncornholio 3y ago

Disagree, you can put the info in whatever box you want. Just make it so that you can copy-paste the URL and you will see the same page with the same modal openen.

deleted 3y ago

[deleted]

mrpelz 3y ago

1. you can certainly implement good user interface accessibility in both page-based websites and single-page applications, the latter requiring time, knowledge, and proper prioritization within the project 2. once again, there is a failure here to recognize which use cases are best served by a website (i.e., a set of web pages that use native browser navigation) or by a single-page application (which takes native UI paradigms such as multiple windows and modals and implements them using web technologies) 3. blanket criticism for single-page applications often comes from people who have no real understanding of web development and harbor nostalgia for the "good old days" when browsers acted only as display devices for server-generated HTML strings; those people aren't worth arguing with, I don't have time for them, I'd rather spend my time improving web technologies so that more people can implement applications that feel "native" yet work across different architectures, devices, screen sizes, languages, and writing directions, built on top of a platform that is privacy-centric by default, and not controlled by a single company

jrochkind1 3y ago

"To compensate for slow page load" is probably my main use (still rare), and, hey, sometimes you've got slow page load. Another reason might be to avoid losing state on the underlying page. If you have a "SPA" style app, it might obviate both of these reasons. In an SPA app (ideally one with good URL and back button behavior of course) the difference between a modal window and a separate page perhaps becomes _only_ one of UX, which presentation is better? But in a more traditional server-side-rendered app with minimal UI-focused JS, other considerations still exist which are legitimate, it seems to me.

konha 3y ago
> In an SPA app (ideally one with good URL and back button behavior of course) Those are rare. So much easier to mess up than to match native browser UX.

notatoad 3y ago

This is one of those things that sounds good when presented like this. But it's just the opinion of some guy. Run it through user testing and see how your users actually react to new windows being opened all the time. A lot of them are going to be confused, and not be able to make it back to your site. Modals are popular because they work

padjo 3y ago
I think they’re saying you should use a new “page”, not a new window.
- notatoad 3y ago
  sure, that works if you can use a new page. but usually if i'm throwing up a modal, it's because i need to preserve some context on the existing page that might be lost by navigating away from it. so the choice is a new window, or a modal. and at least in my use, the modal is always the better choice there. especially since the advent of <dialog>

davedx 3y ago

> Forms for creating/updating entities Sprinting along delightfully, getting everything right, every piston firing... then falls on face at the last hurdle. No, don't put forms in modals, gah!

1337shadow 3y ago

When external pages can show in modals or separately because you are using Unpoly.js then it's perfect

ibejoeb 3y ago

It seems like a lot of people don't really consider what it really means to be "modal," and when it comes up, I describe it something like this: A modal is not, in itself, an overaly, window, frame, etc. Generally, it really shouldn't even be used as a noun. Modal describes the state of the interface. Most interfaces allow for multiple user interactions originating from the broader interface, i.e., it is multi-modal. Sometimes, it is necessary to put the UI into a single-purpose state, so, in a single mode. This is required when two interactions can interfere with one another. When one interaction must not be interrupted by another, we must go modal. The author seems to be chiefly complaining about unnecessary modality and the way that gives rise to clunky UIs that don't allow for things like linking. That's rooted in conflating on-screen, 3D elements like overlay dialog boxes with the concept of one of some interface being modal. An example of this would be an interface with a item list that, on item selection, conjures a modal overlay dialog box with the item details. In the base case, there is no dependency problem here, i.e., it's an entirely acceptable design to allow a user to view the details of two items at the same time, and therefor it doesn't call for a modal detail interface.

ericyd 3y ago
Modal is a common term for a UI element, as used in the site. I'm not saying you're wrong, per se, but I think you're missing the point, or perhaps missing context into modern UI design terminology
- ibejoeb 3y ago
  I'm willing to hear your argument. I could have done without you telling me that maybe I'm just out of the loop, because there's a point to be made here. But let me entertain the notion. What is a modal?
  - eropple 3y ago
    "A modal" is a specific term of art referring to set of UI elements that floats over other content, compels focus, and disallows interaction with UI elements behind it. That's it. That's what it is. You're arguing with accepted terminology. "Well actually, do ships really have beams, isn't that a light thing?" doesn't really get far either.

deleted 3y ago

[deleted]

nonethewiser 3y ago

> Modal windows can't be bookmarked or shared as links. Deep linking can be added to modals, but it's complex. What will show up in the background when the link is followed? How much application state needs to be restored? How will the user be confident that it will work? Why is there a completely untested assumption that everything should be linkable?

asynchronous 3y ago

While I agree with the author, I can’t actually think of an example where a modal is being misused in this context? Every application I’ve worked on with a ‘resource detail’ component had a open in new tab hyperlink.

derekzhouzhen 3y ago

I'd even argue all html modals are bad designs; including alerts, forms, and confirmations. HTML modals are poor emulations of native dialog boxes; they try to address rendering performance problems that no longer exist.

corry 3y ago

The article seems to pay scant attention to THE main reason modals make sense to me: they allow for a discrete bit of work to be completed within the greater context of the app, without losing state or position. Loading a new page, new tab, or simply navigating fully away to a new editing screen are all pretty heavy disorienting actions for something that could be pretty light. But it's related to the amount of work being done in the modal. For a very small amount of work (e.g. editing a single text field), inline-editing would be best; for a lot of work (e.g. composing a bunch of textboxes and including other data, etc) a dedicated page is best. A modal belongs somewhere in-between - editing a few things at once, in context of other things. "Can this modal be an inline-edit?" <-- first question I'd ask. If the answer is No: "Will the work being done on the modal take more than 2 minutes to do?" <--- then I'd consider a separate page. But things in-between seem perfect for a modal.

ericyd 3y ago
No disagreement. In my experience though, modals are used in far too many places. I think if your criteria were applied diligently to every design, this site (and the motivation behind it) wouldn't exist
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]
hombre_fatal 3y ago
I'd go even further and say that modals make sense in almost any context where there's some underlying state whether it's a game, form, or even just scroll position in a forum thread. And I don't see why the modal needs to be limited to quick jobs like inline edits. It could be the place where the bulk of the tasks are done. Modals done well can remove anxiety and uncertainty from the user. One example that comes to mind having just bought plane tickets is that the plane ticket flow could be an underlying all-on-one-page UI (flight -> seats -> payment) where each section opens as a form modal on top of that state. You can close modals, open previous sections, edit completed sections, where the modals communicated that you're not losing state by navigating between forms. One of the best UX aspects of the modal is seeing the underlying state behind it and behind able to click out of the modal to return to it. Meanwhile, when buying tickets 30 min ago, the airline website had a sequence of pages where, I found out, going back to make an edit on a previous page reset the state of the subsequent pages. Obviously they could improve that without modals, but modals communicate state preservation by their nature. Modals get too much hate just because they can be done poorly. Most UX is done poorly and that's not a reason to wash your hands of it.

andix 3y ago

I hate them, but our UX designers use them everywhere. I try to fight back, but their "usability studies" always comeback in favour of modals. I really don't get it. We're doing mostly SPAs, so any back-button would be as fast as closing the modal.

bob1029 3y ago

I mostly agree with this. I've been refactoring some "modals" that have 30+ fields. Ultimately, I prefer the idea of subdividing a gigantic web app resource into smaller pieces whenever it isn't entirely catastrophic for the UX. For example: /MyResource/123 (all operations happen here as various "Modes") vs /MyResource/123/View /MyResource/123/Export /MyResource/123/EditPropertyA /MyResource/123/EditPropertyB /MyResource/123/Delete etc... This doesn't work for all things, but I mostly build internal admin dashboards when I am doing web development. One other benefit to using full routable pages for your various views is that you can subdivide the work a lot more easily. Assuming you have some common layout/style system (which you absolutely should), you can realistically part out the dev work at the grain of a URL at a time. We still have a few modals, but they are all of the "confirm scary operation XYZ" variety.

KevinChen6 3y ago

I think whether to use modal window or not should be case-by-case basis. I once refactored a web application for a data analysis platform using a front-end framework that I developed myself, and many of the prompts and information display functions in this framework are implemented through modal windows. When we showed the system to customer, we still gained a little acceptance. Of course, this internal private system doesn't need to do SEO optimization and indexed by search engines, if there is such a demand, using modal windows may not be the best way.

usrbinbash 3y ago

> You don't need a modal window You don't need most of the cruft that clutters "modern" webpages. While not solely responsible, ever more "clever design" has certainly contributed to the status quo, where we load upwards 30MB of garbage to display <10 lines of information.

hk1337 3y ago

Like with a lot of things, modals get overused then people get sick of seeing modals everywhere and go anti-modal. Bootstrap probably helped contribute to that. Modals have their use and function. Don't overdo it and maybe even provide non-modal options in addition to the modal.

zuprau 3y ago

Preach. You don't even necessarily need to place it in a new page, probably you can just expand it inline. Most modals are just lazy. "Where should I put this piece of UI/information?" "Just place it above everything else." With SPAs you don't even have an excuse that "a full-page reload will take longer" because you can change the whole page/layout instantly.

zethus 3y ago

A part of me wishes the "Bonus: RESTful UI" section at the bottom opened a "Coming soon" modal

ulrischa 3y ago

Plus: Not accessible

b1nj0y 3y ago

A stupid post