Ready for implementation
Magnolia informs the user, if an action he started caused an error or requires him to read a warning or other textual message. It is especially important that error messages of long running actions aren't missed. If the users has left his desk, he should either see all messages when he returns or find a notification informing him that he should consult the message log, since new important messages have arrived during his absence.
All messages should be non-technical and easy to understand. It shall be easy to copy&paste them if he intends to contact product support. For the same reason, it must be easy to send the entire message log to support over a secure channel.
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, but should also be used scarcely. Second, the context of a system message is usually gone once it's being shown. As an example, a process running a longer time might fail eventually, or a regular background 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 explicitly 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 and informational messages don't show up in the center but at one of the borders of the central view area. They show up and may be dismissed, but they don't have to - they automatically disappear after a short delay. The difference between warning and informational message is that warning messages show up more colorful to get your attention and also light up a system messages icon indicating new messages (see #Dealing with multiple messages below).
Status messages are potentially displayed more often, since they notify the user of changes related to a typical work flow: 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 almost unnoticeable and disappear quickly. It must be possible to turn of status messages.
Dealing with multiple messages
If a user is not at her desk or if multiple messages appear at once, an error message or warning message might go unnoticed. The rule is that only the last message of a particular type stays. As an example, think of an activation error on a screen and another message coming in notifying the user that the public instance has gone down due to an error - since the second message covers the first, the first is dismissed and might go unnoticed.
So even for error messages, only the last message will always be visible - all the others are auto-dismissed. In order to avoid that warnings and errors are missed, not dismissed messages cause the system messages icon to light up. The color of this icon shall indicate the highest level of message waiting to be confirmed and a badge shall show the total number of errors and warnings which need to be read.
The list of system messages is accessible from the notifications section of the meta menu. A click on the corresponding item opens the list, which shows all messages of type error, warning and informational - status messages do not show up on any list.
Error messages still have to be confirmed either one at a time by checking them off in the list or by using a convenient button at the top confirming all messages. Warning messages are considered read if the message list has been opened.