JavaScript's prompt, confirm and alert considered "old-fashioned" [closed]

Question

Lately I've been developing a web-based management system for a gym. Their previous app was developed in Visual Basic. For the new app, all the front-end scripting uses jQuery, the server is running PHP & MySQL... you know, the typical el-cheapo linux based stack.

Anyways, I was wondering why JavaScript's prompt, confirm and alert message dialogs are so underused nowadays. There a lot of jQuery plugins for modal windows and alert messages that try to mimic something that the language already offers and every browser is forced to support properly.

Using hand-made or plugin-based solutions is ok for complex forms and special needs, but if you just need to ask for a single value or confirm the deletion of a record, why would you add such overhead to your web app? Furthermore, iOS and Android offer nicely adapted message dialogs when you use prompt, confirm and alert.

Answer 1

1. UX: message boxes are mostly evil

Alert boxes are bad in all cases from the UX point of view. In desktop apps. In web apps as alerts or inline JavaScript messages. Everywhere.

You can read About Face 3 by Alan Cooper¹ if you want to know why; it explains very well how does this interrupt the workflow and annoys the user, and how nearly every alert box which exists in current software is deeply wrong. On page 542, "The dialog that cried “Wolf!”" explains that alert boxes are dismissed routinely, so their model is completely broken. On page 543 of the book are listed three major design principles:

• Do, don't ask.
• Make all actions reversible.
• Provide modeless feedback to help users avoid mistakes.

Then, the authors tell us how to replace the alert boxes by the correct design approach.

Prompt messages are slightly different. And still, they break the user experience of your app. If you want the user to enter something, consider using a textbox or a textarea, decorating it with JavaScript when need. Don't be lazy, provide a rich interface in an era of RIA and AJAX-enabled apps; in all cases, if JavaScript is disabled, your prompt will not be displayed.

In web pages, both alert boxes and prompts are mostly annoying. Some examples:

1. Some forums let you create lists by prompting infinitely for the list items. It means that while creating the list, you cannot use the page itself, including copy-paste. You also have a single tiny field. What about long text? What about bold and italics?

2. "If you continue, the photo will be removed definitively from your profile. Are you sure?". Of course I am sure! Would I click "Remove photo from my profile" otherwise? Why your web app supposing I'm so stupid? Actually, Google applications as GMail show the correct approach. You can remove, delete, destroy whatever you want, and when you do so, the app displays a small "Undo" link.

3. "Do you want to take our greatest survey?". Well, actually I was there to visit your website, but since you bother me with your annoying messages, I would rather go somewhere else.

4. "The right click is disabled on this website in order to protect copyrighted photos". Well, actually I right-clicked to change the language of spell checker before sending my comment. Sure, I'll send it without checking the spelling.

Conclusion: from user experience point of view, the applications use message boxes wrongly most of the time.

But wait! Many low-quality websites replace annoying alert boxes by annoying JQuery messages with a semi-transparent background which covers all the page. So the drawbacks remain.

Well, there are another reasons not to use message boxes in web applications :

2. Design: alert boxes have their own design

You can't design an alert box at all. You can't change its color, its size, its font. This makes it even more annoying for the user: you were working with a web app, and your workflow is broken by a message which seems to come from nowhere and does not even match the visual aspect of the app. Not counting that the language of the buttons also match the OS/browser language, not the web application one.

For designers, JavaScript messages are much more powerful than the alert boxes.

They are also much more extensive. You can add bold and italic, you can choose your own buttons (what about: "We apologize but the password you entered is invalid. [Reset my password] [Try another one] [Cancel]"?)².

3. JavaScript: application flow stops

When displaying an alert box, JavaScript stops executing until the user clicks. On a website, it might be ok. With a web app, it often becomes a problem.

4. Sandbox: don't force the user to reboot his computer

Remember the crappy websites which show you an infinite number of message boxes? The only way for the users without enough technical background to be able to continue working was in fact to reboot their computer. This brings us to a problem: alert boxes are out of the scope of the website or web application. You are not authorized to prevent the user from accessing other tabs of the browser³.

The same problem forced the browsers to solve it in different ways. Firefox, for example, permits the access to other tabs when displaying an alert on your tab. Chrome, on the other hand, allows you to check that you don't want to get any alert boxes from a page any-longer, but still blocks the access to other tabs.

While Firefox approach is perfectly valid, Chrome's one can be criticized (since it still blocks every tab), and causes a problem: what if the user was severely annoyed by several message boxes issued by your app and checked the case, and then, you tried to show something really important? Right, the user will never see it.

The fact remains the same, most users will be annoyed by alert boxes, so they are still not very user friendly, and may severely block a user with no enough technical background. Inline, JavaScript messages may block the page, but not the browser itself. Since web app model is a sort of sandboxing, where you can't for example access the user keyboard or reboot the computer or read files from hard disk or go full-screen or use two monitors, alert boxes with their blocking effect break severely this sandboxing model.

Last but not least, what if the user was on another tab when your application decided to show the alert box? What if the user was doing something important, and does not want to interact with your app right now?

---

^{¹ About Face 3, The Essentials of Interaction Design, Alan Cooper, Robert Reimann and David Cronin, ISBN 978-0-470-08411-3; Chapter 25: Errors, Alerts, and Confirmations.}

^{² This is just an example. Please, don't do it in your web applications, since it's really a poor design choice.}

^{³ If you want a comparison with the world of desktop apps, an inline JavaScript message is like a message box of a desktop application. An alert box in a browser, on the other hand, is like a window appearing from nowhere, set as topmost, on a full-screen opaque background which blocks you from accessing any other desktop application. Any app which will decide to do it once on my computer will be removed immediately, and forever.}

Answer 2

Bottom line: The default prompt, confirm and alert dialog boxes match the style of your browser, not the style of your site. Most UI people want all dialog boxes to flow with the UI of their site. They use modal windows to present messages and collect data using the same fonts and colors as the site's UI, not the default grey and blue of MSIE or FF.

Answer 3

You are only adding overhead if you don't need the fancy dialogs elsewhere, which you probably do. At that point it doesn't make much difference whether the functionality is included as part of the browser or as part of the framework you are using, and you may as well keep all your popups looking consistent.

While you can do a lot with javascript and no frameworks, I remember what it was like developing in javascript before the frameworks were available, and I wouldn't want to go back to it.

Answer 4

Because browsers don't handle them very well. As you may have noticed they are usually modal dialogs and not only prevent users from moving and resizing their browsers they also prevent other tabs from being accessed, which is very annoying.

For dialogs like confirm and alter I still think the browser should be enforcing the behaviour, and for the latest Firefox browser you can see they've fixed the problem I mentioned above. They use in page alerts that are scoped to the current page.

Therefore I suggest that you override the alert behaviour so that all browsers can handle (at least alerts) more elegantly.

A few summarised reasons:

• This is the standard API and developers can figure out what you’re trying to do.
• It’s more user friendly, and looks better.
• Platform support, mobile sites might need the native API.