Story
Magnolia informs me adaquately, if an action I take causes an error or requires me to note a warning or other textual message. It is important to me that I especially don't miss error messages of long running actions, possibly launched in the background.
If I leave my desk and return, I should either still see all messages or have a notification waiting for me informing me that I need to take a look at a message log, since new messages arrived in my absense.
Last but not least, all messages should be non-technical and easy to understand. I should be able to copy&paste them if I need customer support. For the same reason, I'd also like to be able to send my current message log to support using a secure channel.
Description of desired behaviour
System messages differ from e.g. validation messages in a number of ways. First, they report important system status changes. As such, they have to be displayed more prominently. Because of this, they should also only be used scarcely. Second, the context of a system message is usually gone once it's being shown. A process running a longer-time might fail eventually or a regular cleanup job has discovered an oddity, which requires a warning to be displayed to the user. The message thus shows up in any context. By contrast, a validation message can still be visually related to the field, which caused the problem, when it is displayed.
We do define four types of system messages: error, warning, informational and status messages.
Error messages have to be explicitely acknowledged by closing the message box. They should appear bang right into your face and have to interrupt you with whatever you're doing now. Use errors as sparingly as possible.
Warning messages don't show up in the center but at a border. They show up and may be dismissed, but they don't have to - they disappear after a short delay. The difference between warning and informational message is that warning messages show up with a brighter color to get your attention and also light up the message icon indicating new messages if they weren't manually dismissed.
Status messages are potentially displayed more often, since they notify the user of changes related to a typical workflow: new work items have appeared in the inbox, a user you've waited for has logged in, new content was published by someone else, a user has written you an internal message. Since they're more obtrusive, the visual appearance of status messages must be a lot more decent: they show up in a corner of the screen only, should be small and disappear again quickly.
Dealing with multiple messages
If a user is not at her desk or if mulitple messages appear at once, an error message or warning message might go unnoticed. Think of an activation error on a screen and another message coming in notifying the user that the public instance has gone down to an error - since the second message covers the first, the first might go unnoticed.
The rule is that only the last message of a particular type stays. So even for error messages, only the last message will always be visible - all others are auto-dismissed. In order to avoid that warnings and errors are missed, undismissed messages cause the message icon to light up. The color of the icon shall indicate the highest level of message waiting to be confirmed and a badge shows the total number of errors and warnings which need to be confirmed.
Messages list
A click on the messages icon shows the list of messages. All messages of type error, warning and informational show up - status messages do not show up on any list. Note that error messages still have to be confirmed, either one at a time in the list or using a convenient button at the top confirming all messages.