from Hacker News

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

by return_to_monke on 5/24/23, 11:12 AM with 292 comments

by corry on 5/24/23, 1:48 PM
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.
by huhtenberg on 5/24/23, 11:27 AM
> 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.
by chakintosh on 5/24/23, 12:33 PM
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/di...
Further reading: https://www.nngroup.com/articles/modal-nonmodal-dialog/
by ab_goat on 5/24/23, 11:38 AM
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.
by kypro on 5/24/23, 11:49 AM
> 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.
by qwertox on 5/24/23, 11:28 AM
Above all, please respect that a middle mouse button is supposed to open a link in a new tab.
by quickthrower2 on 5/24/23, 12:03 PM
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.
by ibejoeb on 5/24/23, 1:41 PM
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.
by notatoad on 5/24/23, 1:35 PM
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
by DonHopkins on 5/24/23, 12:33 PM
We use too many damn modals (2018) (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
>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.
by micheljansen on 5/24/23, 12:46 PM
... 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.
by jasonlotito on 5/24/23, 11:57 AM
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."
by zuprau on 5/24/23, 2:30 PM
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.
by ptx on 5/24/23, 12:36 PM
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).
by sva_ on 5/24/23, 11:22 AM
For some reason I thought this was someone complaining about those German windows we have in our houses, that open two ways.
by physicsguy on 5/24/23, 11:49 AM
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"
by davidthewatson on 5/24/23, 1:01 PM
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.
by HL33tibCe7 on 5/24/23, 12:34 PM
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).
by golergka on 5/24/23, 11:22 AM
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.
by efitz on 5/24/23, 11:32 AM
People who implement modal windows are antisocial. And, there is a special place in hell for people who implement system modal windows.
by jmbwell on 5/24/23, 12:54 PM
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
by myth2018 on 5/24/23, 12:44 PM
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.
by projektfu on 5/24/23, 12:08 PM
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
by 0xedb on 5/24/23, 11:27 AM
Next.js 13 has a neat solution: parallel routes (https://nextjs.org/docs/app/building-your-application/routin...)
by yawnxyz on 5/24/23, 11:44 AM
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.
by dvh on 5/24/23, 11:45 AM
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.
by sureglymop on 5/24/23, 11:48 AM
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.
by nfRfqX5n on 5/24/23, 12:42 PM
I've seen tons of feedback directly from customers which indicate the opposite, losing context is super annoying
by ThatMedicIsASpy on 5/24/23, 12:05 PM
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.
by spaceman_2020 on 5/24/23, 12:04 PM
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.
by tobr on 5/24/23, 11:38 AM
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.
by mrpelz on 5/24/23, 1:28 PM
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
by bob1029 on 5/24/23, 1:53 PM
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.
by EduardoBautista on 5/24/23, 11:45 AM
> 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.
by Gabrys1 on 5/24/23, 11:48 AM
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?
by dadalorian on 5/24/23, 12:08 PM
Ironic that the popover API was just announced 2 days ago. https://developer.chrome.com/en/blog/introducing-popover-api...
by 000ooo000 on 5/24/23, 12:12 PM
youdontneedadomainforyouronepagepedantry.com
by NavyG on 5/24/23, 11:47 AM
> 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
by jrochkind1 on 5/24/23, 1:33 PM
"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.
by KevinChen6 on 5/24/23, 2:04 PM
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.
by marcofiset on 5/24/23, 12:21 PM
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.
by motoboi on 5/24/23, 12:52 PM
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.
by js8 on 5/24/23, 11:42 AM
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.
by dncornholio on 5/24/23, 1:17 PM
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.
by nologic01 on 5/24/23, 11:33 AM
The Treachery of Modals: Ceci n'est pas une page
by nonethewiser on 5/24/23, 1:42 PM
> 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?
by zethus on 5/24/23, 4:05 PM
A part of me wishes the "Bonus: RESTful UI" section at the bottom opened a "Coming soon" modal
by usrbinbash on 5/24/23, 2:20 PM
> 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.
by vaylian on 5/24/23, 12:01 PM
Modals disempower the user. That's why they are so popular with mandatory Cookie selection dialogs.
by hk1337 on 5/24/23, 2:27 PM
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.
by mbostleman on 5/24/23, 12:57 PM
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.
by andix on 5/24/23, 1:52 PM
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.
by derekzhouzhen on 5/24/23, 1:47 PM
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.
by asynchronous on 5/24/23, 1:44 PM
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.
by nicbou on 5/24/23, 12:24 PM
What are good alternatives? I like <details> and collapsible panels.
by davedx on 5/24/23, 1:37 PM
> 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!
by extasia on 5/24/23, 11:25 AM
Love your username, OP.
by gloryless on 5/24/23, 3:37 PM
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
by throwawaaarrgh on 5/24/23, 1:45 PM
ThisIsAShittyClickbaitArticleWhyIsItAnEntireWebsite.dev
by j3th9n on 5/24/23, 12:55 PM
I want it to close when I click outside of the window.
by amelius on 5/24/23, 11:35 AM
Yes. Why does nobody use alert() anymore?
by 1337shadow on 5/24/23, 1:41 PM
When external pages can show in modals or separately because you are using Unpoly.js then it's perfect
by jcmontx on 5/24/23, 11:51 AM
Bootcamp React developers discover MPAs
by revskill on 5/24/23, 12:50 PM
Written by a confusing developer who love to reinvent the wheel all the time.
by ulrischa on 5/24/23, 5:29 PM
Plus: Not accessible
by b1nj0y on 5/25/23, 6:32 AM
A stupid post