An iPad application we are building throws an alert window for various error conditions. We are considering building a custom UI for the alerts since the default alert window is fairly annoying. My question is, how do you stack the alerts? For example if 2 parts of the app throw 2 different alerts, whats the best way to show that 2 things went wrong. One thought is to only show the first error that happened. Another is to show the alerts one after the other, so the user is made to click "ok" twice. Another is something like "2 things went wrong:here is 1 and here is another" but the problem there is error 2 may happen after error 1 but before the user has had an option to dismiss alert 1.

Has anyone seen any good UI pattern for grouping multiple alert messages?

6 Answers
6

-1: please provide some additional information aside from just posting a screenshot of something. What's good about this design? How does this example relate to the original question?
–
Rahul♦Aug 31 '10 at 7:28

Thanks. I think this makes most sense for a stackable notification system.
–
ArpitAug 31 '10 at 14:01

I provided the screen snapshots more as food for thought, and an idea. When displaying progress, I actually do not like this approach at all -- it's OK ONLY for displaying alerts. For handling progress, see my post on UX Exchange at uxexchange.com/questions/2716/…
–
HishamSep 1 '10 at 4:17

nobody likes alerts (that I know of), but for multiple asynchronous messages, a 'growl' interface thus far feels quite appealing. After reviewing several jQuery specific plugins for 'notification', I found the following pretty useful:

Does the error need to be shown in a popup or can it be shown in the flow of the app? Eg. is it an exception, or is it a notification? "The page could not be loaded" has a different significance and weight to something like "Retweet failed. Twitter didn't respond."

Thinking about those differences leads to a couple of thoughts:

If it's a critical error, you should break flow of the app and alert the user. "The page could not be loaded" needs to pop up because there's nothing else that can happen in parallel.

Non-critical errors, like "Retweet failed" in a twitter app, shouldn't break flow, as you'll interrupt the user's usage of the app, which is generally going to be something like reading or writing.

What is the user doing? If the user is performing some sequential task, eg. filling out a form, then show the user the different errors grouped together.

Consider designing your way out of the problem. For instance, don't treat the error as an error. In the "retweet" example, the twitter API is an external dependency and therefore any calls to it should be fault tolerant, including feedback to the user in the UI. This affects how the user perceives your app: if you always pop up an error whenever some exception happens, the user will perceive an unstable, annoying app that interrupts her. If you inline the errors and display them as unavoidable notifications that just happen because Twitter can be down sometimes, it will come across very differently.

Look at platform conventions for iPad. Refer to the Apple Human Interface Guidelines and look at leading apps. My experience with the iPad has been that there are very few error states in apps; this may be due to great testing, or due to the fact that the designers have designed possible error states out of the app. Consider this example: in a web form, if you ask for phone numbers in a certain specific format, you just introduced a possible error state where the user incorrectly fills in the phone number. However, if you just accept any format, that's one less problem for the user to worry about. I wonder sometimes whether iPad app designers lean towards that kind of design.

Sruly posted an answer while I was writing this and it looks very specific and technical. Hopefully my answer can contribute some high level food-for-thought.

Is able to automatically stack multiple alerts. The alerts can fade out after a second if it's not a severe alert. You can also create alerts that the user must dismiss. Growl is used in a large number of Mac programs, I don't know how popular Howl is.

Although you may not want to use Windows patterns for an Apple product.

A few patterns to consider. (From Windows)

The task bar notifier icons show one message at a time and when you close it or it times out another one shows.

Some messages stack with each subsequent message being moved a few pixels down and to the right.

Some messages (like an alert in JS) block until responded to so obviously there can only be one at a time.

Some messages (like the the windows system alerts for security risks) show in one box but with all the messages there are.

StackExchange sites put important notifications on top and less important ones may popup after you do an action.

Since I don't know exactly what you are building it is hard to make a suggestion but through a process of elimination I can narrow it down.

Since you have limited screen pixels grouping messages in one box could steal a lot of your screen space.

You probably don't want your application to block unless there is a critical error so JS style alerts are probably out.

Stacking non blocking popups wouldn't work again due to lack of screen space.

I think this leaves you with only a few options. A popup that doesn't block and fades or goes away when clicked (like the notification icon bubbles in the windows taksbar or the small notifications in StackExchange) or a notification area (like the top bar in StackExchange)

I would probably pop up a transparent street sign style alert and leave it in the top right or lower right corner.

Whenever an error occurs, you can display the symbol and then if another error occurs you can flash the alert a brighter color and add a counter next to it with the number of errors they have received. In addition to the symbol and counter, you might want a one or two word label. Something short and to the point would probably be best to save on real estate.

When the user pushes(clicks) the alert, it can pop out a box with their list of errors.