13 ms·
> 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 ar
by 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 agoThis 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 agoYour 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 agoYou 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[flagged]
- radiorental 3y agoYou can't generalise like this. We use modals, drawers and new tabs where appropriate. There's two words you must learn when talking about UI design - "It Depends". The one general rule I will state that guides towards using a modal is if the user needs to stay within the context of the originating page and they must return to that page as part of the workflow that launched the modal. But there's also edge cases to this. source: UXer with 25 years experience in both desktop and webapp.
- adamlett 3y agoPeople who say "it depends", without also explaining what it depends on, are not worth listening to. Someone who advocates for a silver bullet solution to a problem is more helpful than someone who won't make any recommendation at all, because "it all depends".
- MattPalmer1086 3y agoYou can say it depends, if the entire point you are making is just that it depends! It's unrealistic to outline all the different thought processes that would go into such a decisionn in a short comment on HN. And you could not hope to cover all the different things it depends on.
- waboremo 3y agoNeither of these statements are true (and the latter can be far more devastating as those types love to rush through changes without careful consideration), but you're free to repeat them as many times as you'd like in hopes they become true.
- marcosdumay 3y ago> You can't generalise like this. I have never met that other kind of user. Even when it's a small detail completely embedded on the context of the page, people get annoyed by modals. AFAIK, that happens on the desktop too (with the single exception of things like app settings). I do believe in pushing a more usable design despite users not liking it a few times. But those times have to be few, and thus, you have to get a lot of extra usability out of it. Modal details isn't such an important use case, so I do recommend to avoid unless you gather your own evidence (and any UI recommendation can be ignored if you gather your own evidence), even if they are better. I do recommend a default to avoid almost all of the use-cases people are posting for modals: - click to enlarge is much better done inline; - alerts are that one thing where modals became a caricature, modal alerts are absolutely shit; - confirmation prompts should be avoided as much as you can (yeah, if you can't, make a modal); - the 2 minutes rule from the OP, nope, if it can't be done inline, you can put it in another page.
- francasso 3y agoYMMV. If you are building a single page app for expert users in a domain, and editing an entity changes the visual context by going to a different page, that doesn't go down well in my experience. We tried it once, with multiple iterations, and in the end had to roll it back to modals because the complaints were endless.
- deleted 3y ago[deleted]
- withinboredom 3y agoI freakin love it when it goes to a different page with its own URL. Stakeholders/customers can just create a spreadsheet directly to the relevant link if they have a lot of things they are trying to track outside the software (think inventory management stuff).
- jevgeni 3y agoThey ARE pop-ups mostly. Just ones that are harder to block as compared to the 1990s pop-ups.
- kmoser 3y agoYep: devs call them "modals" while users call them "pop-ups" but they're the same thing. Now, native browser modals (think Javascript's alert()) don't use the same underlying technology as HTML/CSS modals (think Bootstrap's modal component), but at the end of the day they're both modals/pop-ups.
- Semaphor 3y ago> You must use "telemetry" instead of actually talking to your users. I mean, there are several people in this thread who like modals as users. I’m another one of those. I find modals very useful, as long as you don’t do them in a crappy way. You shouldn’t insult people just because your experience was different.
- nicbou 3y agoI'd love to hear some unexpected insights you got from asking users.
- reaperducer 3y agoI'd love to hear some unexpected insights you got from asking users. There are too many to list here. Things that the sort of people who read HN would never imagine. One is that a surprising number of users don't know to press the "Search" button after they enter text into a search field. They will just sit there for a bit and when nothing happens, they assume it's broken. I haven't followed up on this yet, but I suspect it's because people have gotten so used to autocomplete.
- arghwhat 3y agoSure, you can complement every modal view with a non-modal version, but now you have 2x the views and users that are ambivalent about the duplication at best, confused and frustrated at worst. Just make a good non-modal view, with whatever transition is needed for continuity to/from the parent view.
- keyle 3y agoI think unfortunately in the last decade modal windows have been abused. I however agree with you, and I don't like the website simply dismissing the idea because it's been over-used and abused all over the place. Modals have a place in UX.
- rozenmd 3y agoFunnily enough, I never complained about how Jira solves this (it's clear that linking to the modal will work, because the URL updates)
- korijn 3y agoSo what about people with screen readers? They don't (middle) click or type at all. Does your UX account for them too? If so: great. Usually, it's overlooked. I think that's the point of this article. Standard browser controls are all 100% accessible by default.
- aendruk 3y agoClearly “middle-click” was just an example of how to open a link in new tab. Screen readers don’t have a way to do that?
- pqb 3y agoNo, at least not in VoiceOver, which I use. In my experience, screen readers/assistants don't mimic the left/middle/right click of the mouse [0]. You often get two options: left click and double click [1]. There is also a right-click menu (control space), but unless it is based on a system-native UI, it is likely to be unusable for SR. [0]: It is even easier to not use a mouse, when you are using an assistant. With a keyboard and VO you can resize, drag and drop and do many more activities. [1]: https://support.apple.com/en-us/guide/voiceover/mchlp2746/10/mac/13.0 https://support.apple.com/en-us/guide/voiceover/mchlp2746/10...
- aendruk 3y agoI don’t have a Mac to try it but a quick web search suggests Command+Return.
- pqb 3y agoUh, that's interesting, but it does not work for me :( AFAIK, VO+Command+Return can be used to select multiple things, not to click. For example, in the file viewer (Finder.app, similar to Nautilus/explorer.exe), it is similar to pressing Control (win/linux) and the left mouse button when the cursor is over a file to add it to the selection. Edit: To open a page in a new tab in a Firefox with stock VoiceOver, I need to press VO+Shift+M to open context menu (aka right-click menu), and then select an option from the list (by greping, using arrows etc.).
- jevgeni 3y agoI am one of those people whose user experience will drastically improve if modal windows are accepted for what they are - an anti-pattern at best and a dark pattern most of the time. I as a user make the decisions if I want a separate window or not, not the application developer. As a principle, I don't read any website that has a modal window, especially a modal "subscribe to our newsletter".
- ebiester 3y agoWrong use case. Think more like a web application where a modal comes up for more details and to edit details instead of going to a separate page and URL.
- layer8 3y agoYou are describing the cases I hate, because you then can't (easily) open those views in a separate window while keeping the current view for reference. It's similarly annoying as paging controls that don't support "open in new window" and/or don't work with the browser history.
- jen20 3y agoIt’s the same use case. The browser is an agent of the user, not of the website developer.
- smeagull 3y agoYou mean like a web application where the modal edit window blocks the information on the original page that I would want to refer to, so I have to close the window, copy it in to a text editor, and bring back the modal window? Sounds wonderful.
- jevgeni 3y agoIt's not the wrong use case. I need you guys developing apps to listen: - I *want* more details on a separate, linkable URL. - I *want* it to open in either the same window, or a separate window if I ctrl+click it. "Subscribe to newsletter" use case is just the worst use case.
- rayiner 3y agoHow about the fact that modal windows suck? There’s so many web apps that throw up a modal window—for e.g. editing an item—that prevent you from seeing anything else in the app or editing two things at once (because nobody would ever need that).
- myth2018 3y ago> This will worsen the UX more often than not. Guaranteed. Experience shows that this is not the case, provided you keep load times as lowest as possible. In business apps, this has the additional advantage of allowing users to share information among themselves by simply sharing URLs.
- nicoburns 3y agoYou can make modals linkable too.
- myth2018 3y agoYou can. But then there are the issues. The article even reports some of them. On large applications, this can be become a nightmare to maintain.
- sb8244 3y agoWhat issues? It really seems like subjective experiences being pushed as best practice. It's absolutely possible to build maintainable, accessible, linkable, fast modals. I have no clue why someone would say those things are impossible or impossibly difficult to achieve.
- myth2018 3y ago> What issues? Article mentions some. And please notice that we are not advocating for the complete elimination of modals; rather, to avoid their use in specific situations.
- dimmke 3y agoI have been developing a single page application for several months in SvelteKit, which emphasizes server side rendering and progressive enhancement. I spent a lot of time making things work without JS when it would have been easier not to. Modals were the spot where I threw in the towel on perfect progressive enhancement. Like yes, I could make this work without JavaScript. But I'm not willing to take the likely weeks designing and building a robust solution for it which would definitely have to involve routing. I like OP's post, because this is a decision I am wrestling with. Right now I only use modals for things like confirmation windows or showing a larger version of a photo when you click a thumbnail. Kind of like the use cases they outline. Ephemeral. But I am about to start implementing a payment flow that is more complex than just "enter your card number and hit enter", and as nice as I think it would be to have it in a modal, but having it as its own page/flow is so much easier in so many different ways, I think this tipped me over the edge.
- usrbinbash 3y ago> This will worsen the UX more often than not. Guaranteed. The article states very clearly the use cases for which modals make sense: 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 As soon as something is a resource, that is, an article to read, a picture to watch, a diagram to open, a sound to play, in short anything for which it makes sense that it should be reachable via an URI, a modal is the wrong choice.
- smeagull 3y agoAnd it's wrong about all of them. Alerts don't need to stop the world. Confirmation dialogs block examining the things that you want to confirm. And forms for creating anything do not need to block access to the rest of the page.
- SoftTalker 3y agoI tend to agree. Modals are just contextually different things and even if some/most of your users understand that it's extra cognative load that may not be required for what the app or web page is doing. Such questions as "if I close this modal is that different from using the cancel button?" should not even need to be dealt with by the user.
- usrbinbash 3y agoI agree, and I also don't think that modals should be used for these things. I merely also agree with the article that these are use cases when a modal "can" be used. It still isn't a good solution, but at least it doesn't actively hurt my ability to access a resource.
- wizofaus 3y agoExcept I've seen countless times that users ignore stuff if they can, including important warnings etc. Ideally confirmations should be kept to a minimum anyway (and instead ensure all actions are reversible), but in cases that's not possible I'd rather have a confirmation show in a modal where I can at least see the page/context it's referring to (and it goes without saying, all modals should be draggable, even for touchscreen devices) than a separate page entirely. And if an action can't be performed then I'd much rather see the reason why in a modal window that grabs my attention and forces me to acknowledge it than a button that appears to do nothing but cause some easy-to-miss message show up elsewhere on the page.
- dataviz1000 3y agoIf you are working with an single page app, you can open a modal window and change the href without navigation by calling `history.pushstate`. ``` history.pushState({}, "", "/new-url"); ``` Moreover, modals serve one very important UI purpose in that they keep the user's mind in a context.
- smeagull 3y agoEvery Modal window has me close it so I can access and refer to content on the page that it's blocking. There's one kind of modality needed for computers, and it's the power switch.
- _greim_ 3y agoInclined to disagree. I once worked on a product that went all-in on modals for detail-views, and we ran into all of the problems mentioned in the article. It produced a constant stream of tickets, and at the end of the day the UX was indeed terrible.
- ericyd 3y agoRespectfully, I think your first sentence could use editing. It isn't clear if you're agreeing with the author's statement (i.e. Don't use modals because it will result in worse UX), or contradicting the statement (i.e. Don't use a new page because it will result in worse UX)
- andix 3y agoModals can be a life saver, if you do server side rendered pages, because navigating back is probably slower than opening/closing a popover via Javascript. You may also lose some state on the previous view on navigating back, you may end up at another scrolling position (I know this can be prevented). I prefer master-detail views. Like an Email client, where you select a message in a list and then see the body of the email. For smartphone sized screens this should switch to a detail page with a back button. Like the Mail app on iPhone/iPad. Master-detail can be tough on server side rendered pages though. And you really need a good page structure, because you show a lot of data on one page and it can look cluttered quickly.
- account42 3y agoNavigating back used to be instant before pages became so bloated that browsers had to evict them from ram so soon.
- ordu 3y ago> 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. It is what is wrong with web-designers. They throw away existing browser features, like a scrollbar, and develop their own half-baked replacements, which work differently, they are probably incomplete realisation, and then I'm scratching my head trying to imagine a reason for all this work done by a developer: why to spend additional development time to make my life worse? It could be a UX improvement, if it was not a modal window but a modeless one: it can help to compare details of different products by placing their windows side-by-side. Or I can right-click on a link and open it in a new window. But a modal window is a nightmare: I can move tabs into a separate browser window easily and to place them side-by-side. It is pain to do it with modal windows. One needs to clone tab and then to open modals.