You can show information to users in three basic types: banners, alerts and notifications.

Banners

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.

Behavior

  • Banners must be closed by the user. A banner stays on the page until the  user clicks it.
  • Not displayed modally. Does not interrupt what the user is currently working on.
  • Persistent. The message is stored in the messages workspace.
  • Only the title and an optional short description is displayed in the banner. Full message is in the Pulse.
  • Clicking the More button on the banner opens the message in Pulse. 
  • Banners can be displayed to the current user, a specific named user, a group of users, or broadcast to all users.

Levels

All message types have at least the following levels of urgency, as defined in MessageType:
  • ERROR messages report a severe problem that has occurred.
  • WARNING messages warn the user that the system has detected a condition which requires the user's attention.
  • INFO messages simply inform the user about a change or a situation.
  • WORKITEM is a special type reserved for workflow notifications.

Examples

  • An error captures an exception that occurred in an app and which was not foreseen. (ERROR message sent by an app)
  • A warning is sent since the license of a particular app is about to expire. (WARNING message sent by an app)
  • A warning is sent to an administrator that the license of a particular Magnolia instance is about to expire. (WARNING message sent by the system)
  • An administrator is informed that a new version of a particular app is available. (INFO message sent by an app)
  • An administrator sends an instance-wide message to all users that the instance will be taken down and restarted in an hour. (INFO message defined by and sent to all users by an admin app)

Looks like

INFO banner  WARNING banner  ERROR banner  Message list in Pulse  Full message text open in Pulse

How to show

See Showing banner messages

Alerts

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.

(warning) Do not use alerts to gather any user input. For quick input, use a light dialog instead. Light dialogs are meant to carry a small set of form fields and still resemble regular dialogs. For complex input, use a regular dialog. Dialogs should be used when presenting the forms for adjusting the page properties or the settings in the user profile. You might even want to use a wizard dialog, if you have to guide your user through multiple steps.

Behavior

  • Alerts are displayed in the context the user currently works in. They don't make much sense outside of context.
  • Transient. Alerts are not stored and thus they do not show up in Pulse.
  • Sent by apps, subapps or shell apps. Alerts often originate from a particular UI element within an app.
  • Modal. Alerts block the UI element they originate from.
  • Personal. Displayed only to the user who triggers the alert. Alerts cannot be sent to other users.
  • Don't collect user input with alerts. Simple button answers only: Yes/No, OK/Cancel.

Levels

All message types have at least the following levels of urgency, as defined in MessageType:
  • ERROR messages report a severe problem that has occurred.
  • WARNING messages warn the user that the system has detected a condition which requires the user's attention.
  • INFO messages simply inform the user about a change or a situation.
  • WORKITEM is a special type reserved for workflow notifications.

When to use

  • Yes-No question: an alert asks the user whether an action should proceed or not.
  • Confirmation: an alert informs the user of an important fact and requires that the user confirm it was read and understood.
  • Cancel confirmation: an alert confirms that an action was successfully aborted by the user and informs about the consequences.
  • Progress report: an alert reports the progress of a long-running action that needs to block the UI - or at least major parts of it.

Examples

  • A user deletes one or more contacts. An alert asks the user to confirm the deletion because it cannot be undone. (Yes-No question)
  • A user aborts a simultaneous publication of several pages. An alert confirms that the action was canceled and lists pages that were already activated as well as those that were not. (Cancel confirmation)
  • An alert asks the user to confirm a publication request. The same message allows the user to also publish all subitems as well by checking a box. (simple form + Yes-No question)

Looks like

WARNING alert

How to show

See Showing alerts

Notifications

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.

Behavior

  • Notify that an action was or currently is being executed. Notifications may also inform that an action failed to properly perform its task.
  • Displayed in the context the user currently works in. They don't make much sense outside of context.
  • Transient. Notifications are not stored and thus they do not show up in Pulse.
  • Sent by apps, subapps or shell apps.
  • Non-modal. Notifications don't block the UI and they go away automatically after 3 seconds.
  • Personal. Displayed only to the user who triggers the notification. Notifications cannot be sent to other users.
  • Don't collect user input with notifications. Just inform the user of changes.

Levels

All message types have at least the following levels of urgency, as defined in MessageType:
  • ERROR messages report a severe problem that has occurred.
  • WARNING messages warn the user that the system has detected a condition which requires the user's attention.
  • INFO messages simply inform the user about a change or a situation.
  • WORKITEM is a special type reserved for workflow notifications.

When to use

  • Success confirmation: a notification confirms that an action was executed successfully.
  • Cancel confirmation: a notification confirms that an action was successfully aborted by a user.
  • Progress report: a notification reports the progress of a long-running, non-blocking action.
  • Quick info: an notification reports that an event has occurred that affects what the user is currently working on.

Examples

  • A user publishes many pages at once. A notification reports on how far the publication has proceeded and how long it still takes to complete. (Progress report)
  • At the end of a long publication process, a notification confirms that all 20 pages were published successfully. (Success confirmation)
  • During an image upload, a notification signals the upload progress using a progress bar. (Progress report)
  • A user aborts an image upload. A notification confirms that the upload was canceled. (Cancel confirmation)
  • Another user has just started to edit the same item as you. A notification tells you are now working on the same content. (Quick info)

Looks like

INFO notification  WARNING notification  ERROR notification

How to show

See Showing notifications

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels