13

I need to notify the user under certain circumstances and have seen that confirm() and alert() shouldn't be used. Instead, a lot of questions mention using the modal thing in jQuery UI, especially if you need to style things. That's all fine and dandy, but, at the end of the day, what's the reason coders are saying you should stay away from it?

This is a pretty good example of how people feel, but pretty much any other question dealing with styling an alert box has the same comments. Is it only a styling issue or are there more fundamental reasons to shy away from this built-in functionality?

More importantly, none of the answers talk about what you ought to use instead. Are jQuery UI and similarly pre-built solutions simply the only answer? Why? Is it performance or security or inexperienced coders who need something easy to use or...?

Edit:

Okay, so let me clarify a bit. The reason I'm asking is because the alert functionality is to prevent a user from accidentally wiping out the work they've been doing since there are three ways to start a new plan on this page and each wipes out the existing inner html for the div where the plan is displayed.

Most of what I'm hearing is that it's bad for users and UI, but, if the anger-inducing, attention grabbing is what I want, what should I use instead? Someone mentioned that alerts / confirms halt JavaScript execution and may prevent you from using other tabs. That's closer to the functionality problems I'm expecting. I do understand that it's bad for UI, but I'm looking for more technical reasons here.

Community
  • 1
  • 1
Drew
  • 272
  • 1
  • 3
  • 15
  • 6
    See http://programmers.stackexchange.com/questions/106031/javascripts-prompt-confirm-and-alert-considered-old-fashioned/106039#106039 and http://ux.stackexchange.com/questions/12884/decline-in-javascript-prompt-usage – JJJ Dec 03 '13 at 19:25
  • 2
    Try this link: http://stackoverflow.com/questions/8825384/alert-is-bad-really – jpodwys Dec 03 '13 at 19:25
  • That was astoundingly quick. Thanks, guys, I'll take a look at those right now. – Drew Dec 03 '13 at 19:26
  • 1
    It is perhaps worth noting that Stack Overflow itself uses a browser-native `confirm` when prompting for delete confirmation. It's really ugly (compared to, e.g., the closing and flagging dialogs), but maybe its visual starkness is really a feature? – apsillers Dec 03 '13 at 19:28
  • Alert boxes are the EULA of the internet in that they all look the same and they take up more time than they are measurably worth within .0125 seconds of seeing them. User will simply become **NUMB** and will click "OK" just to get it out of the way as fast as possible. – MonkeyZeus Dec 03 '13 at 19:30
  • 3
    If you aren't using it for debugging, it's just informational, and you're ok with it being ugly, by all means, use it. It's there, it's simple, it's cross browser, and it won't break. Using confirm() when deleting records is standard. Doing the same with a modal dialog adds unneeded complexity. – Kevin B Dec 03 '13 at 19:32
  • @apsillers in this case, that's actually what I was going to use it for and ALL I was going to use it for. "You're trying to undo all the progress you were just working on, ya sure?" Zeus, I completely agree, but why not use it if it's sparing and forces the user to pay attention? – Drew Dec 03 '13 at 19:32
  • This question appears to be off-topic because it is about user experience best practices, not about any specific software problem. – citizen conn Dec 04 '13 at 00:10

4 Answers4

14

There are no "technical reasons" that you should not be using the built-in browser methods for alert and confirm functionality. It's all opinionated.

lets split this into two parts.

Alerts should never be used for debugging unless you intend for it to stop the execution of the code for a purpose. Otherwise, you should be using console.log because alert can actually change the result of your code if your code involves asynchronous logic. "But console.log isnt supported in IE!" Yes it is, if the console is open. In production code your debugging code should not be there anyway. To protect against forgotten console.logs, simply polyfil it. For uses other than debugging, such as informing the user that something happened, it's generally better to use some other way of informing the user that a change happened such as highlighting an element or a banner with informational text, however, there's nothing wrong with using an alert in that case as long as the pause in execution won't impact your code.

Confirm is the standard way of asking a user "Are you sure?" before performing a damaging action such as deleting information. It's easy to understand and is used by many sites, so i'd suggest using it within your own code as well. The alternative will generally result in a extra code adding unneeded complexity to your application. Keep in mind, however, confirm also blocks execution, so you should make sure that it won't affect any asynchronous logic that you may have running.

If your asynchronous code is written correctly, it generally won't be impacted by a pause in execution.

Kevin B
  • 94,570
  • 16
  • 163
  • 180
  • 3
    Alert is particularly useful for debugging something that will cause the page to refresh or redirect because it won't go away and the page won't redirect until you click ok. Of course, the console has tools to solve that too in some browsers. – Kevin B Dec 03 '13 at 19:56
  • Very true! And from what I've been reading online, that was essentially what I was getting, but I couldn't find anywhere to confirm it. Thanks! In my case, this isn't true, but let's assume for a moment that you didn't want to halt execution, what would you want to use instead? I think jQuery UI creates a div overlay for the screen instead, why might that be preferred? – Drew Dec 03 '13 at 19:56
  • 1
    The overlay forces the user to interact with the dialog in the same way the alert pauses execution to force the user to interact with the alert. – Kevin B Dec 03 '13 at 19:58
  • So, essentially, if I want to prevent the user from deleting data, anything that halts execution will be pretty similar and I should do the one they'll notice quickly, but hate the least? – Drew Dec 03 '13 at 19:59
  • Or, the one that will require the least maintenance from you if your designer decides to redesign the page, or if functionality needs to change, :) Both solutions work, it's up to you, the developer, to decide at that point. (or the designer depending on how things work in your office/department) – Kevin B Dec 03 '13 at 20:01
  • Fair enough. That answers pretty much all of my questions as much as possible, though the first two comments on my post had really awesome resources, too. Thanks! – Drew Dec 03 '13 at 20:03
1

Alert blocks JS execution. It's ugly. It is limited in functionality.

It's much better use use a modal dialog and callbacks to handle the user's choice. There are many libraries that do a good job of this.

Diodeus - James MacFarlane
  • 112,730
  • 33
  • 157
  • 176
  • Okay, but why? That answers a part of the question, but why / how does the alert block JS execution when things like a modal dialog box and callbacks don't? – Drew Dec 03 '13 at 19:28
  • 4
    To play devil's advocate, blocking js execution can at times be desired. – James Montagne Dec 03 '13 at 19:30
  • And, as I added to the edit above, that's actually true in this case. – Drew Dec 03 '13 at 19:50
0

Think about it from a design standpoint. End users hate popups, and prompts/alerts/confirms are very "spam" like in nature (abused as such). Modal windows are more "gentle" (as my professor used to say), customizable, and more stylish than an alert.

Not to mention too many popups could trigger the "Check here to disable alerts from this website" some browsers offer.

Sterling Archer
  • 22,070
  • 18
  • 81
  • 118
  • True, and I understand that. If this were customer facing and used more than once every 5-6 months, it'd be far easier to justify spending a ton of time on the UI. I was more trying to figure out where their hatred was coming from. Do you think it's primarily because of this? – Drew Dec 03 '13 at 19:27
  • 4
    I think it's primarily because so many developers incorrectly use it for debugging, resulting in false positives such as thinking an alert is required to make an ajax request work, when in fact it doesn't work because their logic is wrong. – Kevin B Dec 03 '13 at 19:29
0

Here are some reasons why you should not use alerts in your code:

  • As you said, a lot alert boxes may annoy the users
  • Styling of alert boxes is as far as I know impossible. Furthermore every browser displays them diffrent, which may not look good in all cases with your website-design
  • Most modern / common browsers block alerts after a site tried to display a few of them, to prevent alert spamming

You can use jQuery UI dialogs as an alternative, or anything else that is able to display modal dialogs. That way you can customize / style the dialog box and browsers don't block them.

I generally use alert boxes only for debugging / error reporting, not more.

RononDex
  • 4,143
  • 22
  • 39
  • 1
    *"I generally use alert boxes only for debugging / error reporting, not more."* that's the only place you should NOT use them in my opinion. – Kevin B Dec 03 '13 at 19:36
  • why? So you are telling me that you use the alerts everywhere else? The only places I am placing an alert is inside error event of ajax request, and don't only if there is no jquery loaded that can display the error message using the built in error style. – RononDex Dec 03 '13 at 19:38
  • 2
    Use console.log() instead, much faster debugging. Alerts for debugging is very bad practice IMO – Sterling Archer Dec 03 '13 at 19:49
  • guys ... just use debugger; please. – Jeremie Ges Dec 29 '16 at 03:43