Notifiers

Usage

Notifiers are unobtrusive alerts that provide a short feedback message. Notifiers can be either Zywave system generated or user-initiated.

Notifiers should be used to:

• provide general information about the current process
• alert and inform about something that happened in the system
• inform about server-side issues or errors
• provide a timely alert that does not interfere with the current workflow

For more information on when a Notifier is the appropriate delivery component, see messages.

Anatomy

Notifiers consist of an opaque background, drop shadow, icon, text, and close button to dismiss the message.

• Top bar: Defines the type of Notifier by color: info (blue), success (green), error (red).
• Icon: Defines the type of Notifier by an icon: info, success, error.
• Header: Briefly describes the message to the user. The header should be H3 and remain on one line, with a max-width of 50 characters.
• Body text: Provides supporting content for the header. The body text should be kept straightforward and span no longer than 3 lines.
• Action (optional): A single action associated with the message, such as 'View details.'
• Close: A close button allows the user to dismiss the message.

For detailed documentation on our Notifier anatomy, view the ZUI Notifier design specs.

Types

The three types of available Notifier types are identified by the different colors and icons. These identifying features allow someone to know, at a glance, the type and importance of the message contained within.

Info Notifier

Used to provide general information about the product or current process.

Success Notifier

Used to provide information that an action or workflow has been completed successfully.

Error Notifier

Used to alert the user of server-side issues or errors or that an error was encountered while performing an action or workflow.

Behavior

Positioning

Notifiers are anchored to the top right of the viewport above all other content in z-space, including Dialogs.

Timing

By default, Notifiers will be on a timer and disappear on their own without the need for interaction. The Notifier must also include a close button in the upper right corner for manual dismissal of the message. When a Notifier includes an action, timing should be disabled to prevent the message from disappearing before the action can be clicked or tapped.

The timer should be used in cases where the Notifier includes non-crucial information, for example:

• when there is general information about the product or current process, such as syncing, that does not require the user to take action.
• when there is an action or workflow that has been completed successfully, such as the user successfully adding an account.

The timer should not be used in cases where the Notifier includes an action or error, for example:

• when there is an action that the user may choose to explore, such as viewing details on an imported file.
• when the Notifier contains an error message

The default length of time a Notifier will remain on the screen after animating in is 5 seconds. This time can be adjusted based on the length of the message. We recommend not reducing the time for shorter messages, but longer messages can be extended — an additional 1 second for every 120 characters is a good rule of thumb.

Animation

Notifiers slide up and fade in as they appear on the screen, and slide down and fade out as they disappear.

Responsive layout

While the behavior remains unchanged, the location of Notifiers is different on mobile devices with viewports smaller than 720px. The Notifiers on mobile devices should be pinned to the bottom of the screen to make it easier to dismiss while holding the device.

The responsive behavior for Notifiers is not yet available in the toolkit. You can track our progress
[here] (https://gitlab.com/zywave/devkit/zui/zui/-/issues/323).

Best practices

Actions

Notifiers can include a single action associated with the message. Notifier actions are styled similar to text links, but are the same color as the Notifier top bar.

Actions should only be used when there is more information associated with the message that may be explored further. When the action is pressed, the Notifier is dismissed and the user is routed to the correct location. Consider a different delivery method for required actions.

Examples of when actions could be used:

• In an informational Notifier about a new enhancement as a link for further information.
• In a success Notifier about a successful import as a link to view the import details.

If the action must remain visible to is required, a well or dialog may be the appropriate delivery component.

Multiple notifiers

When multiple Notifiers appear at one time on the screen, they should vertically stack so that all messages can be seen at once and further action can be taken if necessary.

There should not be more than three Notifiers on the screen at one time. A Notifier must be dismissed or allowed to time out before a new Notifier may appear.

Multiple Notifiers should be used sparingly and only be seen in certain circumstances, for example:

• multiple errors occurring on the same page.
• multiple notifications appearing from the same workflow.

Support for displaying multiple Notifiers is not yet available. You can track our progress here.

Alternate considerations

In the case of messaging:

• A well may be the appropriate component if the message needs moderate emphasis or an action should remain visible to the user without a timed dismissal.
• A dialog may be the appropriate component if the message needs high emphasis or a specific action the user must take.

In the case of errors:

• A banner well may be the appropriate component when a feature or resource error occurs, such as a 404 resource not found error.
• An error page may be the appropriate component when a critical system error occurs, such as a 500 internal server error.

For more information on when a Notifier is the appropriate delivery component, see messages.