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.
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.
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.
So much fragile tedious technological hackery and pointless showboating of rube goldberg machination to implement something that's just a user hostile terrible idea in the first place.
There are times when a modal input is genuinely useful or indeed necessary, not just programmers being lazy and taking the easy-for-us-but-shit-for-users option. A number of these are already mentioned elsewhere in this thread and the original article, so I'll not repeat them.
> Just don't.
Except where it actually makes sense to. Or you are trying to improve the UX of something that already works that way and you don't have time/budget/permission to reengineer more thoroughly.
Where it makes sense to the “technological hackery” isn't pointless: where the UX pain can't be easily removed the visual hackery at least reduces it to a minimum. Similarly for when you are stuck with the overall design (at least for now) and are trying to minimise the suck for the user.
I'll not disagree with going fancy and adding blur filters & whatnot is showboating, I'm firmly in the function over fancy tricks camp too, but many people want things to look pretty as well as be functional¹. And once you are already doing the functional, the few small tweaks to make it prettier are hardly hard work so don't waste enough time to deserve the level of incredulity you are expressing, so while I might not bother I'd not judge others for doing so as long as the fancy doesn't get in the way of the function.
--
[1] heck, some will judge your work on the visuals before even thinking about the functional matters
[2] or take more time than refactoring the UI to remove the need for the modal, if that is possible/practical
There was never a more obnoxious showboaty in-your-face modal dialog than the OPEN LOOK popup notice (as implemented by XView and other toolkits that I won't mention out of shame), with its pointy triangular tail, that would actually violently "warp" your mouse pointer location back and forth between the originating button and the "OK" button:
The one thing OPEN LOOK did get right were the pushpins. It annoys me to see so many "modern" half-assed semi-skeuomorphic pushpins that instead of actually pushing in just remain in the "not pushed in" state, but highlight a framing box instead. It's in the name, people. It's supposed to pin the window on the screen, and how can it do that it it's just highlighted instead of actually pushing into the hole? Pushpins REALLY should safely and satisfyingly push in, not just sit there sharply pointing out at you menacingly like that. It's not rocket science so I don't understand why so many pushpins don't push in. Was there a user interface software patent on pushpins that push in?
Which I thought made sense but I have missed an ok modal before myself let alone seen others as another commenter pointed out. In native apps they also open off screen which is about as broken as you can get.
So, I may go even further than the article and say there are even fewer cases where it is the best way to do a job.
> 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.
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."
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.
You 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.
People 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".
You 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.
Neither 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.
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.
YMMV. 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.
I 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).
Yep: 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.
> 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.
I'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.
Sure, 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.
So 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.
No, 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.
Uh, 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.).
VoiceOver is most often, and best, paired with Safari.
By default, Command-Return, no VO key, opens a focused link in a new tab behind the current tab. It's not a VoiceOver-specific keyboard command. It also works in Firefox and Chrome.
However, by default, Safari does not focus links when pressing the Tab key, you need to go to Settings > Advanced and check "Press Tab to highlight each item on a webpage" first.
Even if a screen reader does, someone using a touch screen usually doesn't. If you step out of your bubble for a moment you'll notice that quite a lot of non-technical people no longer have computers, they do everything on a mobile device of some sort which typically does not have a mouse or keyboard.
I'm quite confident that you wouldn't have to interview many people to discover that even though it is not beyond people that it is unknown to many.
I know several non-technical people who find the distinction between window and tab difficult to manage for instance. As well as people who have had Android mobiles for years and still don't understand those three little buttons at the bottom of the screen: back, home, 'task' list.
d: Represent resources only as standard hypertext documents.
h: Progressively enhance with nonstandard features. The traditional
affordances of hypertext will remain available—for example,
middle clicking to branch browser history.
k: But screen readers can’t middle click.
a: Branching is afforded by *some* interface though, right?
w: Not on touch screens.
a: Not even by using the touch interface?
w: Nope. You can’t expect everyone to know how to use it.
So we’ve established that many people are unable to effectively navigate the web using the native features of their web browser. It’s not clear to me how that informs the surrounding debate. Are browsers’ navigation features inadequate? In context that sounds like an argument in favor of websites implementing their own navigation.
Personally I’d prefer us to prioritize building a web of addressable resources rather than applications, and to the extent that our user agents aren’t meeting our needs, improve them rather than work around them.
> to the extent that our user agents aren’t meeting our needs, improve them rather than work around them.
Most of us are in no position to improve our user agents only large organizations like Google or Mozilla can do that. In fact calling them user agents is extremely misleading in most cases.
If they were genuinely user agents they would obey the user not the server. They would assist the user to a much greater degree than they do now; for instance there is no native way of saving the rendered page in either Firefox or Chrome so sharing a page is exceptionally difficult if the URL points at a resource that require logging in and also risks that the resource changes before the recipient can read it. One has to install an add on to do that and hope that the author doesn't get bored of maintaining it or piss off the Chrome Store or whatever it is called.
Accessibility support is a matter of priorities for a given project.
If 99.99% of your target audience is not using screen readers, then you need to decide if worsening their experience to accommodate the other 0.01% aligns with your project plans and goals.
In some cases it will, in some it won't. It depends.
My employer has more than that, and is not subject to it. I don't know exactly why, but I think has something to do with availability to public? Our users are employees of our customers.
First, in the US accessibility support is the law. While it is far from well* enforced, your simple formulation of “priorities” obscures the fact that the team is prioritizing convenience vs law. Yes we all do this when deciding, say, how fast to drive. But we know when we are speeding.
Second: in physical space: ramps are required to be implemented in a way that supports wheelchair use. Yet they create alternative affordances: I have appreciated them when when I have broken a limb, for example, even though they weren’t “intended” for that. They are clearly mostly used by delivery people; not only does it make deliveries easier, but reduces incidents of injuries, strains etc.
The same applies to web sites: cleaner affordances allow people to use the page in ways not imagined by the designer.
* By imperfectly I don’t mean “not hyper vigilantly”, I mean that it is often observed in the breach; sometimes it can have negative effects (consider the Berkeley videos case), etc. But that is much better than no attempt at all.
Not your main point, but in the Berkeley videos case I blame, well, Berkeley. They could have taken the videos offline temporarily, worked on transcribing them, and brought them back gradually (they have the resources or, if they’re too cheap, could have resorted to crowdsourcing). Taking that wealth of knowledge offline so abruptly, and with no plan to ever bring it back, is really a disgrace. The videos live on thanks to Archive Team, but they’re not as easy to discover.
> First, in the US accessibility support is the law
Only for governments or businesses that are open to the public. I've rarely worked on those type of websites. But plenty of B2B stuff. There's a ton of it.
I know 99.99% is just an example, but that's a pretty high estimate. I'm seeing estimates for vision impairment at 2% and color blindness at 4% [1] of the US population.
I'm also reminded that people use screen readers or other assistive tech for non-disability reasons. Like increasing font size when tired or when using a website in a foreign language. Plus, building assessible websites may be required by law, such as ADA requirements in the US.
> Accessibility support is a matter of priorities for a given project.
Not any more. In the US this hasn't been the case for years since 2019 [1], and in Europe a similar requirement will take power in 2025 at the latest [2].
There is no choice any more if you cater to either markets: either you're compliant or you can and will get fined to oblivion.
That first link doesn't say what you claim it does.
SCOTUS rejected hearing the case and has let the 9th circuit decision stand for now. That means the ruling ONLY applies in areas of the US that fall under the 9th circuit. Further, if SCOTUS chooses to hear the case in the future, they may well overturn the 9th circuit decision.
As they point out in that article, this decision would instantly make hundreds of thousands of business non-compliant and open them up to being destroyed by accessibility lawsuits.
A megacorp will just do the work and write off the expenses.
Small businesses are different. Faced with tens of thousands in expenses, they have two options. The first is that they eliminate their website entirely. This hurts them and almost all of their customers (including disabled people who might have relied on the partially accessible features). The second is to lay off employees to pay for the work. Neither option is very good.
> That means the ruling ONLY applies in areas of the US that fall under the 9th circuit.
Ah, thanks. I'm German, I thought federal court orders were binding for the whole country.
> Small businesses are different.
Actually small businesses are exempt. The EU EEA has a threshold of 10 employees/2 million euros balance, and the US ADA - at least from a quick Google - of 15 employees [1]. If you're hitting either of these thresholds, you're large enough to afford a once-off expense and hell, you should have a couple tens of thousands of dollars in reserve anyway simply because your employees rely on you being able to make payroll even if disaster strikes - even at 10 employees and 3000 dollars per employee in total cost, that's 30k in payroll a month total so you should have 60k in reserve anyway.
For those who don't, well, please don't operate in a way that externalizes costs and risks onto others - no matter if it's disabled people, your employees or your customers.
> Faced with tens of thousands in expenses, they have two options.
A lot of small businesses don't do their own website, they use social media or SaaS providers - Wix, Wordpress, Jimdo, or (for restaurants) Just Eat and their competitors. For them, the SaaS provider does the heavy lifting, and besides: these sites usually don't have much content anyway.
Boo! That attitude hurts people, and is against the law for good reasons.
And even if you have no empathy so you don't give a shit about anything unless it affects you directly (in which case UI design isn't for you), then consider that unless you die young or have supernaturally perfect health, you're going to need accessibility features yourself some day, so your lazy anti-accessibility attitude is going to come back and bite you in the ass.
And you're dead wrong that accessibility necessarily worsens the experience for people without disabilities. It's useful for everyone.
Please leave the user interface design to other better educated more compassionate people, and stick to the back-end yourself.
That's a shallow knee-jerk interpretation of what I was actually referring to.
Put my remarks in the context of a startup that has a limited runway and needs to choose between working on something that would appeal, entice and attract the majority of their target user base and trying to accommodate the needs of the fraction of the same. You can "boo" all you want, but their choice will be obvious, as it should be perfectly understandable, even for people from the second group.
> Please leave the user interface design to other better educated more compassionate people, and stick to the back-end yourself.
Ah, a gratuitous personal attack, the best way to strengthen any argument.
Pulling totally bogus statistics out of your ass like "99.99% of your target audience is not using screen readers" is not the best foundation for your dubious argument for using modal dialogs and against supporting accessibility. And your claim that accessibility "worsen[s] their [non-disabled users] experience" is flat out wrong, so it's hard to take you seriously.
And anyway, a lot more people would regularly and happily use screen readers if it weren't for all those badly and lazily designed web sites and user interfaces that use modal dialogs and don't bother supporting accessibility, which make them much less useful and accessible for everyone.
Speaking of context: Even if screen readers or people with disabilities did not exist, there are still many important legitimate reasons not to use modal dialogs, and still many perfectly reasonable alternatives, so your bogus statistical argument for using modal dialogs is still dubious and doesn't address any of those other issues.
>Here are the numbers regarding how many people have disabilities that make accessibility features necessary when surfing the internet.
>4.9% of U.S. adults have a vision disability with blindness or serious difficulty seeing even when wearing glasses, requiring screen readers.
>5.7% of U.S. adults are deaf or have serious difficulty hearing.
>10.8% of people with a disability have a cognition disability with serious difficulty concentrating, remembering, or making decisions.
>There are an estimated 300 million people in the world with color vision deficiency which requires color-adjusting tools on sites.
>About 16% of people who use screen readers have multiple disabilities.
>Roughly a quarter of Americans with disabilities (26%) say they have high-speed internet at home, a smartphone, a desktop or laptop computer, and a tablet compared with 44% of those who report not having a disability.
>18% of US adults report that they have a disability, according to this survey, which asked respondents if any “disability, handicap, or chronic disease keeps you from participating fully in work, school, housework, or other activities.”
>Americans with disabilities are three times as likely as those without a disability to say they never go online (15% vs. 5%.)
>By 2050 nearly 2.5 billion people are projected to have some degree of hearing loss and at least 700 million will require hearing rehabilitation.
>By 2060 the number of people 65 or older is expected to double to 98 million.
Another point is that screen readers aren't only useful for blind people. Here's a demo of a screen reader that I implemented for reading the long but amusing catalog object descriptions in The Sims ("Simplifier" demo starts at 3:15), that's useful for kids who aren't good at reading yet (but want to learn while playing a game), and anyone who is too impatient to read all the tiny text on the screen:
Demo of The Sims Transmogrifier, RugOMatic, ShowNTell, Simplifier and Slice City:
> Pulling totally bogus statistics out of your ass like "99.99% of your target audience
Please make some effort when refuting the arguments of others. See "target audience" in the part that you quoted? That's the keyword.
If one's making an augmented reality app that assists car mechanics in repairs, what would you say be the percentage of screen-reader wielding people there?
> And your claim that accessibility "worsen[s] their [non-disabled users] experience" is flat out wrong
For one, you are taking it out of context. For two, you keep repeating something as if it would make it true.
Here's a little exercise - consider what it would take to make https://finviz.com/bubbles.ashx page accessible. Then, consider what the target audience here is and ponder the choice of working on things that would benefit said audience (i.e. improving their experience) and refactoring the page to be compatible with screen readers. That's what I was referring to in the original comment. It's all in the context, it depends.
Speaking about empathy, might want to use some to get his point. He isn't talking about himself. He is talking about a typical software business making business decisions.
If adding support for accessibility delays their product delivery, or raises their costs, it's another tradeoff that might even kill their product. And then it wont be a case of the software not being accessible to those needing those features, but it not being accessible to anybody.
Sure, where the law mandates it, they can always do a half-ass job to be, in name, compliant. But full (or proper) accessibility will be judged in the end like any other feature decision.
You might consider those features essential, but you'd be surprised how many business features get cut to get something out, even more so for an MVP.
If you think those designing most websites and apps people use are made by "more compassionate people" who'd jump on such features out of ethical concerns, you'd be quite off.
Heck, this very website (HN) has a quite bad accessibility track record even considering the average website. Among other things: image elements do not have [alt] attributes, form elements do not have associated labels, links do not have a discernible name.
And this is from a major VC company with tons of resources, and a place where thousands upon thousands of devs frequent.
So, while everybody can get their "morally superior and empathetic" rocks off judging the parent, the reality is more like what's described above. It isn't bad if somebody points to the reality - or to the hypocrisy, if we're to see it ethically.
This is, to be blunt, narrow-sighted; most accessibility support is rooted in best practices for every user. Screen readers are only one use case, other things that people don't even consciously think about and take for granted when they use a webpage or app are things like zooming in, focus/reader modes, light/dark modes, performance, print views, copy/pasting content, SEO / searchability, bookmarkability (e.g. headings & anchors in webpages, also used by screen reader users to quickly navigate a page), etc.
99.99% of accessibility things are covered if you just follow normal, established software development practices. Unfortunately, a lot of software developers overcomplicate things, for example by adding modal dialogs to websites. Modals are common and established design patterns in desktop apps, but not so in web and mobile apps. Applying one environment's UX patterns to another is asking for trouble.
>most accessibility support is rooted in best practices for every user.
This isn't quite true, when you get into things like using aria attributes. I definitely wouldn't put it at 99.99%. And I think a lot of vendors of accessibility software get to skate where others would have their feet held to the fire. They could be doing more to make their software easier to use and for developers to make it accessible.
I used to work as a contractor for the CDC, so I have experience in web development that is held to a higher accessibility standard (we had an actual real person who would verify our work and certify that it was accessible.)
And being able to navigate a site with a keyboard, or announce when sections change. That stuff isn't automatic. It might be baked into whatever framework you're using, but those frameworks have bugs too.
> Accessibility support is a matter of priorities for a given project.
It is painful that some managers, architects or developers might think this way. Accessibility is not just for disabled people, such as the blind or those who have lost a limb. In the kitchen, for example, it is great to have push to open drawers (e.g. based on IKEA's EXCEPTIONELL [0]). If your hands are dirty, you can still open the kitchen drawer without getting anything else dirty. And this is just one example of accessibility.
Personally, I see screen readers as an additional tool (like Copilot or ChatGPT) to be used on a daily basis by keyboard users.
Screen readers can also help you, even if you are sighted. For example, with a ShortCat.app [1] I have a system-wide ace jump [2] with a command list. I don't have to use the mouse to move the cursor - I have a keyboard for that. But in applications that are not compatible with screen readers, you can only choose "close", "minimise", "maximise" buttons, and the first option - close - is the best for such an application (e.g. Sublime Text).
In other cases, SR/SA will read the text for you. If you are too tired to read, or your hands are occupied with a sandwich or utensils, you can use SR to read an article or paragraph for you.
Accessibility is hugely important and every single html project people work on should at the very absolute least strive to satisfy the chrome light houses accessibility suggestions. It is _really_ not difficult to attain a basic level of accessibility and with a small effort by UX and product people the entire application could be easily usable by anyone able to currently use a computer.
I worked in a consulting company, which estimated accessability requirements to increase web development costs by 10%. It's easy to imagine some big successfull company paying it up like it's peanuts, but it's another hurdle for companies living on the edge. I was in another company that had done a lot of work on accessability. But in the end, they ran out of money and released their software extremely buggy, which contributed to their product failure and bankruptcy.
Non-bugginess is also accessability, but I don't see a law saying that you can't release unfinished software. So how would accessability be anything more than all the others unimplemented issues stuck in the backlog?
There should be zero legal requirement to do so - I just meant to say there is a lot of low hanging accessibility fruit that doesn't require a large amount of time and money to implement that will give everyone using a computer a better experience.
Adding keyboard control to an app makes it better for blind users and power users. Adding alt text to images makes it better for blind users and SEO. Adding ARIA tags makes a page better for blind users and for testing with things like testing-library.
I haven't found a single case where improving accessibility doesn't also result in a meaningful improvement for some set of users who don't need accessible features. There is absolutely no good reason not to make things accessible. Heck, I'd make an app accessible even if I had irrefutable proof that it had no users who need it to be accessible.
This was a common argument in the early 2000s, until, you know, someone looked at real world data and figured that something like 10-30% of a website’s audience usually benefits from accessibility features. Accessibility is not only about supporting complete blindness or other stereotypical disabilities.
However, consider how much do you worsen the experience of the majority, and how much do you improve it for the minority? I think that should factor into this decision.
I think the article is mostly trying to make an effort to inform people of the options available to them, so that when you are creating estimates of the work required to support accessibility requirements, you're not overestimating out of sheer ignorance.
Are you confusing screen readers with voice control software? Screen readers are most often used by people with vision impairments; with desktop operating systems, they use a keyboard not just for typing in form fields but to navigate and control all the websites and software on their device instead of a mouse or other device that operates a cursor.
Voice control software is used most often by people with limited use of their hands, verbal commands replace keyboard and cursor control inputs.
> Standard browser controls are all 100% accessible by default.
Unfortunately, this is not entirely true. For instance, `select` elements and their options don't reflow in most browsers. It is true that the native elements are much more accessible than most alternatives developers create.
I 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".
Wrong 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.
You 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.
You 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?
Us "developing apps" aren't the ones designing modals - there are teams doing that instead and we implement what they suggest. It turns out that when they ask users of the software I build, at least, that this isn't a common complaint.
The problem that designers are often trying to solve is that there is not enough information that there is a good way to put it on its own page - it's too small for its own page but too large for the table that we'd rather just add another column to.
We have an export button so you can get all the details in excel or LibreOffice or your tool of choice, though. And in a better world, we'd be writing proper desktop apps instead of web applications so that we aren't making stupid compromises like this, but here we are.
How 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).
I 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.
> 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.
I 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.
I 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.
Except 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.
> users ignore stuff if they can, including important warnings etc.
They sure do. Especially modal dialogs. Everybody has been trained to hit okay automatically, because they're so prevalent on things that don't matter. Good apps track history and have undo.
Apps that have changes that matter use more drastic things than modal dialogs. Just try deleting things on AWS.
> 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.
These feel incredibly unrelated to me. Why does that matter at all for the display choice? A modal is getting used because it's a view into another section of the application that doesn't lose the current location of the user.
Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. It's just not important to most people what the string of characters is.
So...
Anywhere you've got multiple steps to complete, or an adjacent resource that might be related and viewed/edited in the context of the parent resource.
Or a form is being filled in and a user wants to enable extras, which requires filling in a different form, etc...
The modal is about not losing the current place for the user. Because most current users don't use multiple tabs/windows for the same product, and they don't pay any attention to the urls.
"Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice.
> Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. It's just not important to most people what the string of characters is.
This is not correct. Normal users have learned that if they copy that URL thingie, and send it to someone else, that someone else will see the same thing they see now.
I don't know how many times I've received a link from someone saying "lol look at this hilarious dog" and ended up on some useless overview page completely devoid of hilarious dogs. Because some fucking designer decided to do exactly what TFA is complaining about.
Fair, but there’s no reason a URL can’t resolve to a landing page and already open modal state populated with the content the other person shared to you. Deeplinking / permalinking works just as well with modals as it does with anchor named content blocks below the fold.
So, something can intrinsically work by default, or it can possibly work only when and if you go out of your way to make it work. Two totally equal choices!
> Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs.
Tell that to my non-techy spouse and her +1400 bookmarks. You know what her most recent rant was about? That she cannot bookmark certain timetables at a booking platform she uses. Why? Because guess what: The timetable shows in a modal.
> The modal is about not losing the current place for the user.
Resources opening in tabs also don't lose the place of the user. But you know what modals do usually lose the user? The ability to interact with anything but the model while it's open. A usual gem is a form which opens a modal, where I would then really really like to copypaste some info I already entered in another part of the form, but can't, because the effing modal is in the way. So I have to close it, and that usually wipes all the info in it.
> "Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice.
If a web design can cause the user to get lost in the first place, then the problem isn't that there is no modal, and adding one will likely not fix it.
Once again, these sound like issues with poorly done modals.
I've made multiple websites where URLs are routed to modals because the app made most sense as pages on top of an underlying state. GET /things/42/edit loads thing#42 in the background and opens the edit modal prefilled with thing#42's info.
A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task.
Preserving form data during navigation is something you have to consider for any form, even forms on the same page or separate pages where you don't want the form to clear when the user navigates away. One key design principle of modals is to make them mentally cheap to open/close/reopen, and modal state preservation is usually a part of that.
> A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task.
That cherry on top can be just as easily implemented by opening the /login in a new tab. Auth gets set, there, user is logged in even in the old tab, and doesn't lose his position in the page either.
Added cherry on top of that: If the user decides to log into the page halfway through the application, he can still bookmark the login page.
The same is true for almost every other use case of a modal where it displays a resource.
Tabs are builtin capabilities of the browser. Even terminal browsers like w3m support tabs. Why built something else that can be built poorly, instead of using what the browser already can do?
In your example, the work in progress page traditionally never gets to know that the user logged in until the user refreshes that page. That is exactly the status quo UX that sucks.
Funny enough, a page-refresh is usually what happens, after I fill in a login form that appears in a modal.
But even if it doesn't do that: If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh?
And on the off chance that the use case actually requires that, what specific advantage does a modal confer over two input fields (Username, Password), tucked discreetly along a "Login" Button into the navbar?
Like all UX, the best solution depends on a multivariate consideration which is why you cannot dismiss modals with zero consideration.
For example, a username/password in the navbar can make a lot of sense. If it's slightly more complicated than that, like if login has multiple screens (e.g. 2fa token, maybe SSO), then a modal can make sense.
On a mobile screen, having username/password in your hamburger slide-out menu isn't automatically superior to extracting it into a modal.
> If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh
I can think of a lot of examples where this can polish the experience.
Once again, I'm brought back to the airline checkout process where you might have almost finished booking a flight but you want to get flight rewards and autofill your contact info at the last step and realize you want to log in.
Games are another example -- I've built a modal-based UI for a large casino where there's always a round-based game going on. Guests can watch it. They can login to play. Deposit, FAQ, player profiles, game history, etc. are all cheap interactions that users can view and dismiss while participating in the global game without losing their state. At any moment they can login which enhances most of the pages with additional content.
Fwiw, I'm arguing that modal should be a tool in one's UX toolbox, not something you use all the time.
> these sound like issues with poorly done modals.
There is no other kind. The whole idea of modal window is stupid. It constrains the user instead of empowering them.
Solve the server's problems some other way that doesn't impact the user.
These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead.
> One key design principle of modals is to make them mentally cheap to open/close/reopen
Modal can enhance UX. I've given examples in my post including an answer to your "Cheaper for whom?"
I don't think it's a good argument, you could also just use your own argument against you: Pages are only easy for developers but worse for users since you don't have to polish the UX in the way that a modal lets you. It's for developers that don't want to have to think about UX optimizations and defer everything to out of the box browser experiences. Which, granted, might be the best choice for everyone who doesn't want to think about UX.
But I find that to be an empty claim.
> These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead.
That is often a good choice. However, sometimes a modal makes more sense for an all-or-nothing task, or when the user is already in one of those "expando" forms, or a number of other occasions worth pondering for your app instead of dismissing modals without discretion.
Knowing when a modal does and does not make sense is part of a good intuition about UX.
In this current age, this usually means an SPA that will first load the underlying page, then the entire application bundle, start up the JS, detect the route, load the data for the modal over another request, and finally display the modal. In the multiple seconds this is happening, nothing indicates that a modal will be opened. Sounds familiar?
Problem is, this is the standard, not a particularly poor implementation. I don't even know where to find an example that shows UI feedback before the modal is loaded.
> Modal sometimes also works as a peek view of a resource.
That's what thumbnails and stubs are for.
> In fact, you can make a link open modal with left click but open in new tab with middle click. I think it is the most balanced way in my opinion.
Cool. How do I "middle click" on my phone? Left click is "open resource" by default. If a webapp doesn't have a damn good reason to overwrite the browsers default behavior, it shouldn't.
And "we thought it would make the design really pop", is not one of those reasons.
Besides, open in modal don't even mean the url won't change.
Fb, reddit both open in popup AND change the url. Copy the url to other browser would just work as intended.
> but at least this part of it is trivially easy to implement.
It was a resolved problem before that, by letting the browser do what the browser is good at, instead of implementing new UI paradigms on top of it.
> Besides, open in modal don't even mean the url won't change. Fb, reddit both open in popup AND change the url.
So I add more code, and thus more complexity to websites, in order for the browser to behave in the way it would have already behaved in the first place, had I not thrown the modal in there, and instead let it work as intended.
Modern social websites uses infinite scroll, and infinite scroll don't really work with browser's back navigation button. A direct navigation means you lost your read position completely. Hence nobody ever navigate directly.
> Modern social websites uses infinite scroll, and infinite scroll don't really work with browser's back navigation button
Yes, and the same can happen with any number of other things, like a keybind that scrolls back, or a link in the feed the user accidentially clicks.
Which is part of the reason why infinite scroll falls under the same category as modals as far as I am concerned. There is a reason why pages with lots of entries are paginated.
Depending on my use-case I strongly prefer a modal. A new tab would be highly disruptive, if I just wanted a glimpse over the content.
This is yet another instance of optimizing for something that can not be made perfect.
Let me decide what I want. Give me the option to do both without much of a hassle. If a decision needs to be made regarding what should happen on a mouse-click, one may choose a sensible default (i.e. what is the most typical use-case), while leaving the option to configure the other choice.
You can always argue that many options are a non-goal, but any sufficiently sophisticated software needs training anyway. Configuration can be a part of that.
Nothing is worse than a program in which the designer chose to make your use-case to be painful to be met.
Furthermore, a uri does not need to be bound to a view. In fact, one might prefer different ways to look at the same data.
A new tab would be highly disruptive, if I just wanted a glimpse over the content.
I know how to close a tab, be it via keyboard shortcut or mouse click. I know how to resize it. I know how to print it. When content I want to glimpse at opens in a modal, I know none of that. Even if it is well designed, different sites will have different engagement paradigms.
My current pet peeve with modals is when I try to select text with the mouse, and drag past the edge of the modal, it closes.
This is why I encouraged the choice of configuration, as can bee seen in the paragraphs below your citation. The intended message of my comment is that different people prefer different things.
Modal windows and how they interact with the user is obviously something that should be standardized, but that is a different discussion.
Inclined 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.
Respectfully, 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)
Modals 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.
> 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.
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.
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.
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.
Note, I've been using trackpads exclusively instead of mouse since 12 years now, before that, I had a mouse with extra buttons that I used a lot, including the open in new tab middle click.
Not before reading your comment I had realized I never missed those extra buttons, or at least remembering missing them.
And I realize that while my implementation takes care of modifiers to open links in new tabs on my web apps, I always overlooked middle button.
The real problem though is that the web is very broken for building apps, and that the DOM API is missing a way to negociate the url changes on default clicked link behavior instead of the current «block event and update url» mechanism.
I have reached this resolution: <a href="javascript:void(0)"> is never acceptable. If you have no reasonable value for an href, then you shouldn’t use an <a href> element, but probably a <button>.
As for <a href="#">, it’s in the same boat, with the sole exception of jumping to the top of the page.
And the only way to achieve this is by having the mouse interact with an actual link element (HTML <a>, HTML <area> or SVG <a>) with a meaningful href.
A few times I’ve encountered sites trying to be clever and detect Ctrl+click or middle-click and use window.open(), but this doesn’t behave natively: natively, middle-click or Ctrl+click probably open in a background tab, but open() opens a foreground tab, which will always be disruptive for people that use this stuff much, and sometimes infuriating.
This isn’t the only reason for having real links; there are also things like status bar text on hover, and context menu on right click or long press, which may include options like Open Link in New Private Window that cannot be emulated in any way.
If you want to intercepting link click events, you must check if the click is modified in some way like this:
Maybe this should be supported by browsers though. The main place where I hate not having modals is when filling out forms and checking for a slightly expanded explanation about what is expected to be filled into a field. What would be the best behavior for those is if a click showed something inline and middle click (or right click -> open in new tab) opened a new page with the correct tab focus behavior.
This is what can be accomplished by the is-click-modified code I listed. If the click is modified, let the event go through and the browser do whatever with it, but if it’s not modified, call event.preventDefault() to block navigation, then do what you want with it.
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.
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!
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.
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.
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.
I reached the same conclusion: modals are excellent at helping people quickly dive into multiple items on the list while keeping their main mental context in the listing view. I call it "Hummingbird mode" - zoom in, zoom out, jump around.
For example, you are running a project review meeting and want to quickly jump between tickets on the kanban board. Your main business context is the entire board (you might have filters/sorting), and you keep a mental record of where interesting tickets are placed on the screen. However, during the group discussion, you need to quickly jump into an individual ticket to reassign it or scan through comments for 5 seconds. In this case, using a modal to show ticket details is preferred to redirecting to a separate 'details' page because it does not scramble the user's context and their mental model about what's on the screen. Of course, the UI still should support cmd+click to open a full page dedicated to that ticket, but that's a 10% use-case.
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.
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.
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.
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.
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.
> 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.
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.
> 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?
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.
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"
> 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.
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.
The dialog HTML element[0] obviates the JS point but I don’t think it’s available in all browsers. I think there are still many considerations with this approach but many things also work out of the box.
They really aren't too much effort to get right, not anymore. Dialog element exists and by default handles most considerations when it comes to accessibility.
Also, you're going to have to create modals eventually, alerts are needed in most applications so you might as well create a thorough component.
Avoiding modals because of those who browse with JS disabled doesn't make much sense. Especially when they can temporarily enable on your site, as disabling JS for security reasons would mean they trust your site if they're still using it enough to reach a modal. You can still create fallbacks, but they'll be ugly considering most modals are for nested form changes or alerts.
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."
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.
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.
Counterpoint: changing a jira Issue into a Bug takes me into three intermediate pages of changing details, most of which are empty because they're overengineered for a board configuration that only the highest-caste jira priests would ever actually use. And then after the final Next button it takes me back to page that isn't where I even started.
Just pop up a modal and reload the Issue/Bug state when done.
306 comments
[ 3.1 ms ] story [ 134 ms ] threadSmall 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.
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.
Just don't.
> Just don't.
Except where it actually makes sense to. Or you are trying to improve the UX of something that already works that way and you don't have time/budget/permission to reengineer more thoroughly.
Where it makes sense to the “technological hackery” isn't pointless: where the UX pain can't be easily removed the visual hackery at least reduces it to a minimum. Similarly for when you are stuck with the overall design (at least for now) and are trying to minimise the suck for the user.
I'll not disagree with going fancy and adding blur filters & whatnot is showboating, I'm firmly in the function over fancy tricks camp too, but many people want things to look pretty as well as be functional¹. And once you are already doing the functional, the few small tweaks to make it prettier are hardly hard work so don't waste enough time to deserve the level of incredulity you are expressing, so while I might not bother I'd not judge others for doing so as long as the fancy doesn't get in the way of the function.
--
[1] heck, some will judge your work on the visuals before even thinking about the functional matters
[2] or take more time than refactoring the UI to remove the need for the modal, if that is possible/practical
There was never a more obnoxious showboaty in-your-face modal dialog than the OPEN LOOK popup notice (as implemented by XView and other toolkits that I won't mention out of shame), with its pointy triangular tail, that would actually violently "warp" your mouse pointer location back and forth between the originating button and the "OK" button:
https://www.oreilly.com/library/view/volume-7a-xview/9780937...
https://www.oreilly.com/api/v2/epubs/9780937175873/files/bg4...
https://guidebookgallery.org/articles/facetofacewithopenlook
https://guidebookgallery.org/articles/facetofacewithopenlook...
https://guidebookgallery.org/articles/facetofacewithopenlook...
Open Look modal dialogs were so disruptive they must have been inspired by the Chest Burster scene in Alien:
https://www.youtube.com/watch?v=AdBu6VAESeI
The one thing OPEN LOOK did get right were the pushpins. It annoys me to see so many "modern" half-assed semi-skeuomorphic pushpins that instead of actually pushing in just remain in the "not pushed in" state, but highlight a framing box instead. It's in the name, people. It's supposed to pin the window on the screen, and how can it do that it it's just highlighted instead of actually pushing into the hole? Pushpins REALLY should safely and satisfyingly push in, not just sit there sharply pointing out at you menacingly like that. It's not rocket science so I don't understand why so many pushpins don't push in. Was there a user interface software patent on pushpins that push in?
Which I thought made sense but I have missed an ok modal before myself let alone seen others as another commenter pointed out. In native apps they also open off screen which is about as broken as you can get.
So, I may go even further than the article and say there are even fewer cases where it is the best way to do a job.
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.
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."
I never made any blanket assumptions and never wrote "Users hate modal windows."
Reading is fundamental.
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.
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.
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.
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.
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.
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.
Just make a good non-modal view, with whatever transition is needed for continuity to/from the parent view.
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.
[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...
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.).
By default, Command-Return, no VO key, opens a focused link in a new tab behind the current tab. It's not a VoiceOver-specific keyboard command. It also works in Firefox and Chrome.
However, by default, Safari does not focus links when pressing the Tab key, you need to go to Settings > Advanced and check "Press Tab to highlight each item on a webpage" first.
I know several non-technical people who find the distinction between window and tab difficult to manage for instance. As well as people who have had Android mobiles for years and still don't understand those three little buttons at the bottom of the screen: back, home, 'task' list.
Personally I’d prefer us to prioritize building a web of addressable resources rather than applications, and to the extent that our user agents aren’t meeting our needs, improve them rather than work around them.
Most of us are in no position to improve our user agents only large organizations like Google or Mozilla can do that. In fact calling them user agents is extremely misleading in most cases.
If they were genuinely user agents they would obey the user not the server. They would assist the user to a much greater degree than they do now; for instance there is no native way of saving the rendered page in either Firefox or Chrome so sharing a page is exceptionally difficult if the URL points at a resource that require logging in and also risks that the resource changes before the recipient can read it. One has to install an add on to do that and hope that the author doesn't get bored of maintaining it or piss off the Chrome Store or whatever it is called.
If 99.99% of your target audience is not using screen readers, then you need to decide if worsening their experience to accommodate the other 0.01% aligns with your project plans and goals.
In some cases it will, in some it won't. It depends.
E.g. ADA (Americans with disabilities act) website compliance which seems to be required when the employer has more than 15 employees
Second: in physical space: ramps are required to be implemented in a way that supports wheelchair use. Yet they create alternative affordances: I have appreciated them when when I have broken a limb, for example, even though they weren’t “intended” for that. They are clearly mostly used by delivery people; not only does it make deliveries easier, but reduces incidents of injuries, strains etc.
The same applies to web sites: cleaner affordances allow people to use the page in ways not imagined by the designer.
* By imperfectly I don’t mean “not hyper vigilantly”, I mean that it is often observed in the breach; sometimes it can have negative effects (consider the Berkeley videos case), etc. But that is much better than no attempt at all.
Only for governments or businesses that are open to the public. I've rarely worked on those type of websites. But plenty of B2B stuff. There's a ton of it.
I'm also reminded that people use screen readers or other assistive tech for non-disability reasons. Like increasing font size when tired or when using a website in a foreign language. Plus, building assessible websites may be required by law, such as ADA requirements in the US.
[1] https://ux.stackexchange.com/questions/57340/percentage-of-s...
Not any more. In the US this hasn't been the case for years since 2019 [1], and in Europe a similar requirement will take power in 2025 at the latest [2].
There is no choice any more if you cater to either markets: either you're compliant or you can and will get fined to oblivion.
[1] https://www.latimes.com/politics/story/2019-10-07/blind-pers...
[2] https://en.wikipedia.org/wiki/European_Accessibility_Act
SCOTUS rejected hearing the case and has let the 9th circuit decision stand for now. That means the ruling ONLY applies in areas of the US that fall under the 9th circuit. Further, if SCOTUS chooses to hear the case in the future, they may well overturn the 9th circuit decision.
As they point out in that article, this decision would instantly make hundreds of thousands of business non-compliant and open them up to being destroyed by accessibility lawsuits.
A megacorp will just do the work and write off the expenses.
Small businesses are different. Faced with tens of thousands in expenses, they have two options. The first is that they eliminate their website entirely. This hurts them and almost all of their customers (including disabled people who might have relied on the partially accessible features). The second is to lay off employees to pay for the work. Neither option is very good.
Ah, thanks. I'm German, I thought federal court orders were binding for the whole country.
> Small businesses are different.
Actually small businesses are exempt. The EU EEA has a threshold of 10 employees/2 million euros balance, and the US ADA - at least from a quick Google - of 15 employees [1]. If you're hitting either of these thresholds, you're large enough to afford a once-off expense and hell, you should have a couple tens of thousands of dollars in reserve anyway simply because your employees rely on you being able to make payroll even if disaster strikes - even at 10 employees and 3000 dollars per employee in total cost, that's 30k in payroll a month total so you should have 60k in reserve anyway.
For those who don't, well, please don't operate in a way that externalizes costs and risks onto others - no matter if it's disabled people, your employees or your customers.
> Faced with tens of thousands in expenses, they have two options.
A lot of small businesses don't do their own website, they use social media or SaaS providers - Wix, Wordpress, Jimdo, or (for restaurants) Just Eat and their competitors. For them, the SaaS provider does the heavy lifting, and besides: these sites usually don't have much content anyway.
[1] https://www.eeoc.gov/laws/guidance/ada-primer-small-business...
And even if you have no empathy so you don't give a shit about anything unless it affects you directly (in which case UI design isn't for you), then consider that unless you die young or have supernaturally perfect health, you're going to need accessibility features yourself some day, so your lazy anti-accessibility attitude is going to come back and bite you in the ass.
And you're dead wrong that accessibility necessarily worsens the experience for people without disabilities. It's useful for everyone.
Please leave the user interface design to other better educated more compassionate people, and stick to the back-end yourself.
Put my remarks in the context of a startup that has a limited runway and needs to choose between working on something that would appeal, entice and attract the majority of their target user base and trying to accommodate the needs of the fraction of the same. You can "boo" all you want, but their choice will be obvious, as it should be perfectly understandable, even for people from the second group.
> Please leave the user interface design to other better educated more compassionate people, and stick to the back-end yourself.
Ah, a gratuitous personal attack, the best way to strengthen any argument.
And anyway, a lot more people would regularly and happily use screen readers if it weren't for all those badly and lazily designed web sites and user interfaces that use modal dialogs and don't bother supporting accessibility, which make them much less useful and accessible for everyone.
Speaking of context: Even if screen readers or people with disabilities did not exist, there are still many important legitimate reasons not to use modal dialogs, and still many perfectly reasonable alternatives, so your bogus statistical argument for using modal dialogs is still dubious and doesn't address any of those other issues.
https://ddiy.co/web-accessibility-statistics
>Here are the numbers regarding how many people have disabilities that make accessibility features necessary when surfing the internet.
>4.9% of U.S. adults have a vision disability with blindness or serious difficulty seeing even when wearing glasses, requiring screen readers.
>5.7% of U.S. adults are deaf or have serious difficulty hearing.
>10.8% of people with a disability have a cognition disability with serious difficulty concentrating, remembering, or making decisions.
>There are an estimated 300 million people in the world with color vision deficiency which requires color-adjusting tools on sites.
>About 16% of people who use screen readers have multiple disabilities.
>Roughly a quarter of Americans with disabilities (26%) say they have high-speed internet at home, a smartphone, a desktop or laptop computer, and a tablet compared with 44% of those who report not having a disability.
>18% of US adults report that they have a disability, according to this survey, which asked respondents if any “disability, handicap, or chronic disease keeps you from participating fully in work, school, housework, or other activities.”
>Americans with disabilities are three times as likely as those without a disability to say they never go online (15% vs. 5%.)
>By 2050 nearly 2.5 billion people are projected to have some degree of hearing loss and at least 700 million will require hearing rehabilitation.
>By 2060 the number of people 65 or older is expected to double to 98 million.
Another point is that screen readers aren't only useful for blind people. Here's a demo of a screen reader that I implemented for reading the long but amusing catalog object descriptions in The Sims ("Simplifier" demo starts at 3:15), that's useful for kids who aren't good at reading yet (but want to learn while playing a game), and anyone who is too impatient to read all the tiny text on the screen:
Demo of The Sims Transmogrifier, RugOMatic, ShowNTell, Simplifier and Slice City:
https://www.youtube.com/watch?v=Imu1v3GecB8
Also check out the "talking pie menus" and tool palette in X11 SimCity (aka open source Micropolis):
X11 SimCity Demo:
https://www.youtube.com/watch?v=Jvi98wVUmQA
OLPC SimCity Demo:
https://www.youtube.com/watch?v=EpKhh10K-j0
Please make some effort when refuting the arguments of others. See "target audience" in the part that you quoted? That's the keyword.
If one's making an augmented reality app that assists car mechanics in repairs, what would you say be the percentage of screen-reader wielding people there?
> And your claim that accessibility "worsen[s] their [non-disabled users] experience" is flat out wrong
For one, you are taking it out of context. For two, you keep repeating something as if it would make it true.
Here's a little exercise - consider what it would take to make https://finviz.com/bubbles.ashx page accessible. Then, consider what the target audience here is and ponder the choice of working on things that would benefit said audience (i.e. improving their experience) and refactoring the page to be compatible with screen readers. That's what I was referring to in the original comment. It's all in the context, it depends.
If adding support for accessibility delays their product delivery, or raises their costs, it's another tradeoff that might even kill their product. And then it wont be a case of the software not being accessible to those needing those features, but it not being accessible to anybody.
Sure, where the law mandates it, they can always do a half-ass job to be, in name, compliant. But full (or proper) accessibility will be judged in the end like any other feature decision.
You might consider those features essential, but you'd be surprised how many business features get cut to get something out, even more so for an MVP.
If you think those designing most websites and apps people use are made by "more compassionate people" who'd jump on such features out of ethical concerns, you'd be quite off.
Heck, this very website (HN) has a quite bad accessibility track record even considering the average website. Among other things: image elements do not have [alt] attributes, form elements do not have associated labels, links do not have a discernible name.
And this is from a major VC company with tons of resources, and a place where thousands upon thousands of devs frequent.
So, while everybody can get their "morally superior and empathetic" rocks off judging the parent, the reality is more like what's described above. It isn't bad if somebody points to the reality - or to the hypocrisy, if we're to see it ethically.
99.99% of accessibility things are covered if you just follow normal, established software development practices. Unfortunately, a lot of software developers overcomplicate things, for example by adding modal dialogs to websites. Modals are common and established design patterns in desktop apps, but not so in web and mobile apps. Applying one environment's UX patterns to another is asking for trouble.
This isn't quite true, when you get into things like using aria attributes. I definitely wouldn't put it at 99.99%. And I think a lot of vendors of accessibility software get to skate where others would have their feet held to the fire. They could be doing more to make their software easier to use and for developers to make it accessible.
I used to work as a contractor for the CDC, so I have experience in web development that is held to a higher accessibility standard (we had an actual real person who would verify our work and certify that it was accessible.)
Some things that come to mind are color contrast ratios where you have to pass different levels (AA vs. AAA) https://webaim.org/resources/contrastchecker/
And being able to navigate a site with a keyboard, or announce when sections change. That stuff isn't automatic. It might be baked into whatever framework you're using, but those frameworks have bugs too.
Here's an example I ran into with React Native, and it's still not clear if they ever fixed it or if it just got closed as stale: https://github.com/facebook/react-native/issues/27989
It is painful that some managers, architects or developers might think this way. Accessibility is not just for disabled people, such as the blind or those who have lost a limb. In the kitchen, for example, it is great to have push to open drawers (e.g. based on IKEA's EXCEPTIONELL [0]). If your hands are dirty, you can still open the kitchen drawer without getting anything else dirty. And this is just one example of accessibility.
Personally, I see screen readers as an additional tool (like Copilot or ChatGPT) to be used on a daily basis by keyboard users.
Screen readers can also help you, even if you are sighted. For example, with a ShortCat.app [1] I have a system-wide ace jump [2] with a command list. I don't have to use the mouse to move the cursor - I have a keyboard for that. But in applications that are not compatible with screen readers, you can only choose "close", "minimise", "maximise" buttons, and the first option - close - is the best for such an application (e.g. Sublime Text).
In other cases, SR/SA will read the text for you. If you are too tired to read, or your hands are occupied with a sandwich or utensils, you can use SR to read an article or paragraph for you.
[0]: https://www.ikea.com/gb/en/p/exceptionell-drawer-medium-with...
[1]: https://shortcat.app/
[2]: https://github.com/acejump/AceJump
Non-bugginess is also accessability, but I don't see a law saying that you can't release unfinished software. So how would accessability be anything more than all the others unimplemented issues stuck in the backlog?
I haven't found a single case where improving accessibility doesn't also result in a meaningful improvement for some set of users who don't need accessible features. There is absolutely no good reason not to make things accessible. Heck, I'd make an app accessible even if I had irrefutable proof that it had no users who need it to be accessible.
However, consider how much do you worsen the experience of the majority, and how much do you improve it for the minority? I think that should factor into this decision.
I think the article is mostly trying to make an effort to inform people of the options available to them, so that when you are creating estimates of the work required to support accessibility requirements, you're not overestimating out of sheer ignorance.
Voice control software is used most often by people with limited use of their hands, verbal commands replace keyboard and cursor control inputs.
> Standard browser controls are all 100% accessible by default.
Unfortunately, this is not entirely true. For instance, `select` elements and their options don't reflow in most browsers. It is true that the native elements are much more accessible than most alternatives developers create.
As a principle, I don't read any website that has a modal window, especially a modal "subscribe to our newsletter".
It's similarly annoying as paging controls that don't support "open in new window" and/or don't work with the browser history.
Sounds wonderful.
- 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.
The problem that designers are often trying to solve is that there is not enough information that there is a good way to put it on its own page - it's too small for its own page but too large for the table that we'd rather just add another column to.
We have an export button so you can get all the details in excel or LibreOffice or your tool of choice, though. And in a better world, we'd be writing proper desktop apps instead of web applications so that we aren't making stupid compromises like this, but here we are.
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.
On large applications, this can be become a nightmare to maintain.
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.
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.
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.
The article states very clearly the use cases for which modals make sense:
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.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.
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.
They sure do. Especially modal dialogs. Everybody has been trained to hit okay automatically, because they're so prevalent on things that don't matter. Good apps track history and have undo.
Apps that have changes that matter use more drastic things than modal dialogs. Just try deleting things on AWS.
These feel incredibly unrelated to me. Why does that matter at all for the display choice? A modal is getting used because it's a view into another section of the application that doesn't lose the current location of the user.
Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. It's just not important to most people what the string of characters is.
So...
Anywhere you've got multiple steps to complete, or an adjacent resource that might be related and viewed/edited in the context of the parent resource.
Or a form is being filled in and a user wants to enable extras, which requires filling in a different form, etc...
The modal is about not losing the current place for the user. Because most current users don't use multiple tabs/windows for the same product, and they don't pay any attention to the urls.
"Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice.
This is not correct. Normal users have learned that if they copy that URL thingie, and send it to someone else, that someone else will see the same thing they see now.
I don't know how many times I've received a link from someone saying "lol look at this hilarious dog" and ended up on some useless overview page completely devoid of hilarious dogs. Because some fucking designer decided to do exactly what TFA is complaining about.
I can think of 2 very good reasons right away:
1. It increases the complexity of the webpage
2. It makes it impossible to simply download or integrate the resource elsewhere
No, because in the one that intrinsically works, you're losing the user's context by navigating them away.
Which is what the modal is good for.
Whether that's worth it is a discussion, but at least this part of it is trivially easy to implement.
We're talking about BOOKMARKS, so what context do we lose? The users browsers home screen?
Tell that to my non-techy spouse and her +1400 bookmarks. You know what her most recent rant was about? That she cannot bookmark certain timetables at a booking platform she uses. Why? Because guess what: The timetable shows in a modal.
> The modal is about not losing the current place for the user.
Resources opening in tabs also don't lose the place of the user. But you know what modals do usually lose the user? The ability to interact with anything but the model while it's open. A usual gem is a form which opens a modal, where I would then really really like to copypaste some info I already entered in another part of the form, but can't, because the effing modal is in the way. So I have to close it, and that usually wipes all the info in it.
> "Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice.
If a web design can cause the user to get lost in the first place, then the problem isn't that there is no modal, and adding one will likely not fix it.
I've made multiple websites where URLs are routed to modals because the app made most sense as pages on top of an underlying state. GET /things/42/edit loads thing#42 in the background and opens the edit modal prefilled with thing#42's info.
A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task.
Preserving form data during navigation is something you have to consider for any form, even forms on the same page or separate pages where you don't want the form to clear when the user navigates away. One key design principle of modals is to make them mentally cheap to open/close/reopen, and modal state preservation is usually a part of that.
That cherry on top can be just as easily implemented by opening the /login in a new tab. Auth gets set, there, user is logged in even in the old tab, and doesn't lose his position in the page either.
Added cherry on top of that: If the user decides to log into the page halfway through the application, he can still bookmark the login page.
The same is true for almost every other use case of a modal where it displays a resource.
Tabs are builtin capabilities of the browser. Even terminal browsers like w3m support tabs. Why built something else that can be built poorly, instead of using what the browser already can do?
Funny enough, a page-refresh is usually what happens, after I fill in a login form that appears in a modal.
But even if it doesn't do that: If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh?
And on the off chance that the use case actually requires that, what specific advantage does a modal confer over two input fields (Username, Password), tucked discreetly along a "Login" Button into the navbar?
For example, a username/password in the navbar can make a lot of sense. If it's slightly more complicated than that, like if login has multiple screens (e.g. 2fa token, maybe SSO), then a modal can make sense.
On a mobile screen, having username/password in your hamburger slide-out menu isn't automatically superior to extracting it into a modal.
> If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh
I can think of a lot of examples where this can polish the experience.
Once again, I'm brought back to the airline checkout process where you might have almost finished booking a flight but you want to get flight rewards and autofill your contact info at the last step and realize you want to log in.
Games are another example -- I've built a modal-based UI for a large casino where there's always a round-based game going on. Guests can watch it. They can login to play. Deposit, FAQ, player profiles, game history, etc. are all cheap interactions that users can view and dismiss while participating in the global game without losing their state. At any moment they can login which enhances most of the pages with additional content.
Fwiw, I'm arguing that modal should be a tool in one's UX toolbox, not something you use all the time.
There is no other kind. The whole idea of modal window is stupid. It constrains the user instead of empowering them.
Solve the server's problems some other way that doesn't impact the user.
These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead.
> One key design principle of modals is to make them mentally cheap to open/close/reopen
Cheap for whom?
I don't think it's a good argument, you could also just use your own argument against you: Pages are only easy for developers but worse for users since you don't have to polish the UX in the way that a modal lets you. It's for developers that don't want to have to think about UX optimizations and defer everything to out of the box browser experiences. Which, granted, might be the best choice for everyone who doesn't want to think about UX.
But I find that to be an empty claim.
> These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead.
That is often a good choice. However, sometimes a modal makes more sense for an all-or-nothing task, or when the user is already in one of those "expando" forms, or a number of other occasions worth pondering for your app instead of dismissing modals without discretion.
Knowing when a modal does and does not make sense is part of a good intuition about UX.
In this current age, this usually means an SPA that will first load the underlying page, then the entire application bundle, start up the JS, detect the route, load the data for the modal over another request, and finally display the modal. In the multiple seconds this is happening, nothing indicates that a modal will be opened. Sounds familiar?
In fact, you can make a link open modal with left click but open in new tab with middle click. I think it is the most balanced way in my opinion.
Modal and tab can co-exist. They are not really mutually exclusive.
BTW, social media websites generally implements this in their feed view. A image behaves different when you click it with middle or left click.
That's what thumbnails and stubs are for.
> In fact, you can make a link open modal with left click but open in new tab with middle click. I think it is the most balanced way in my opinion.
Cool. How do I "middle click" on my phone? Left click is "open resource" by default. If a webapp doesn't have a damn good reason to overwrite the browsers default behavior, it shouldn't.
And "we thought it would make the design really pop", is not one of those reasons.
Try long press and open in new tab.
Besides, open in modal don't even mean the url won't change. Fb, reddit both open in popup AND change the url. Copy the url to other browser would just work as intended.
It is already a resolved problem in my opinion.
It was a resolved problem before that, by letting the browser do what the browser is good at, instead of implementing new UI paradigms on top of it.
> Besides, open in modal don't even mean the url won't change. Fb, reddit both open in popup AND change the url.
So I add more code, and thus more complexity to websites, in order for the browser to behave in the way it would have already behaved in the first place, had I not thrown the modal in there, and instead let it work as intended.
Yes, and the same can happen with any number of other things, like a keybind that scrolls back, or a link in the feed the user accidentially clicks.
Which is part of the reason why infinite scroll falls under the same category as modals as far as I am concerned. There is a reason why pages with lots of entries are paginated.
This is yet another instance of optimizing for something that can not be made perfect. Let me decide what I want. Give me the option to do both without much of a hassle. If a decision needs to be made regarding what should happen on a mouse-click, one may choose a sensible default (i.e. what is the most typical use-case), while leaving the option to configure the other choice.
You can always argue that many options are a non-goal, but any sufficiently sophisticated software needs training anyway. Configuration can be a part of that. Nothing is worse than a program in which the designer chose to make your use-case to be painful to be met.
Furthermore, a uri does not need to be bound to a view. In fact, one might prefer different ways to look at the same data.
I know how to close a tab, be it via keyboard shortcut or mouse click. I know how to resize it. I know how to print it. When content I want to glimpse at opens in a modal, I know none of that. Even if it is well designed, different sites will have different engagement paradigms.
My current pet peeve with modals is when I try to select text with the mouse, and drag past the edge of the modal, it closes.
Modal windows and how they interact with the user is obviously something that should be standardized, but that is a different discussion.
It already is. It's called tabs.
``` history.pushState({}, "", "/new-url"); ```
Moreover, modals serve one very important UI purpose in that they keep the user's mind in a context.
There's one kind of modality needed for computers, and it's the power switch.
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.
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.
Once you get how it works it’s neat.
It makes me furious
Not before reading your comment I had realized I never missed those extra buttons, or at least remembering missing them.
And I realize that while my implementation takes care of modifiers to open links in new tabs on my web apps, I always overlooked middle button.
The real problem though is that the web is very broken for building apps, and that the DOM API is missing a way to negociate the url changes on default clicked link behavior instead of the current «block event and update url» mechanism.
As for <a href="#">, it’s in the same boat, with the sole exception of jumping to the top of the page.
A few times I’ve encountered sites trying to be clever and detect Ctrl+click or middle-click and use window.open(), but this doesn’t behave natively: natively, middle-click or Ctrl+click probably open in a background tab, but open() opens a foreground tab, which will always be disruptive for people that use this stuff much, and sometimes infuriating.
This isn’t the only reason for having real links; there are also things like status bar text on hover, and context menu on right click or long press, which may include options like Open Link in New Private Window that cannot be emulated in any way.
If you want to intercepting link click events, you must check if the click is modified in some way like this:
Note that middle-click fires an auxclick event instead of click, and right-click fires contextmenu first and then auxclick if that’s preventDefaulted.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.
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.
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.
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.
For example, you are running a project review meeting and want to quickly jump between tickets on the kanban board. Your main business context is the entire board (you might have filters/sorting), and you keep a mental record of where interesting tickets are placed on the screen. However, during the group discussion, you need to quickly jump into an individual ticket to reassign it or scan through comments for 5 seconds. In this case, using a modal to show ticket details is preferred to redirecting to a separate 'details' page because it does not scramble the user's context and their mental model about what's on the screen. Of course, the UI still should support cmd+click to open a full page dedicated to that ticket, but that's a 10% use-case.
[1]: https://gwern.net/index
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.
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.
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.
AWS Management Console begs to differ:)
Modals can definitely be bookmarkable if they are dependent on a certain path or query param to appear.
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
> 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?
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.
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"
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.
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.
https://www.kryogenix.org/code/browser/everyonehasjs.html
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.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
Also, you're going to have to create modals eventually, alerts are needed in most applications so you might as well create a thorough component.
Avoiding modals because of those who browse with JS disabled doesn't make much sense. Especially when they can temporarily enable on your site, as disabling JS for security reasons would mean they trust your site if they're still using it enough to reach a modal. You can still create fallbacks, but they'll be ugly considering most modals are for nested form changes or alerts.
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."
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.
That said the modal load is just as slow.
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.
Just pop up a modal and reload the Issue/Bug state when done.