The 1990's called! Please return its cascading message boxes!
Alerting system are extremely complex and difficult to get right. They require subtlety in one case, while demanding you slap the user in the face the next. If you fail to get it right you either cry wolf every time (your current design is doing this) or hide them in the corner.
You should spend significant resources in analyzing your users' needs for errors and how to best design them. There is no catch-all for alerting; you need to know how your users and their work flows to do right for them.
Better alternatives to display too many Popup/Alert message
Your title tells you your first problem. You have too many alert messages!
What really demands an alert? What is truly so important that the user needs to be interpreted so aggressively?
You may need an audit of your alerts to find out what you really need to be alerting about.
The events may or may not be related to the user's current activity.
If I am working on 'Task A' and something concerning a completely unrelated my current task pops up, what do I do? Do I just confirm it and keep working or do I have to go deal with it?
Your alert presentation implies to me that the alerts are pointless to my current task. When I have 10 alerts I'm clicking "ok" 10 times on completely unrelated items -- there is no way I'm going to be remembering what they all say. With 10 alerts on my screen I have to deal with them to get them off my screen, I'm more concerning with getting them out of my way than readying them.
I think you'll find that a lot of users are just confirming dialogs without reading them.
We want user to acknowledge each alert individually.
Why? Are they so important that they demand you interrupt the user's work flow to have them press an "ok" button on something that possibly has nothing to do with what they're doing?
Is the wing of the plane about to fall off? Yeah, that needs to be dealt with!
Is there an issue I should know about, and deal with... eventually? I don't need to be slapped in the face for that.
The current implementation we have is to display a top most non-modal Dialog whenever an event has occurred.
While your code calls it "non-modal", your users call it obtrusive. These are not non-modal dialogs, you are demanding that the user deal with them now in one manner or another. Your user has two choices:
- Acknowledge it.
- Move it out of the way so they can keep working... so why not just acknowledge it.
There is no way your user can ignore it and keep working. It is a modal alert box to them, regardless of your code calls it that.
If the user can hide an alert behind the main window there is even more reason not to use a dialog. Just put it in a place the user can deal with it when they are ready.
And, If there are multiple events that need to be acknowledged by the user then all these top most Dialogs will be cascaded (refer to the below mock-up).
Your alerts are holding your users hostage!
You are not allowing your user to complete their task, you're forcing them to click the "ok" button.
One other alternative we came up with is to have a Window for each Alert Type (We may have a maximum of 5 Alert types) and display all the alerts of that type as Cascaded panels in that window.
Let's look at this:
download bmml source – Wireframes created with Balsamiq Mockups
What is the user working on? I don't know... and your user probably doesn't know either, because you've totally removed them from their work flow and forced them to become a confirmation robot.
Are any other better alternatives to present these alerts?
First, as I mentioned above, you need to really examine your user work flows and understand why you should interrupt them (forcing them to confirm an alert) and when to do it.
Once you know how important the alerts really are you can start to find an appropriate place and an appropriate presentation. Not all alerts necessarily demand the same amount of attention, so your application might have different alert styles.
Notification Area
Look at web apps like Gmail that provide a notification area:
Clicking on the notification icon simply lists out the alerts. The user can dismiss the ones the want to, but perhaps keep others around to remind them to go do something!
download bmml source
When I have something that I should take note of the bell icon shows a badge, telling me how many alerts I have (I don't have any right now, so it's blank).
If your alerts do not demand action, don't force action. Let the user complete there current task and then address the alerts when they are able to deal with the issue those alerts are telling them about.
Alert Popups
download bmml source
There are certain things that might demand immediate action! Use a popup for it, but make sure that the user needs to be interrupted by it!
Alert Bar
If you need a little more insight into the alerts than a notification area, but don't need to slap the user in the face, perhaps something along the lines of an alert bar would work:
download bmml source
At an appropriate place in your application (not necessarily the bottom) you could show the latest alert for each of your five types. Clicking on the alert may bring up a list of other alerts, similar to the notification area, or just confirms that latest and shows the next (if one exists). The appropriate logic is something you need to discover for your use cases.
The bar is not in the users way, but gives a clear view into the state of alerts on the system.
Again, you need to work with your users and really understand why & when you should showing an alert. Don't force the user out of their work flow unless they have to be forced out! Don't cry wolf everything time. Figure out why you have so many alerts in the first place (and how to reduce them)!
