Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notification usage updates #1081

Merged
Merged
Show file tree
Hide file tree
Changes from 21 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
b8d4871
Docs: notification guidance updates
jillianhowarth Mar 4, 2020
e3932ee
docs: guidance updates
jillianhowarth Mar 24, 2020
8daaa21
Docs: final updates
jillianhowarth Apr 2, 2020
ee17191
Docs: image fix
jillianhowarth Apr 2, 2020
8d7a517
Merge branch 'master' into notification-usage-updates
tw15egan Apr 2, 2020
602b3d4
Docs: structure updates
jillianhowarth Apr 7, 2020
e3b12b5
Merge branch 'notification-usage-updates' of github.com:jillianhowart…
jillianhowarth Apr 7, 2020
c7f1cc9
Docs: update content
jillianhowarth Apr 7, 2020
187a564
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
5bec428
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
00b53bc
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
3321c1c
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
adb849e
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
386c4b3
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
00072f4
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 7, 2020
107598c
Merge branch 'master' of https://github.com/carbon-design-system/carb…
jillianhowarth Apr 7, 2020
87ad28a
Merge branch 'notification-usage-updates' of github.com:jillianhowart…
jillianhowarth Apr 7, 2020
3791c80
Docs: image and content chagnes
jillianhowarth Apr 8, 2020
362a98e
docs: minor content change
jillianhowarth Apr 8, 2020
0964a58
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 9, 2020
0c27aaa
Update src/pages/components/notification/usage.mdx
jillianhowarth Apr 9, 2020
cd45a1e
Docs: image and content updates
jillianhowarth Apr 10, 2020
f2f40bf
Docs: typo fix
jillianhowarth Apr 10, 2020
606543f
Docs: anatomy updates
jillianhowarth Apr 10, 2020
9196991
Docs: a11y update
jillianhowarth Apr 14, 2020
7188e18
Docs: a11y updates
jillianhowarth Apr 15, 2020
c155765
Merge branch 'master' into notification-usage-updates
jillianhowarth Apr 16, 2020
84ec602
Merge branch 'master' into notification-usage-updates
janchild Apr 16, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
173 changes: 146 additions & 27 deletions src/pages/components/notification/usage.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -4,79 +4,198 @@ description: Notifications are messages that communicate information to the user
tabs: ["Code", "Usage", "Style", " Accessibility"]
---

## General guidance
<PageDescription>

_Notifications_ are messages that communicate information to the user.
Notifications are messages that communicate information to the user. The two main types of notifications are toast notifications and inline notifications.

## Format
</PageDescription>

<AnchorLinks>

<AnchorLink>Overview</AnchorLink>
<AnchorLink>Formatting</AnchorLink>
<AnchorLink>Content</AnchorLink>
<AnchorLink>Inline notifications</AnchorLink>
<AnchorLink>Toast notifications</AnchorLink>
<AnchorLink>Modifiers</AnchorLink>
<AnchorLink>Related</AnchorLink>
<AnchorLink>Feedback</AnchorLink>

</AnchorLinks>

## Overview

### When to use

Use notifications to inform users of updates or changes to system status. Communicating with users and providing immediate feedback are important for building trust. While notifications are an effective method of communicating with users, they are disruptive and should be used sparingly.

For more context on when to use each notification type, including modals, refer to the [notifications pattern](/patterns/notification-pattern/). Carbon currently only supports inline, toast, and modal notification types, although some product teams also support banners and notification centers.

### Types

| Type | Purpose |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Inline | Inline notifications show up in task flows, to notify users of the status of an action. They usually appear at the top of the primary content area. |
| Toast | Toasts are non-modal, time-based window elements used to display short messages; they usually appear at the top of the screen and disappear after a few seconds. |

## Formatting

### Anatomy

<Row>
<Column colLg={8}>

![notification anatomy image](images/notification-anatomy.png)

</Column>
</Row>

1. **Icon:** Informs users of the type of notification at a glance.
2. **Title:** Gives users a quick overview of the notification.
3. **Message (optional):** Provides additional detail and actionable steps for the user to take.
4. **Action (optional):** Ghost button that allows users to address the notification or navigates them to a page with further details.
5. **Close button (optional):** Closes the notification.

## Content

Notifications provide limited space for content, and therefore the content must be short and concise. A user should be able to quickly scan the notification, be apprised of the situation, and know what to do next.

### Main elements

#### Title

All notifications have subject titles, which should be short and descriptive. (Example: “Tester-app-02 has crashed.”)
- The title should be short and descriptive, explaining the most important piece of information.
- When possible, communicate the main message using just the title.
- Use a period only if the title is a full sentence.

#### Message
#### Body content

We recommend the body of the notification be contained within two lines. Be descriptive and include any troubleshooting actions or next steps. When possible, communicate the main message using just the title. You can include [links](/components/link/code) within the notification body that redirect the user to next steps.
- Be concise and avoid repeating or paraphrasing the title.
- Limit content to one or two short sentences.
- Explain how to resolve the issue by including any troubleshooting actions or next steps. You can include links within the notification body that redirect the user to next steps.

#### Dismissal
#### Action

We recommend that toast notifications automatically disappear after five seconds. Inline notifications are persistent until the user dismisses them. All notifications have at least one method of dismissal (typically, it is a small “x” in the upper right hand corner).
- Keep labels concise and clearly indicate the action the user can take.
- Limit action labels to one or two words. For a list of approved action labels, see Carbon's [content guidelines](https://www.carbondesignsystem.com/guidelines/content/action-labels).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was surprised to see approved here, is there a process through which teams get labels approved? Or are these recommendations by our team?

Copy link
Contributor

@janchild janchild Apr 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These labels have been developed through multiple rounds of review with Cloud Data & AI, IoT, and Watson designers and content designers. If there were any changes requested, it would need to go back to this group for discussion and approval or not. The list has been stable for a period of time and so yes, "approved" is the correct word as opposed to "recommended".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion - should read; "For a list of recommended labels...". I'm not sure "approved" is correct here, in that it implies anything else is non-approved (but we don't have any real control over the action labels different teams might use).

Process for choosing which labels are recommended is outside the scope of this PR, but we can discuss if there is something we want to document/clarify.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's implying that labels have to be approved before using, but merely saying the action labels on that content page are approved to use. Maybe it should say "For a list of suggested action labels, ..."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs to be stronger than just suggested. If people have concerns with "approved" then I'd like to go with "recommended".

Copy link
Member

@aagonzales aagonzales Apr 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops sorry y'all my internet is terrible and for some reason no one else comments loaded until now so I wasn't purposefully ignoring any earlier comments.


#### Icons
### Overflow

Icons may provide additional clarity. Icons should be placed to the left of a title. These glyphs (16x16) can be found in the [icons](/guidelines/icons/library) library.
If a toast or inline notification requires a message longer than two lines, include a short message with a “View more” link that takes the user to a view of the full notification message. This can be either a full page with more details or a modal.

For further content guidance, see Carbon's [content guidelines](/guidelines/content/general).

## Inline notifications

### Formatting

<Row>
<Column colLg={8}>

![The three icon states](images/notification-usage-1.png)
![Example of inline notification with action button](images/notification-inline-action.png)

</Column>
</Row>

## Variations
#### Action

Inline notifications have an optional ghost button action that is adjacent to the title and body content. On mobile screens the action button wraps under the body content. This button should allow users to take further action on the notification.

| Notification type | Purpose |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| _Toast notification_ | Toasts are a non-modal, time-based window elements used to display short messages; they usually appear at the bottom of the screen and disappear after a few seconds. |
| _Inline notification_ | Inline notifications show up in task flows, to notify users of the status of an action. They usually appear at the top of the primary content area. |
#### Sizing

### High vs. low contrast
The width of inline notifications varies based on content and layout. They can expand to the fill the container or content area they relate to. Their height is based on the content length, which should not exceed two lines of text.

Use high-contrast style notifications for critical messaging. Low-contrast notifications are best used for supplemental messaging and are less visually disruptive to users. When in doubt, use the low contrast style.
#### Placement

Inline and toast notifications can use different styles but you should never mix styles within the variations.
Inline notifications appear near their related items. They can expand to fill the width of the container or content area they are in and should align to the grid columns.

We recommend placing inline notifications at the bottom of forms, just above the submission and cancel buttons. When error notifications apply to individual text inputs, they should supplement the error state on that specific input field.

<Row>
<Column colLg={8}>

![High vs. low contrast](images/notification-usage-4.png)
![Example of inline notification placement](images/notification-placement-inline.png)

<Caption>
Example of an inline notification supporting an error message on a form
</Caption>

</Column>
</Row>

## Placement
### Behavior

#### Toast notifications
#### Dismissal

Toast notifications slide in and out a page from the top-right corner. Actionable notifications do not appear on mobile screen widths.
Inline notifications do not dismiss automatically. They persist on the page until the user dismisses them or takes action that resolves the notification.

A small "x" in the top right corner is used to dismiss inline notifications. Including the close button is optional and should not be included if it is critical for a user to read or interact with the notification.

## Toast notifications

### Formatting

<Row>
<Column colLg={8}>

![Toast notification example](images/notification-usage-2.png)
![Example of toast notification with action button and time stamp](images/notification-toast-action.png)

</Column>
</Row>

#### Inline notifications
#### Action

Toast notifications can include a link at the end of their body content. This link should be short and navigate users to a page or modal where they can take action to address the notification or find further information. Because toast notifications automatically dismiss, there should be alternative routes to navigate to the link destination.

If you include links within the notification body that redirect the user to steps, be sure keyboard and screenreader users have enough time to access the notification or can easily find the notification after it disappears.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, it seems like we would want to recommend that notifications don't have any interactive content within them. When using a live region, the text of the area is what is communicated to the end user:

demo

As a result, there is no way for them to know if the content is interactive or not nor is there an easy way for them to navigate to it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More specifically. Is the feedback here that this guidance should change because we don't/can't include links in notifications?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is technically speaking something that we currently allow and show in the storybook. She is only commenting on what we're currently allowing. If we don't want to allow this then we need to also remove this from the component code.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aagonzales definitely agreed, I think this needs to be a conversation for us all to better understand what is/is not applicable here. It feels odd given that so many sites use this pattern that this is how a screen reader behaves, maybe I'm misunderstanding something? Was surprised when I was testing it out in that recording above that it announced the way that it did.

@dakahn do you have any insights here? Clearly this is a common pattern, including notifications at the OS-level, is there anything we can do to accommodate interactive content either through a link/action button/close button?

Copy link
Contributor

@dakahn dakahn Apr 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At IBM we have the requirement that any mouse interaction have a keyboard only equivalent. With notifications that popup and disappear (toasts or whatever) and have interactable child elements this rule becomes problematic.

How do we move keyboard focus to that notification? If this were a modal dialog we'd simply programmatically steal the users focus and move it to the dialog when the modal was opened and then trap focus in the dialog until an action was taken. When the modal is closed we then programmatically return focus to the element used to originally trigger the modal.

Toasts or notifications are non-modal dialogs and come and go perhaps on a timer as the user works and are intended to be unobtrusive so the above described interaction pattern doesn't really work.

At the application level there are ways to solve around this problem by having notifications collected somewhere that is keyboard accessible like this:

image

but its always highly inadvisable to use operating system level interactions as guidance for building websites since -- in short -- they are very different contexts and only superficially comparable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dakahn it seems like the guidance from WAI-ARIA gets distilled into two categories: alerts and alert dialogs:

An alert is an element that displays a brief, important message in a way that attracts the user's attention without interrupting the user's task
Because alerts are intended to provide important and potentially time-sensitive information without interfering with the user's ability to continue working, it is crucial they do not affect keyboard focus.

The alert dialog is designed for situations where interrupting work flow is necessary.


Alerts are what we can use for time-based notifications, but if there is anything interactive then we need to use the alert dialog?

What happens if we want to use a timed alert, but also want to give someone the ability to dismiss it early? This seems like it'd directly contradict the alert guidance as it says that it shouldn't steal focus from the user.

Links & resources

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if we want to use a timed alert, but also want to give someone the ability to dismiss it early?

They're highly problematic for sure. You can minimize a lot of these gnarly UX frustrations for keyboard/screen reader/magnification users, but some of those solutions cause frustrations for other (dialogs with interactable elements becoming modal for example solves one problem but creates another).


#### Time stamp

Toast notifications include a time stamp at the bottom the container. The time stamp shows the time the notification was sent. Using time stamps is optional but toasts should be consistent across the product so either all toasts should include time stamps or none of them should. The time stamp is optional and can be removed if a third line of content is needed.

#### Sizing

Inline notifications appear near its related item. In [forms](/components/form/code), we recommend placing the inline notification at the bottom of the form, right before the submission buttons. Depending on the context of the page, inline notifications can appear above the content as well.
Toast notifications use a fixed width and their height depends on the length of the notification message. As noted in the content guidelines, limit toast notifications to two lines of text.

#### Placement

Toast notifications slide in and out from the top right of the screen. They align to the edge of the last column and can stack with `$spacing-03` in-between. New toast notifications should appear at the top of the list, with older notifications being pushed down until they are dismissed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the height of the stacked notifications is greater than the browser height?

Notifications are typically absolutely positioned, as a result, how would one implement this guidance:

They align to the edge of the last column

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarification on @joshblack's last point; "absolute positioning" means that an element doesn't reference other elements, so the "align to the edge of the last column" is difficult/impossible to apply from a code perspective.

Do we need to either address the design guidance, or address the development implementation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good point that we don't currently have a solution for. This will need to be opened as a issue to figure out. I also think if they're disappearing after x seconds the chances of there being a long stack of them seems very unlikely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joshblack do you have a suggestion for how to provide the positioning guidance? I was trying to address this issue #76

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jillianhowarth it seems like we could re-word it to say that the notifications are aligned vertically and use the spacer in between and not mention the edge alignment? Just a thought 👀


Actionable toast notifications do not appear on mobile screen widths.
joshblack marked this conversation as resolved.
Show resolved Hide resolved

<Row>
<Column colLg={8}>

![Form example with inline notification](images/notification-usage-3.png)
![Example of toast notification placement](images/notification-placement-toast.png)

</Column>
</Row>

### Behavior

#### Dismissal

Toasts dismiss automatically after five seconds on the screen. They can also include a close button so users can dismiss them sooner. Toasts cover content on the screen so they should always be easily dismissed. Because toast notifications dismiss automatically, users should be able to access them elsewhere after the toast disappears. This allows them to be accessible for users who need more time reading the notification or who may want to refer back to the notification.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because toast notifications dismiss automatically, users should be able to access them elsewhere after the toast disappears

Should we word this more strongly to say that there must be an alternate location if the toast is automatically dismissed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It definitely seems like it should be a requirement rather than a preference, right? (so "users must be able to access..." rather than "users should...")

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would simply changing "should be" to "must be" be enough?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think so.


## Modifiers

### High and low contrast

Carbon supports high and low contrast style notifications. High-contrast notifications are best for critical messaging while low-contrast notifications are less visually disruptive for users.

It's up to the product team to decide which notification style to use in their product. Inline and toast notifications can use different styles but you should never mix styles within each notification type. When in doubt, use low-contrast notifications.

<Row>
<Column colLg={8}>

![High and low contrast inline notifications](images/notification-usage-4.png)

</Column>
</Row>

## Related

- [Modal component](https://www.carbondesignsystem.com/components/modal/usage/)
- [Notifications pattern](https://www.carbondesignsystem.com/patterns/notification-pattern)

## Feedback