I was just about to share this our designer, who is always talking me down from modals, when I reached the bottom and discovered that our designer is in fact the author.
I seriously can't say enough for this message. Adrian helped us redesign our app 2 years ago, dispatching many many modals in the process, and delivering a huge increase in usability that our customers and users very much do care about.
There's a very simple rule of thumb: must the user give some feedback before it makes any sense to use the rest of the site? If so, it's fine to use a modal. Otherwise, don't. Some examples:
Payment page: not a modal. The user might want to add more stuff to the cart, even when they are literally one click away from purchasing. Blanking out the rest of the page means they now have to work around the site to buy more stuff.
Error message: not a modal. The user is vanishingly unlikely to report an error immediately (obviously it's logged in any case), and probably just wants to try again with slightly different input.
Irreversible action confirmation: not a modal. For the same reason as the payment page, the user might want to do something else before retrying the irreversible action. Just display a prominent message so the user knows the action is not yet done. Or, if at all possible, implement undo instead.
My job depends on it: OK, use a modal. We forgive you.
I remember reading somewhere that most (modal) dialogs are just lazy design. It's easier to have a dialog component and throw whatever notice or controls in there. It's a predictable and flexible canvas.
Your password is incorrect? Error dialog. Easier to design and build that a warning state on the text-boxes and a message close to the login button.
Writing a post? Editor dialog. It's easier to design and build than something that's inline, grows to accommodate what you're writing, and works predictably when you scroll away or click something else.
There's something the user should know? Alert dialog. Much easier than figuring out where in the component hierarchy you should inject a warning, how it should look, what controls you should disable, etc.
I used to have the opinion that modals were bad, but now I think there's a good middle-ground where a lack of modal sometimes generates implicit states with many edge-cases that makes the UX more complex.
Maybe it's lazy but the important question should be: is it good design?
I don't think it is, as it hides some information from the main page. But I think it can be done well and be useful, as said at the end of the article.
And OS modals are crap too. Many many times I have watched someone completely ignore to modal message and get frustrated trying to click on something in the background.
The more important question: do the people paying you care if it’s good design? Because the people who have paid me thus far in my career have not cared.
A lot of people don’t understand design as something that goes beyond the surface layer, though. They see that someone picked a pleasing color palette and layout, but maybe they don’t imagine that a designer would come and tell them to stop using modals.
This is a good point, and often the reality - it’s unfortunate that it is being downvoted. But it’s a defeatist stance. It’s a central part of the designer’s job to contend that human factors are important, and explain what the effects of shortcuts and poor user experience are on the value of the product and the well-being of its users.
If you’re lucky your client hired you because they, too, care and believe design to be important, but that’s far from a given.
Well yeah, but if the person who is in charge of the modal is the implementer, not the designer, then they may not have the expertise to design a good ui.
And many designers are artists ("designers") not ux engineers, so their main goal is to make something that shows their artistic skill - they're going to be trained in design packages, not designing a good ui.
(I mean, when was the last time you saw a clickable button on a modern user interface? nowadays it's just "guess what this shade of grey means")
> if the person who is in charge of the modal is the implementer, not the designer, then they may not have the expertise to design a good ui
Isn’t the obvious fix there to let the designer design and the implementer implement? Obviously if the designer is kept out of the loop completely they may not even be in a position to argue for the importance of good design (or just any design process), but then it shouldn’t be surprising that the outcome is bad design.
Well for many programs there isn't really any separate designer, particularly for line of business apps. That was really where I was coming from - the person who designs the app is simply someone who was trained in coding.
In any case, as I said, you get a problem if the person who designs the app is simply someone who was trained in coding, and you get a problem if they're simply someone who was trained in art.
Have you considered that the problem could be your choice of people who pay you rather than the idea of good design being valuable? Not that it's necessarily an either/or situation here, mind you.
True that may be, if you are not uncovering this during your interview process, do you think it's possible there's room for improvement in how you conduct your end of the due diligence process?
Unfortunately, the CTO that hired me left the company two weeks after I started which caused a significant cultural shift. I did my due diligence, no need for the virtual gaslighting.
> I did my due diligence, no need for the virtual gaslighting.
> Unfortunately, you never really find out until you work somewhere.
If you invest in a stock that you tried to research and it drops to a value of zero and you say "well you never really know until you try it", am I gaslighting you if I tell you that there's room for improvement in your due diligence process?
A CTO hiring you and then leaving the company 2 weeks after you started is a major red flag. This is not a common occurrence in anything but a dysfunctional org. Now, there is of course only so far you can predict into the future, and surprises do happen. But whose decision was it to accept the offer? And who is ultimately on the hook for it, whether it's in your control or not? To protect yourself, you need to own the responsibility for that decision, even if you have no control over it happening inside the company.
There are companies you can accept offers from where the chances of this happening are one in several thousand, and companies where the chances are closer to one in fifty. To what extent are you confident in your ability to accurately predict and gauge a range and confidence interval about that?
I used to say the same things you did, and I kept getting the same results. Eventually, I just got tired of it and I realized I'd do quite a lot to prevent it from happening in the future -- or at least, if it happened again, I didn't want it to be a surprise. I'm thankful to say that I'm significantly closer to that point now, although it took many years of trial and error. And surely, I have even more room to improve, and I look forward to honing my technique even further as I gain more experience!
If what you're trying isn't working for you, it may be worthwhile to try to reconsider your process and see if you can improve it. If you don't even try to improve it and you're unhappy with your results, why do you think that would ever change?
You are truly insufferable and making incorrect assumptions. This happened once, in my current role.
> This is not a common occurrence in anything but a dysfunctional org.
This happens all the time in orgs all over the planet. Hiring managers and executives get new jobs and things change. Time from offer acceptance to starting work is always nonzero in big companies (measured in weeks to months in most of the fortune 500, I'd bet - my current company is Fortune 10[1], so there's that - cto in this case means of the particular division of this company, not the parent).
Now, please... do us both a favor and stop talking out of your ass.
> I also agree with grumple that you are truly insufferable.
Go for it!
I get paid well to do quality work by employers who appreciate the value of that. Why would I care about whether someone who is content with mediocrity finds that insufferable?
My message goes out to those who want to do quality work, who maybe aren't there quite yet, and are keeping their minds open: don't give up. Every little bit helps. Every career transition you make to a firm that has a little bit of a higher bar than the one before is a difference to be proud of, and one day, you eventually arrive at one that's fairly close to the top. Be patient, keep improving, and don't give up! You can do it!
>I remember reading somewhere that most (modal) dialogs are just lazy design
If they are lazy design does that mean they are quick design, especially if you find a problem that needs solving in the middle of getting ready for the launch of your MVP it might be easier to do a modal.
Of course this would lead to legacy design that needs fixing over time, and legacy code to support the quick and dirty design decisions.
Especially blocking modals (which both stop your code and the user) are a damned easy way to interact with the user in most programming languages. Nothing is easier then to write alert("foo") or if(confirm("are you sure?")) do_sth();
I don't want to complain, website is harder to read with all that 8 bitsh font type...Maybe normal post with one example for each idea would be good enough.
That's kind of what I thought too. Our app is very Modal heavy (including modal inception), but I can't think of any case where the suggested alternatives would actually be better. And that's backed up by the fact that our users regularly tell us how easy and awesome it is to navigate through it.
Granted the authors could have tried to get the website to work in reader mode (they might be missing an `<article>` tag or some `<meta>` tags). But in the meantime, it works well in lynx ;)
I agree about modals. But seems like the same points can be made about the website's design that trying to teach others about modals, have you considered using plain text or a more readable website to convey your point across without resorting to 1-bit retro decoration?
If my obese doctor tells me I need to lose weight, I have two choices. Either I can weigh his advice, or I can ignore him and cluck that his comment is really rich considering he is overweight himself.
I think the first option is helpful; the second option is boringly obvious and not helpful.
As for the style, I found it to be entertaining and helped make a possibly dry topic seem a little less like a lecture and more like friendly advice.
That's a bad analogy. The reason why you trust your obese doctor for weight loss advice is not because their body shape, but because of the credentials (Doctor).
Replace a doctor with a random stranger (which is what this website is, I don't know the person giving advice about the modals) on the street who is obese and tries to tell you with authoritative voice - "Hey! Listen, you're fat and this is how to lose weight!".
That's more accurate. I can agree with you about the entertainment value, I personally don't see it but if someone is entertained by it, good.
The depth and clarity of the advice and the effort put into presenting it work as solid credentials in this case. The author is clearly a “doctor” of design.
Look how well those those graphics get their message across, whilst also matching the style of the text. That takes a real steady hand (both literately and figuratively).
Yeah I had a hard time reading it without getting distracted. So I went to a website that converts pages to plain-text and the first thing that popped up was a newsletter modal.
> Considering that the target audience is other designers, why does the presentation matter
I fail to see the logic here. Good design helps people learn easier. It's not like designers have some unique ability to learn equally well no matter how poor the design is.
Well context... the information the author is presenting is simple, right brain stuff. No one with UI experience is going to have a hard time digesting it.
That isn't actually true. I think I have UI experience, but I would actually have preferred some mockup examples instead of 1 bit bmp pseudo-thumbnails to represent his ideas. Surely it would be better to show some good user interfaces.
I think it kills the credibility of the designer trying to tell others, authoritatively mind you, that modals are bad while A) I have no idea who this person is or know their credentials B) Why should I listen to them if they're presenting it without a good understanding of design which is what they're trying to preach others?
IMO it totally kills it. Others may not have as strong of an opinion. This is the age old question about separating art from the artist. With authoritative didactics, especially as a stranger on the internet, it is even more important to associate art with the artist so to speak. It comes with responsibility.
Modals are basically the fancy clone of old school javascript's alert(), and while everyone would rightfully be annoyed being "alerted" needlessly, designers have convinced themselves that it's fine to show modals frequently?
Edit: Claiming it's only designers' fault, or generalizing that all designers do that, is obviously wrong. I did not mean that. What I meant to convey (partially failed) is that examples propagate, and somehow design choices are the beginning of this propagation chain.
My impression from seeing old windows version (never having used anything older than vista) was that in general using an extra window instead of a separate pane inside the window was more common. As far as I can tell, the old windows explorer would pop open a new window for each opened folder. Now it seems like most programs are run in half/full-screen; They arent really treated as windows. IDEs have their own window-layout system anyways, right? (Modal) dialogs are probably more at place in a world where windows is more that just the name of the os.
What I was getting at is that the important thing is the concept (which is about as old as GUIs), the other stuff is implementation detail. The 'modal' part of the a modal dialog is that it takes you out of the 'modeless' interaction state where you can take one of the many UI actions available to you to a state (mode!) where you can do very few things and nothing else.
Making GUIs less modal is a similarly ancient UI design holy grail. Applications are modes hence everything from OpenDoc to the just-announced App Clips. A familiar clunky modern mode is 'native' apps vs 'apps' in browsers - a big chunk of technologies many programmers work with today are directly or indirectly related to mitigating its effects.
Yeah I think nowadays a lot of people think "modal" means "a dom element positioned with respect to the viewport that prevents interaction with the rest of the webpage".
The classical sense of "a collection of related controls that prevents interaction with the rest of the application (however the collection, controls and application are implemented)" is surprisingly rare now, particularly since the older sense were often called "dialogs" (and indeed, "modal" was short for "modal dialog") - intended to emphasise that this was communication between the user of the application and the developer of the application to decide how the application should behave.
Therefore, a modal dialog should be used when the communcation couldn't have happened before and cannot happen later, and the developer of the application cannot do something intelligent and allow the user to correct it later on. (For instance, just delete the thing and let them undo it - no interaction between the developer and the user actually needs to transpire.)
I’m not sure this logic is honest. In the black and white world you posit, an alert is merely a window of information just like a browser window. Of course the devil is in the details. I don’t mind a popup if it’s for SSO but I do mind it if it shows an ad. The same goes for modals, and the differences between modals and alert() are for more significant than you give credit.
The problem problem with modals in a web page context is that they go against the statelessness of the html request/response model. They end up building up a lot of local state in the client, both model state as well as UI state, that eventually need to be reconciled with the server. If the user closes the modal, is the data saved for later? Does the form reset? Does the server know anything about it? If it is a wizard, were previous steps saved? And so on.
After many years of working on and with intercoolerjs/htmx, I now typically prefer inline editing and wizards, to a modal solutions. It fits better with the web model, allows for proper URLs, etc.
The inline-edit demo from htmx is a good example of something that might be implemented as a modal by some developers, but works very well as an inline-edit UI instead:
I’ll try to condense it more. If you play a video game and a modal pops up, it takes you out of the experience. It’s the same as (hypothetically) me having to go into my HN profile to find a list of comments I upvoted to then go ahead and downvote (versus just having the downvote button next to the post).
Can’t teach this stuff, you basically need to be confronted by tons of bad UI in software, games, physical printed forms, processes, until you get a good sense of taste.
I can’t teach HN devs that my thumb covers both the upvote and downvote button on mobile. Can’t teach it.
Imagine you're playing a game and you click "Options" and a modal window pops up with the options you can tweak. Or an endless image gallery where clicking an image enlarges it inside a modal that you can dismiss to resume scrolling without losing your place.
It didn't wrongfully force you out of experience, it's what you wanted.
Seems like we're talking about getting in the way of users where crappy modals are just one way of doing that. Navigating to a new page seems even more jarring in TFA examples.
Yes but have you seen software - almost anything that's been developed since the growth of mobile platforms has basically done the exact opposite of what that field of science teaches.
My biggest issue with modals, is that they never seem to be tested with mobile devices in mind.
So when I'm on my phone, the ability to close it is often off the screen.
The only choice is to leave the website at that point.
I often find the pattern on websites that I visit the site for the first time due to a link, read maybe half a paragraph, and then get a modal popup asking for my email address to subscribe. I've never read any content from them before, how would I know if I want to subscribe? My phone is also in landscape mode, so the modal's close button is off the screen, and I can't scroll to it cause it's an absolutely positioned modal.
So the only logical thing to do is avoid the site in the future, they're more interested in extracting money from their existing readers than getting new readers. Sorry, maybe if you had let me read one article I may have liked your content.
My biggest issue with modals, is that they never seem to be tested with mobile devices in mind
I feel your pain.
The web sites I maintain have at least 70% mobile users. But the managers (and designers!) only see them on giant-screen desktops, and only care what it looks like in-house, not to the customers.
I'm tired of constantly telling layers of bosses that what they want won't work on mobile, which is where their customers are.
The key design principle overlooked here is Progressive Disclosure[1], which modals and dialogs can be very good at delivering.
Progressive disclosure retains user focus on a single task as opposed to showing everything at once. Accordions have similar function to modals and dialogs but adding further task controls to an already complex interface isn't always the best solution.
The author goes on to state that even full screen modals are bad, but what difference does the user see? If done well the user should still be able to use the browser back button, escape key, etc to navigate out. In modern applications, pages can transition from one to the next without a "full page load" -is that also bad for some reason?
Think of many popular mobile apps like Instacart, Doordash, etc that allow a user to dive into categories that slide on top of the existing content to give further controls; is that not ok?
Every element in the DOM can be applied inappropriately but that doesn't shift the blame to the elements themselves. One could argue an entire dedicated site that only uses modals based on the misuse of illegible fonts would be about as apropros.
TFA is not saying all modals are bad, just most. Progressive disclosure is a fine thing, but that doesn't have to mean modals. Most of the time a discreet notification that doesn't interrupt the user's flow is what's appropriate; I think Tidal does a good job here, by highlighting one feature per screen, and if I don't tap on it to see what it is I'm able to go about my way.
Since we're quoting NNGroup, here's their guidance on modals[1] (emphasis mine):
1) Important warnings
2) Critical to continuing the current process
Most modals are unasked for, not relevant to the user's current needs (no matter what the dev/marketing might think), and unwanted. Modal to select filter settings when I've clicked/tapped the 'filter' button? That's a good use.
TFA literally says don't use full screen modals, ever. I disagreed with examples of that not being necessarily relevant with the way today's applications can work.
Important from the NNGroup article you linked even demonstrates great modal usage and states "3. Modal dialogs can be used to fragment a complex workflow into simpler steps." and "4. Use modal dialogs to ask for information that, when provided, could significantly lessen users’ work or effort."
That's important - modals are not just intrusive pop-ups as many designers and others in this thread have decided that they are. Again, every element can be used inappropriately but that doesn't mean the elements are to blame.
You're right about full screen modals, I've seen those done right and "never use x" is rarely right all of the time. And modals can be done well, but 90+% of the time I encounter them, they're not. They're not related to the workflow I'm currently engaged in, they don't save me any time, they don't serve me.
Again, I'm not saying (and I wouldn't characterize TFA as saying) modals per se are bad. But the priors are such that absent any other information, modals are suspect.
If you design a desktop application, like say Word then modals are more appropriate than the alternatives in many situations. For a site like Medium, a modal is an annoyance. If I asked for something (click Settings) then I am happier with my modal than if I didn't ask (we're going to stuff cookies on your page anyway, here is our arse coverer).
The underlying message I take is we "use too many things that make it easier for the coder and harder for the user". Sometimes that's a modal, but sometimes that's NOT using a modal!
I hate modals - I'll never add them to products I build.
Edit: To provide a little more substance here - for example in one product of mine that actually has customers - confirmation is done via inline elements that slide into the page.
So you want delete a comment for example. The delete/cancel buttons slide into the box for that comment. No weird context switch for your eyes.
Since you deny a weird context switch for your eyes, are these actually inline elements? That would imply the size of the containers is changing. Which would surely be a weird context switch. But at least I can have no doubt what my action is about to affect - I get frustrated on sites when it says "you're about to delete these items" and i have no idea whether it agrees with me about which items I'm about to delete or not.
But if they're overlaid elements, like a context sensitive menu that contains two options - delete, cancel - is there any substantive difference between a menu and a modal? The main advantage of a classic menu over a modal seems to be that it has a implicit cancel option that is uniformally implemented. But nowadays, menus are implemented without toolkit support - yay dom, yay - so even that is not consistent.
Yep okay, so I guess that's not inline by my definition (since it overlays the text). I have definitely seen webpages that change the size of the containing box to add in the confirmation message and buttons.
I guess it's an between case I didn't consider - it's maybe not modal with respect to the whole app, but it seems to be modal with respect to that one comment (you can ignore it and do something else with the rest of the program, but with that comment, you can't even read it).
Typing this from Ubuntu, Gnome 3 I think, in Firefox, I press Ctrl-S to save the page, and I get a modal dialog, which cannot be even moved. Sometimes, it actually obscures something that I cannot read on the screen.
If you have to use a modal element at least allow me to get it out of the way so that I can read the text under it!
This is only tangentially related, but one thing I'm absolutely sick of is rounded corners. I don't know why, and I don't know if it makes any sense, but opening a page and seeing literally everything with border-radius makes my blood boil. It feels like they're trying to protect me from sharp corners, as if they're dangerous. Come on, we're all adults here. We can take a few 90 degree angles.
The new GitHub UI is too damn round. Everything is rounded. I’m all for changing a UI to make it better. GitHub needed to change some things around because it is cluttered with features and hard to navigate at times. But rounded corners everywhere is all I see.
> Come on, we're all adults here. We can take a few 90 degree angles.
I know that 90 degree angles on webpages are not more dangerous for children, parents, adults, or any other known subcategory of humans than for any other known subcategory of humans, but ... lots of people who use webpages and dev tools are actually children.
Didn't a lot of us get started as kids?
Have we collectively forgotten the olden days, when to print something, the solution was to ask the neighbor's next door kid? (who was probably you). Printers aren't any easier to use today than they were back then, but I guess that practice is over nowadays.
Fair enough, but some of the worst offenders of this aren't really targeted at children or something they'd be interested in. The new Github UI (which I adore, besides this particular issue) is a really bad offender for example. If you go to your profile page, there's not a single not-round border. The exception are the little squares showing activity, which makes it even worse because in the caption underneath they are rounded. What happened there?
Modals are a good way to show complex content without throwing away your current render. Whatever you were doing before the modal came up, you can go straight back to that. No re-draws, no scrolling back to the place you were at.
Modals are good for when you need to show a new blocking state without losing the current state. There are many valid reasons for that scenario. Even for modal inception.
Use them for that purpose, no need to swear them off completely.
The one UX anti-pattern that needs to die for sure is what this site calls "self-spawning modals". They're not only on websites — iOS is very annoying with them for example.
I've been preaching against modals and carousels for years. I'm a big fan of http://shouldiuseacarousel.com/ and while I had long ago intended to create with a similarly implemented site that demonstrates the pitfalls of modals with a series of modals, this site does a pretty good job of highlighting the main issues and alternatives too
Hah! I often have the experience that indeed a modal should actually have been a new page, but I was too lazy to build the thing so I went with the modal. Then later the modal needs more options or fields, and I end up having to convert it to a new page anyway... lesson mostly learned now. Agree with the article.
One thing I like to do is preview a link by Force clicking on it in my browser and scrolling through it–the preview window lets me scroll, but not interact with the page. For many sites this is quite convenient, because I can skim the page without being interrupted. But when modals pop up they cover the content and I can't read the page because I can't dismiss them! So if you're looking for another reason to drop modals, here's one.
Also, hilariously this website uncovers a bug in Safari where the cursor doesn't reset once you leave the page bounds, so I have a huge pixellated cursor hanging around until I click somewhere else :P
Oh, another of Apple's hidden features. Once upon a time, one button mice were a feature so that features weren't hidden and even beginner users could quickly become power users.
I'm reminded of a quote in Inside Macintosh Volume 1:
"But, gentlemen, you overdo the mode."
From John Dryden, The Assignation, or Love in a Nunnery, 1972.
That quote really stuck in my head.
I agree, the site visuals and short messages doesn’t explain well why they are bad.
I’ll try to fill that gap.
Modals switch the application normal mode to get your attention. So they interrupt your “flow”.
Most of the reasons to use them could be resolved by other means, that are better in terms of UX but requires more work in both design and implementation:
- Confirmation modals can be substituted with auto-save, undo, and restore, but is more complex to implement.
- Modals to show more info can be resolved with progressive disclosure or by improving the information architecture.
However, like with many design choices there are cases where modals are a good option. For example, for certain confirmations and navigation the advantage of the modal is that the backdrop makes clear where do you go after dismissing the modal (bottom sheets in mobile are a example).
Another reason why modals get a bad rep is that they have all sorts of implementation issues in web, and in the desktop the mode change for a window is not prominent (macOS solves that with sheets, but Windows still has that problem)
There are so many bad modals in mainstream desktop software. Is there any good reason that an open file dialog completely disables all other interaction? What if I quickly have to task switch, or a piece of info relating to which file i wanna open is just off screen?
A personal favourite is osx Preview and the rename and move file drawer you can get from the status bar of an open file. That guy can't even be moved, and perfectly covers up the portion of a document likely to contain info relevant to a filename.
The website is readable only at 30% zoom(couldn't zoom out even more) on the 4k 27" display also it messed up mine scroll wheel in some way, broke mouse cursor.
Modals can be a lazy (and worst, wrong) solution. But I've found that pavlovian bashing of modals is as lazy and unproductive.
> And remember to always ask, kids:
>“Why does this have to be a modal?”
In my experience people don't need to be remembered to ask this. And generally people can't justify why it shouldn't be a modal or why a non-modal solution is better than a modal one.
Back when js frameworks became a thing, modals were a shiny ball that everyone wanted to put into their app (because they came with the framework). Designers that worked with these modals became poisoned to the fact that this is how a UI should look. Like an old hairstyle they're now thankfully going out of fashion.
I've been using Azure a lot, and they use blades (essentially horizontal accordions) instead of modals.
I was playing with Alibaba Cloud's UI and it's all modals and feels much much nicer to use. I wouldn't use Ali Cloud due to Chinese ownership issues, but I do like their UX.
Eclipse uses modals in the worst possible way. Usually you want to copy the name of a type or variable into a modal but you are already into two layers of modals. You will have to close all of them and lose progress. Using more than one layer of modals is always bad design.
In the web sense of "true to web form" brutalist? Not really, for instance the tables are not made to look like TABLEs and are in fact ULs and such. This design aesthetic might better be described as "(Mac) Classical". (Brutalist isn't only about minimalism.)
I use full screen modals for my new project. A list of items. U click one and the item appears in a full screen modal. U close and you're at the same place you started.users love it and i dont see a problem with it.
My main gripe with modal windows is the name. The first couple times some developer told me that's what she was using, I waited for her to explain what modal meant. But she did not, as if it was standard self-explanatory terminology. Way to name something a word that sounds like it has a standard (even deeper) meaning, but does not.
With time, I have just accepted that this is what modal means (I'm going to create a window of this type to display the data/filters), disconnected from any meaning of the term "mode".
AFAIK, it is based on the word "mode", because what's supposed to happen is the rest of the page is disabled while you deal with the modal. You've switched modes from "normal usage" to "the popup".
If you can still interact with some other part of the page while it's open, it's not a modal, it's just a popup.
It's a term from the UI design world, and it goes way back. A mode is a state where the app accepts certain inputs from you, the user. A new mode means previous buttons and shortcuts are inaccessible, and the same input may produce different results. Either coincidentally or directly related, Vim's modes illustrate the idea well—in contrast to editors where input, motion and shortcuts for extra functions are available together.
The trouble with elaborate modes is that the user has to mentally keep track of which mode they're in (which is what the term describes); and that other functions are inaccessible even though they might be useful to resolve the situation. However, modal dialogs are a streamlined and visually distinct extreme of modes, with an established history, so some don't consider them problematic. (Modes that are difficult to notice are still a no-no.) OTOH dialogs are frequently used as cheap bail-out by programmers, especially in desktop interfaces—since they're very easy to produce, completely synchronous, and shift all problems onto the user.
I guess I just have to live with it when I pop in and out of the UI coding world. Just like in Python a .method isn't what the natural word typically means, but just has gotten a domain-specific meaning attached to it in that world.
Just because you cant see the connection doesnt mean its not there.
Adjective, (of a proposition) in which the predicate is affirmed of the subject with some qualification, or which involves the affirmation of possibility, impossibility, necessity, or contingency.
Its pretty plain to see how a confirm or error message is applied to that definition no?
Not really. It's a stretch (at least for me) to see the connection between a window that shows you some data, or a toggle, or some arbitrary information and the idea that the window should be called "modal" as if it controls some "mode".
You're radically misunderstanding that definition.
It has to do with the notions that are expressed by "can, should, might, must, has to" etc. These words (most of them are called "modal verbs" in English) modify a proposition in such a way that they do not mean it happened/happens/whatever, but qualify it, or indicate its possibility etc. So "he's going out now" is a proposition. "He can go out now" modifies that proposition - no longer are we affirming it, but merely affirming the possibility or permissability of it.
Nothing about "are you sure" is modal. A modal dialog is called modal because the mode of the program has changed - no longer can it accept requests to delete articles or add text or modify an avatar, but it is now in a mode when you can either say "delete this" or "don't delete this".
In particular, if you showed an inline prompt that says "are you sure? delete/cancel" but still allows you to interact with the rest of the system, it's not modal.
I seriously can't say enough for this message. Adrian helped us redesign our app 2 years ago, dispatching many many modals in the process, and delivering a huge increase in usability that our customers and users very much do care about.