For our intranet application we have little notification messages (toasts) that indicate successful operations like "information saved," "logged out" etc. Most of them are not important enough to require a modal operation (like Stack Exchange's "click to close" windows) so they close automatically after 2500ms and I'm trying to make them disrupt the user as little as possible. They are however important to present as users need confirmation an action was successful as it may be part of a repetitive or complex workflow.
I want to make sure they're readable and understandable within the time frame so I was wondering if there was any research on how long it takes people to read information especially in a "pop up" style context. It's not actually a pop up window, more like SE's notification bar but it automatically goes away. If I could ballpark how long to expect reading to take it would help tune the duration of the message and the length of messages.
For what it's worth - I tried a variety of timings myself and ended up at 3200ms for a two line message of up to about 20 words. But I also place a small dot (10px diameter) to the left, which is coloured according to message type (eg red/error, blue/info, orange/warning) and which fades out over the 3200ms. When the fade gets to 100%, the message itself fades out quickly. Users said they like it because it makes the message slightly more noticeable without being too distracting and it made it less of a 'surprise' when the message disappears.
Generally the time taken to read a flash notice will vary according to the complexity of the information, length of notice, and focus/distraction level of the user.
That said, I tend to use the following informed approach:
1. Flash notices should be short
If a notice is longer than about 1.5 lines, it likely too long for an auto-dismiss. In these cases, re-examine the content and determine whether you want to show it modally (e.g. in a dialog which the user manually dismisses) or via screen change (e.g. take the user to a new page containing the information)
2. I generally use the following formula:
The correct formula is min(max(toast.message.length * 50, 2000), 7000)
This isn't an exact science, but it's worked for me and it's reasonably supported by ergonomic data...
Roughly, the logic is:
Show animation of 200-400ms is roughly consistent with the saccade time for the eye to refocus on a new place onscreen.
Show duration of 50ms x # of characters is roughly consistent with user reading speed. The average English language reader will read about 250-300 words per minute, with an average of 5.8 characters per word (including spaces). At a "safe" estimate for a notice of 200wpm, that yields about 1 character every 50 milliseconds.
I apply a 2000ms minimum to allow the user time to congitively context-switch even for short notices, and a 7000ms maximum because I've found that tests about right for the threshold upon which the notice really should not be a flash-based notice (see point #1 above).
Fade animation of 700-2000ms. The fade animation is slower than the show animation because it gives times for users to finish reading or act (e.g. click to prevent dismissal) if they aren't done yet. Users feel very frustrated if they are halfway through reading something and it disappears suddenly before they can do anything about it.
You will have to adapt this to fit your specific situation, but the general framework may be helpful.
I'm surprised that no one has flagged this as an accessibility concern. I recommend that you avoid having timed messages at all because you can't determine how long it takes for someone to not only read the message but also understand it.
Recommendation: Include a "Dismiss" button to allow users to close the alert in their own time.
I would suggest that any auto-show-auto-hide notification should only contain a short phrase, or at most a short sentence. We use these little bubbles that slide in and back out after a user clicks a save button and it succeeds that simply say "saved." They show for about two and a half seconds and give the user the modeless feedback they need to know that clicking the button did something.
Now an error message where a users action failed to produce a result should probably be a little more prominent or require acknowledgement. I'm not saying make them modal but maybe make the user x it out or something. The same goes for a long message. If I am busy doing something in the application and a little pop out shows up I probably will look at it but only after I finish what I am doing. If its gone by the time I go to look at it I will probably not be very comforted by that.
On my client's intranet we're using 3 seconds for short confirmation and error messages, and around 5 seconds for longer messages (bearing in mind that longer cannot be that long).
What grabbed my attention though was what you said that you wanted the user to be as least disrupted as possible. On our intranet, on publishing forms for publishers, since they will be seeing confirmation messages a lot, we enabled that on clicking Esc the message will disappear immediately. As they tend to use keyboards and tabs when publishing, Esc will be optimal when they tab+click Save.
It always depends upon the number of words inside the notification. If the words ranges for 5 to 10, 3 seconds is enough and for the words ranges from 10 to 20 words, It will be better to have it visible for 5 seconds.
Some suggestions for showing 'Temporary notification window'
1. Time should be sufficient so that a normal person can read whole message.
2. Message should not go off when user is keeping his/her mouse pointer on that, it shows user is focusing on this.
3. When window gets disappear, it should be in fading kind of slow animation not abruptly.
4. message should be simply written in plain text and should be precise.