Floating Notifications

[abhigyanghosh30]

Pattern to amend

Notifications

Visual

On Vanilla, it could look something like this:

Context

It is used to inform users of a process that has been performed or will be performed. They appear towards the bottom of the screen. They are detached from the rest of the page content and are positioned usually at the bottom of the screen offset to either side on larger screens.

[abhigyanghosh30]

https://github.com/canonical-web-and-design/vanilla-framework/issues/3997 Looks like a similar issue was raised earlier but was closed due to lack of activity

[danielmutis]

@marinacastejon to look into accessibility of making it a floating item on top of content.

@wgx to take a look at rules for floating notifications. We have already done some of this work in this spec which is not yet finalised.

[danielmutis]

@wgx will investigate use cases for this.

[marinacastejon]

Hi, Some accessibility considerations after doing some desk research. Floating notifications, often called Toast notifications, present a number of accessibility challenges. That is not to say we should never use them. Well-founded design systems (Carbon DS) include them. However they need to be used wisely and implemented with some A11y tweaks.

Main considerations:

• Toast should not be used to convey critical messages to users.
• There should be enough time for users to access the content. WCAG 2.1.1.
• Screen readers should announce the message without receiving focus. This can be achieved using ARIA. WCAG 4.1.3
• This article gives some good points about toast messages NOT containing interactive controls (ie. actions).
• In the case the toast notification contains an action, and this action is important (principle of comparable experience) there should be an alternative way of performing that action outside the toast notification.
• It should never contain critical actions if it is time sensitive.
• When implementing this component, it's important to think about the focus order and the position in the screen. Not only how to access the toast but also where does the focus move to when the user triggers the action in the toast notification.
• The position in the screen should be consistent.
• On desktop, when it is placed in a corner of the screen it is less visible than other times of notifications. It is even more problematic for people using screen magnification software.
• They also hide content that could be focusable, potentially violating the WCAG guideline of visible focus.

Articles on the accessibility of toast messages:

• A toast to an accessible toast...
• Scraping burned toast
• Defining ‘Toast’ Messages
• Designing toast messages for accessibility
• The problem with snackbars and toast messages

Conclusion: specifications and accessibility considerations need to be well thought of, if we decide to move forward with this.

[danielmutis]

@AnnSoMuller has some examples of this being useful on Reviewer pages on Snapcraft. This will be worked on when we have bandwidth to explore.

[danielmutis]

@al-bakalova to provide examples of how this is useful in LXD. This is related to this issue.

[al-bakalova]

LXD is a product with lots of item lists - Projects, Instances, Profiles, Networks, Storage pools - to name a few. To present these and provide details, we use tables. When browsing a table, the current notifications (failing to start or stop an instance as an example) go above the table and the user has to always scroll up to remove them. What is more, we use a split layout to provide further details about the instances in the table. When the split layout is active, there are no clear guidelines on where and how the current notifications should appear. During our user testing sessions, we found out that this experience is rather unpleasant and frustrating to our users. We believe introducing floating notifications will remove that burden.
On a side note, we would like to be able to position the floating notification in a way where they do not cover essential actions available in the header of our pages. Here's a quick example.

I am also tagging @edlerd to make sure he also shares his findings and concerns.

[bartaz]

I guess it's worth bringing back the specs that Will initially created for Notifications and Notification centre: https://discourse.ubuntu.com/c/design/pattern-notifications/81

Because with floating notifications there are a lot of problems to solve - where to show them, how long to show them, how to show multiple of them, what if user doesn't want to deal with them immediately, etc. Most of those problems are solved by having some kind of notification centre, where notifications can be viewed.

There is currently no such component in Vanilla or react components, because no one needed it. If LXD has the need for proper notification center it seems we have specs from Will that could be used as a base to implement it.

But because notifications are quite contextual and a lot depends on the need of actual application it's hard to make good calls on that in Vanilla itself first.

[edlerd]

From my tests, implementing floating notifications is straightforward with plugging the vanilla notification as a custom style into https://react-hot-toast.com/

There are some unknowns:

1. Where to position the overlays: top middle, top right below cta (this is quite complicated, because when scrolling down the notification should move up but also stay sticky), or on the bottom?
2. When to hide? From textbook, I learned it is bad practice, because a user might be away and not see the notification.
3. What to do with multiple? Currently, we only show the latest notification - that might be an okay solution, but again the user might miss something this way. Solution is likely in the notification centre as mentioned above. We could mount a notify icon in a status bar - though I would expect it on the top of the page like in most social networks today.

[anthonydillon]

Personally, I would suggest it would be worth developing the notification center as this is likely to be needed in the long run and helps with missed or reviewing notifications.

On the other hand, notifications should cover these three important factors:

1. Information: the notification message should be clear and distinct to the action which triggered it.
2. Actionable: the notification should almost always be actionable in some way. For example: "Undo", "Cancel", "Rerun", etc.
3. Timely: all notifications should show when the event occurred. For example, "2 minutes ago".