views:

1008

answers:

8

We all know that alerts are bad. If you didn't know it read this

Alerts are used to communicate with the user. So if we don't use them what is a good alternative?

I'd like to get a nice list of good alternatives to choose from when implementing something that requires user communications.

I'll give one myself as an example and for everyone to use:

Case: we need to validate user input before we can proceed.

Solution: instead of showing an alert box when user clicks ok/next/submit show a clearly styled (eg. red on a white bg) "frame" around/next to the user input that has the invalid input with an informative text on what is wrong. To make it easier on the user the input in question should gain focus and if necessary moved back into view.

+1  A: 

Many alert boxes, and all the ones that annoy me, are basically covering up shortcomings of the underlying program.

It usually boils down to i.s.o. providing proper undo support, an "Are you sure?" alert box is thrown in.

In short, make everything as forgiving (undoable) as possible, an most of the alert boxes you wanted to add won't be needed anymore.

Pieter
what about a web application where logging out would obviously have to clear the undo history? How would you communicate this to the user?
Gene
A: 

I quite like ASP.NET's validator controls end result (although they are a bitch to actually use). Work in a similar way to what you describe, placing a star next to the input with an optional message or summary of messages displayed on the page rather than the in your face alert way.

I'd always go for keeping your messages in the page/form if possible. Time scales may dictate otherwise.

Rob Stevenson-Leggett
A: 

A status bar message and color/text/item-flashing changes to indicate problems similar to @Rob's example with ASP.NET. And a multi-level undo/redo system is best.

kenny
+1  A: 

I think the most important thing is to have useful messages in plain (layman-readable) language. "Do you want to tech the tech tech" is not helpful.

Also, make your messages match the style of the rest of the application, and look different from every other box that impedes the user's productivity. This goes against the usual rule of making your application look familiar to the user, but if you want them to read the message, it has to look different.

If you can avoid using a modal dialog box, do so. This will make the times that you need to use one seem more important.

Always bring focus to the item that needs attention, when appropriate. For example, if you are doing some sort of field validation, give focus to the offending field.

pkaeding
I agree. But the point is that what I write in the alert box (should I ever use on) doesn't matter. A long history of poor usage of alerts/erros boxes has thought the users to ignore them. The content is never read in the first place.
Gene
Yes, that's what I was trying to get at in the second paragraph. I wouldn't use traditional alert boxes, I would create my own modal dialog. In the realm of web design, where I am most familiar, I might create an absolutely positioned div on top of the main content with a lightbox mechanism.
pkaeding
A: 

I'm not a huge fan of alert boxes, primarily because they do tend to mar the application's usability. As Alan Cooper said in About Face, it's tantamount to conking the user on the head and calling him/her an idiot.

Notification of bad data, on the other hand, is a critical need in an app. First and foremost, in my mind, you should attempt to prevent bad data from being entered whenever humanly possible. There are a variety of third party control toolkits for most platforms (ASP.NET, .NET WinForms, WPF, Java Swing, JSP, etc.) which will help with this. (Although it's not popular around these parts, I actually have grown partial to Infragistics NetAdvantage.)

Depending on your platform choice, you have many UI notification possibilities. Some have been mentioned: Using the status bar of your app, indicating an issue on the field itself, etc.

I'm a .NET guy, so obviously my input here will be flavored by the environment.

I'm a huge fan, on the web, of the validation controls. They provide a lot of the notification, without too intrusive a UI. Combining a simple Text property of *, a detailed ErrorMessage property and a well-placing and visually obvious ValidationSummary, I get all the validation with almost none of the user nightmares. These controls, for those not on .NET, perform a variety of validations against the entered data, and display their Text properties wherever the control is on the page (usually next to the control being validated). The ErrorMessage property goes in the one ValidationSummary, usually located at the top of the page.

In the WinForms environment, I've taken to using a combination of the in-box ErrorProvider control and Infragistics' Outlook-style pop-up boxes. In my most recent WinForms app, I use two different kinds of pop-ups: One is semi-translucent, and appears in the lower-right corner. It has a green check mark icon, and exists to notify the user of success messages. (My users don't trust computers; if they don't see some confirmation, they think the machine ate their data. Long story.) These boxes disappear in seven seconds, or the user may close them manually.

The second kind of pop-up has no translucency, a red X icon, and appears in the upper right. That's where I display validation errors. Additionally, the ErrorProvider control displays an icon next to each field where validation failed, and hovering the mouse over a given control displays its specific error message. (These specific messages are also in the pop-up.) The error pop-ups disappear after fifteen seconds.

About the only modal alert boxes I use in that app are when it crashes (truly unhandled exceptions; which are currently near-impossible to do) and when the user wants to close a dirty window.

These are some of the techniques I've used to avoid alert boxes. The user can ignore confirmation messages (making their lives easier), and are not modally bothered by validation errors -- they can't save their data until those are fixed, but they're not being conked on the head. And of course, whenever possible, I prevent the validation errors by using appropriately-masked controls which do not allow invalid entry.

John Rudy
+4  A: 

Here’s the hierarchy for dealing with user errors or warnings, applied to validating user input to a field.

  1. Remove the element that may result in an error. Do you really need the user’s birth date? Can you get by just as well with something else that won’t require validation, such as option buttons for “Under 18 years old,” and “18 or over”?

  2. Prevent the error. Make it impossible to enter invalid input in the first place. For example, use a dropdown list, or “picture” the field, refusing any unacceptable characters (e.g., letters for a phone number).

  3. Accept the input and possibly correct it automatically and echoing the result back to the user. Make something out of the input. If the user types 4--14#008 for a date, auto-correct it to be April 14 2008. If the format doesn’t match a version number, check if it’s a Release Number and lookup the corresponding Version number. If it doesn’t fit your idea of a valid address, well, just assume that it is (maybe it’s for a foreign country). Does it really matter if the user’s birth date mangled?

  4. Provide Undo, not verification, showing clearly the implications of what the user did and providing a clear path to reverse it. When the user enters the number of stock shares to trade, show the dollar value beside it, in case the user confused shares with dollars. Keep the fields editable so the user can fix it.

  5. Provide warning and error text in the primary window or web page itself; text should be apparent without being disorienting, non-modal, and disappear automatically when the error is corrected. When a unrecognized date is entered, underline it in red and put text beside it saying “unrecognized date,” perhaps including a Help link for more information.

  6. Modal message box.

Michael Zuschlag
+1  A: 
OscarRyz
A: 

Joel Spolsky advocated for adding more popup boxes to tell the user why they can't perform an action instead of disabling the action (menu, button, link) in the first place. So I guess that disabling actions that users aren't supposed to do is a good way to get rid of a whole slew of popups.

Mike Hall
A long time ago MacOS had this by showing tooltip popups for disabled items explaining why. For tech reasons this was removed on MacOSX and later forgotten to implement again.
Lothar