I’m doing some research on best practices for error messages, warning and confirmation messages for web applications.
Right now I’m making a list of all the shapes these messages can take in an interface.
I’ve come up with 5 approaches and I’m thinking about where/when they’re appropriate, for which types of messages and scenarios, and how they might not be a good idea sometimes.
here is my list so far:
1) the notification area used accross the app, always in the same part of the interface, usually somewhere at the top. Here is an example.
2) contextual messages, for instance next to a form field that’s causing the problem (see this article)
3) modal windows
4) browser dialog boxes
5) growl type of message : they pop up in one area of the screen (as opposed to an area of the interface), hence overlaying some of the interface. They either pop up and dissapear by themselves or they wait for the user to close them. Example here.
My questions are :
- have you identified other forms of notifications?
- do you know any good online resources about this topic?
- how do you personally feel about browser dialog boxes in web apps? I find them terribly annoying most of the time, and I wonder if it’s just me
Thanks in advance for your thoughts
To start with, good work and a nice research. Have some questions first up :
By growl type of message, you say that some part of the interface is overlayed right? Does overlay mean that no further operation can be done with that part of the interface ?
Are modal window and growl type similar? If not what is the difference between them ? Is it possible to show me an example of the modal window type?
Coming to the browser dialog boxes, I assume it is the ‘alerts’ that come up. And I agree with totally in your saying that they are particularly very annoying.
I guess the big difference between growl-like messages and modal windows is that in the first case one’s able to ignore the message and carry out some other task, whereas a modal window is usually more “in your face” : it’s often displayed in the middle of the screen with the rest of the interface greyed out.
Some modal windows let you interact with the rest of the interface but I think that’s fairly rare.
In both cases, the notification may overlap some of the content of the page.
The method I use is basically like the example in 1). I have three types of event:
- Positive (Green): Events where the user has successfully completed something like the successful sending of a pm, deletion of a pm, etc.
- Neutral (Orange): Events that are neutral in nature, not used very much, mainly for things like notification of unread PMs, etc.
- Negative (Red): Events where a user action has failed, like errors when sending PMs, etc.
When it gets nearer ready to go online I’ll look for relevant icons for each of the three. For errors with forms I’ll possibly also change the colour of field names where there is a problem to red.
Whatever colour scheme you choose to use, make sure that it is readable/legible on a variety of monitors/screen resolutions.
SpacePhoenix, I agree with you on these basic principles : colours that make sense, readability etc.
In the web app I’m working on, we might need the user to get confirmation or error messages after they’ve scrolled down the page. In that case, it’s not great if the area used for such messages is always in the header area, for instance.
That’s why I started to look into other ways of displaying notifications so that it’s always visible but not too intrusive like modal windows or alert boxes. These can be fine to use in some cases but definitely not all the time.
I like Growl-like notifications but I’ve noticed that I don’t read them if they show up in a corner a the bottom, so that’s a bit of a problem. I wouldn’t want them to pop up in the top right or left corner of my app because it would overlap important elements most of the time.
It’s quite tricky…