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.
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.