It's not only what you say but how you say it. Choose the right message type.
Messages inform users of events, specific conditions or system states that require attention. You can show message in three types: banners, alerts and notifications. Consider the context and persistence.
First, you can display messages in the immediate context where the user is working. Use notifications or alerts for context dependent messages. Notifications are non-blocking, they go away automatically and the user can safely ignore them. An alert blocks the user and requires a reaction.
Second, only banners are persisted messages. If you need to display something you really want the users to read, display a banner. The user can read it later in the Pulse.
ERRORmessages report a severe problem that has occurred.
WARNINGmessages warn the user that the system has detected a condition which requires the user's attention.
INFOmessages simply inform the user about a change or a situation.
WORKITEMis a special type reserved for workflow notifications.
Banners are messages that inform the user about system and app events. Banners are displayed prominently at the top or bottom of the Magnolia shell. They capture the user's attention effectively but do not interrupt what the user is currently working on. Banners are the only persistent message type. The user can safely close the banner and read the full message in the Pulse later. See Banners.
Example use: An info banner is displayed to an administrator that the license of a particular Magnolia instance is about to expire. (INFO message sent by the system)
Writing banner messages:
- Make the title and short description non-technical and easy to understand.
- By contrast, the message body can be as complex and technical as necessary.
- Cover the incident comprehensively.
- Provide enough context to make the message clear. Remember that messages can show up outside of the context they are created in. For example, a user editing a page may see an unrelated message that the license of the asset management connector he's using to access a SharePoint server will expire in five days.
Alerts are modal messages that show up in the context the user is currently working in. You can use alerts to confirm that an action should be executed, inform the user of harmful consequences, or report the progress of a long-running action. Since alerts are modal they block the user interface. See Alerts.
Example use: A Yes-No question is displayed in an alert, asking the user whether an action should proceed or not.
Writing alert messages:
- Text for alerts should be very short. We want them to be small and neat, and instantly comprehensible.
- If you ask questions, make them concise and snappy and ensure you use explicit labels on buttons that answer the question. For example, when you ask the user to confirm a deletion, labeling the buttons Yes, delete and No, with the latter being the default, instead of just OK and Cancel.
Notifications are non-intrusive messages that inform the user whether an action was completed or aborted successfully. Typically they confirm something. Notifications look like Post-IT notes. They go away automatically and don't require user action. Use notifications to confirm what the user did and provide them with confidence and assurance. See Notifications.
Example use: A notification tells the user that they have not completed a dialog. Some fields still need to be filled.
Writing notification messages:
- Text for notifications must be super short and to the point since it is only visible for a few seconds.