Placement of flash/growl notifications or messages in web application

Question

Question

I have been wading through tons of questions on the topic of flash/growl notifications, but none of them touch on where those notifications should be placed and why they should be placed there!

Where is best for the user to take notice of notifications? Where is best for us to display the notifications, but not interrupt the rest of our web app? Should the notifications be inline or fixed?

First, let me clarify the type of notifications I am and am not referencing:

• I am not referencing form validation summaries or specific form input errors.

• I am referencing notifications that inform a user of the system's status (heuristic #1 on http://www.nngroup.com/articles/ten-usability-heuristics/). These notifications are not related to anything on the screen, so do not belong near a certain element.

So for instance, after a user edits an item and clicks to Save it, the page forwards back to the list of items, and a notification should appear letting the user know that the Save actually occurred. Or, let's say our web app is polling to see if the user has messages. If the user receives a message, a notification should appear that says so.

Now that I have described the kind of notifications I am referencing, where should those go? Are there principles involved that govern where those should go? I've seen some notifications interrupt the flow of the page, some fixed at the top of the screen, some fixed at the bottom, and some fixed at the bottom left.

Visual Samples

1. Inline, interrupting page flow

   

2. Fixed, top center

   

3. Fixed, bottom center

   

4. Fixed, bottom left

   

Observations

1. I don't really like the notification interrupting the flow of the page. It seems out of place and unnecessarily distracting.

2. From what I've read, notifications in operating systems often appear at the top of the screen, so users may be used to this. But it will block our top header, which isn't great. I'm thinking these notifications aren't important enough to block interaction with our web app.

3. I'm fairly familiar with notifications at the bottom center. I'm not sure where that came from, but it makes sense to me for them to be there. They are much more "out of the way" down there.

4. And lastly, I'm also very used to notifications at the bottom left. Facebook is one example of a web app that positions notifications here.

Answer 1

Jakob Nielsen’s F-Shaped Pattern For Reading Web Content references an important tendency of users when reading websites:

Users first read in a horizontal movement, usually across the upper part of the content area. This initial element forms the F's top bar.

You want your user to see the notification, so the top area of the page within that top bar of the F is ideal. Placing the notification anywhere else means it will be less likely to be seen.

Many popular web apps place their notifications on user performed actions in this area of the page:

Gmail

Twitter

SB Nation

Less important notifications (e.g. not related to feedback on user actions) can be placed elsewhere. Your mention of Growl is a good example of this as are the notifications in Facebook when users like/comment on posts you have had activity in:

Answer 2

We might want to distinct between several types of messages that got confused here:

1. feedback messages in response to user actions, e.g. "form saved"
2. unprovoked events, e.g. "new e-mail", "license expired", etc.
3. system status, e.g. "idle", "processing", "process complete", etc.

Each of these have its own conditions and best-practice solutions.

1. Feedback Messages

In many occasions you want to notify the user about the results of a certain task she explicitly asked the system to preform. Then you would want to notify through an explicit feedback message, preferably showing it in proximity to the place that the user asked for the task. For example, if the user clicked "Save", then showing a feedback message "form saved" next or under the button would be good, since the user's attention is near that button (assuming the save is rapid). This would be the case of a web app response to the click of a "Save" button, or a successful login process (see example below, with thanks to Matthew Moore).

2.Unprovoked events

The second type is notifications on events that were not provoked by the user or the system. The most prominent case is the "you have a new message in the Inbox", but it includes other types of events, like new software updates or hardware events (e.g. "battery running low"). If you believe it's important enough to steal the user's attention, you would present a new element on the screen. Facebook has its notifications pop-up on the bottom left. Windows and Outlook place them on the bottom right. Don't know why this is, but these bubbles get noticed more on the bottom (perhaps because this area is less interesting and out of the focus of attention, so that any change there is immediately noticeable).

3. System Status

Many times the system is built in a way that it is always in one state or another. For instance "idle" vs. "processing". It is the best practice to have a fixed indicator on the screen that indicates the current state. In the case of saving a document, a fine example would be Google Docs, where the header reads "Document Saved" (see screenshot below). When you type something, it changes to "saving...", letting you know it went into that particular state. There is no need for an obtrusive message in a new element on the screen after every few keyboard hits. The user hasn't specifically asked to save, its just the system letting the user understand in what state it is currently in.

Another nice example is Outlook, that tells you when it is "online" and connected to the exchange server, so you know e-mails arrive immediately and with no need to periodically send/receive. Again, as Outlook connects to the server automatically without the user asking for it, it would not make sense telling that in a new message. Just let the indicator communicate the current state.

It don't matter too much where these state indicators are located, as long as they have a fixed place. Google placed them on the top, and Microsoft have led a long tradition of placing them at the bottom, in an element suitably known as the "status bar".

To conclude, the place of your message deeply depends on the type of message and its dynamics. For more details, I strongly advise to read the great and thorough guide on messages from Microsoft. Personally, it made a lot of sense and taught me a lot.