Update alerts stacking behavior

[ghost]

Hi, we've just updated the stacking behavior in toast alerts Please, follow LEXI-987 for more info. Thanks!

[marcoscv-work]

Please, review comments on: https://issues.liferay.com/browse/LEXI-987

---

Resume

From accessibility, mobility, and animation point of view, probably the double animation (the union of disappearing animation and the rest of the alerts move them to a new place) can be more difficult to understand because you are sending much more sensory information to process, animations should help to understand, not to create more confusion or make it hard.

About the place to put a new communication: the common and recommended use is to show the communications down in the screen (like in a live chat), not on top of the previous communication, in the current figma if you have a limit height space, you can even lose a new notification.

More info in issue comments:

For our case and following WCAG 2.1 - 1.4.4 (AA):

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA).

It can be said that it is not accessible as a system of displaying alerts since we cannot limit the number of alerts or its size.

In detail: In a common resolution of 1280x720, in a windows SO, you have more or less 550px of vertical space available, if you use a zoom x200, the designed element is double, so you have a real space of 225px available. So we only can ensure the alert is on the screen if we put the new alerts in the bottom left corner.

Currently, this behavior works correctly from an accessibility point of view. So in order to not introduce new accessibility issues, I have the moral obligation to insist on reviewing the pattern

About the animation, I recommend applying the principle of: "Avoid using unnecessary animation" in order to help people with cognitive disabilities or mild vestibular disorder. Disappearing things are much mild than changing the order and focus of things

[jbalsas]

About the animation, I recommend applying the principle of: "Avoid using unnecessary animation" in order to help people with cognitive disabilities or mild vestibular disorder. Disappearing things are much mild than changing the order and focus of things

Couldn't we use prefers-reduced-motion to make that decision?

[pat270]

We can put overflow: auto on the container around the alerts. It should show a scrollbar when the screen is too short.

[bryceosterhaus]

I just tested @pat270s suggestion and overflow seems to work fine for alerts to go off the screen. As for the order in which the elements appear, that is up to the user and how they render their <ClayAlert components within the <ClayAlert.ToastContainer> component. By default, our examples show that the newest items appear at the bottom of the list.

[jbalsas]

As for the order in which the elements appear, that is up to the user and how they render their <ClayAlert components within the component. By default, our examples show that the newest items appear at the bottom of the list

We are kinda the end user in DXP, as we offer a single openToast API. Product Team developers use the programmatic API to open Toasts in a unified way, so we'll need to code some of those requirements there.

[marcoscv-work]

We can put overflow: auto on the container around the alerts. It should show a scrollbar when the screen is too short.

That's technically works perfect, great! But the problem is rather that we are losing the possibility of seeing the alert appear in a concrete place and understand it is new. The scroll could appear but it is not a direct signal of a new alert showed up.

I had to validate this behavior with AENOR in 2012 (WCAG 2.0). And was horrible haha.

@bryceosterhaus yeah, I would say current behavior is accessible

@jbalsas prefers-reduced-motion is the best option to remove animations/transitions. Maybe we could add it to the roadmap as s global solution. I would like anyway to see it as a general design requirement in order to allow other teams to understand is important, that's only a suggestion of course!

@hold-shift @victorvalle

[kresimir-coko]

Perhaps we can make the old alerts transparent/fade a bit, and perhaps add a drop shadow to the newest one. Combination of those 2 things could make enough of a difference while not adding much clutter. Not sure if that's acceptable for DXP/Lexicon

[ghost]

We've just updated the description on this https://issues.liferay.com/browse/LEXI-987 We updated the order of appearance in the notifications to avoid creating new accessibility solutions and so that the component is seen in very extreme resolutions, as we talked with @marcoscv-work.

[ghost]

Please, let us know if it meets the requirements.

[victorvalle]

Related to prefers-reduced-motion we have included in the documentation.

We are starting a major study on motion for lexicon and we will be taking a close look at accessibility.

[jbalsas]

Hey @hold-shift, @victorvalle, thanks for analyzing the feedback and continuing your work on this!!

In this case, I'd like to voice my disagreement with this decision and with @marcoscv-work. I'm not convinced the new solution is better in terms of accessibility or UX. While the new approach addresses some concerns, there are a couple of issues with it that bother me:

• Adding a new alert displaces all other previous alerts causing increased motion. Before, adding a new alert wouldn't cause any other element to shift. This means 3 things:
  • Adding a new alert now causes more motion than needed, making it almost impossible to keep track of alerts and possibly moving information that the user was reading without an explicit user-interaction that triggered it.
  • The new alert is less distinguishable from the other ones as they all move in sync. That makes it harder to detect (as per the Von Restorff effect)
  • Performance when adding new alerts might be impacted if there are several on the page.
• Interactive elements can be displaced in the middle of an interaction. This is just a logical continuation of the first issue. This is a very annoying and well known effect in apps with "scroll to refresh" like earlier versions of Twitter.
  • You're going to click on an element only to find it move in the last second making you click elsewhere. I couldn't find a principle or description of this effect, but I doubt it's a desirable trait in UX...

I'm not saying we should change the decision to make me happy, but I'd like to make sure these things are accounted for in the solution before we proceed with an implementation.

PS: The stacking order moves the most motion either to the time where the alerts appear or to when they go away, so I guess it's a matter of figuring out in which of the cases it should be reduced.

[ghost]

I agree with the solution you propose. In fact, I was discussing it with Marcos a few days ago.

Despite how important it is to offer an accessibility solution, I believe that we have a duty to offer any solution that does not have to penalize the rest of the users' experience. I'm not too fond of the notifications moving every time a new one appears; it becomes more difficult to locate old ones. Even speaking in accessibility terms, the cognitive pattern of returning to the notification and having it remaining in the same place seems better.

I did a little research exercise, and I found examples in both directions; although I didn't find any study to support it, logic makes me go in that direction. If it's okay with you, I will do some research on this and share it as soon as I have it.

[marcoscv-work]

My argument tried not based on what I think because yes! or because I'm looking for information in one direction or in the other direction (I think there are in both, as always). It is based on mistakes my team and I made years ago and how other people help us to fix it during an accessibility official review.

Yes! I've insisted on the importance of not adding no useful animations so if what I think about animations in this pattern is not totally clear, I can clarify it: I do not agree about adding animation to this pattern in any direction.

In the project I mentioned we fix this problem by finally making some changes:

• We remove all animations
• We prioritize the last appeared alert
• We use the same space for new notifications using the corner where we decided to fix the initial notification. (we had in two different corners).

I think at this moment in the conversation, the last point is more relevant:

• If you think in a live chat like WhatsApp or telegram, the first message is placed on the bottom of the screen, and then, the next one is on the bottom of the previous one.
• In Mac notification center, the first notification is on the top right of the screen, and the next one.. on top of the previous one. (toast works different, the same APP only can use a slot of notifications, to stack notifications we would need more than an app. sending notifications and they are ordered inverted).
• In Windows, toast notifications are placed in the right bottom corner.
• In Android and iOS, notification is placed on top, the next ones on top of the last one
• In an AppleTV notifications are on the top right corner, same behavior as previous ones (in this one I usually have a lot of notifications!).

They are only some examples, but most are making appearing new notifications in the corner they decided to make show it up initially, I think is a pretty common pattern, it's like saying: "This corner is going to be used to show notifications". instead of saying: this corner!.. well.. now in the middle.. and now.. on the top!... and now, who will know you cannot see it!!!.

With Clay we could create a notification on any corner, bottom, or top, and I think we need to use a pattern good for all cases, for me, ensure a principle as robust as: "Where appeared the first notifications will appear the rest"

But I insist, if with four notifications we can lose the newest one, it is a problem. I think it is not possible to reproduce in any product I mentioned before.

Having said that! all my support for any solution you guys decide! a general scroll as Patrick mentioned, all animated.. whatever, I only tried to say the new pattern is less accessible than the current one and that probably we can improve it by keeping accessibility at the same time! :-D

[marcoscv-work]

Some last ideas that could fix the issue:

• To use our toast notifications as not accumulate notifications, like Consecutive snackbar in material design
• Do it only when we have more than XX toast
• Using an invisible scroll, if a new one appears and it is out of the screen, we position the scroll on top/bottom to make visible the notification
• Create levels and limits of importance for toast notifications, applying:
• WCAG 2.1 2.2.4 - Don’t use notifications that dismiss on a timer for critical or emergency messages
• Start thinking about a toast notification panel (group them in a toast panel)
• Copy carbon pattern: -- Multiple toasts stack horizontally, with the newest appearing at the top of the list. -- List notifications in chronological order.

[jbalsas]

Thanks @marcoscv-work!

I think @hold-shift and @victorvalle have enough feedback now to make a final decision 😂

Whatever it is, we can implement, test to see how it behaves and iterate if necessary!

[ghost]

I would like to clarify that none of the proposed solutions went in the direction of just what I think. I always try to find the best solution but considering both could work, there is always a criterion behind any decision. From my criteria and experience, controlled animations enrich the user experience, and there are solutions that you can control to comply with accessibility too, but I would say it involves a bit more work. Still, of course it should be done with care. https://www.ibm.com/design/language/motion-ui/basics/

For a user without accessibility problems, for which we also design, it is easier to detect that a new notification appears when there is a slight transition that guides the eye towards what is happening (especially on large screens, the opposite case of users with accessibility issues).

I agree that introducing snackbars could solve the problem; within this context, a new snackbar replaces the previous one, and it is good practice to avoid this stacking behavior between them. https://material.io/components/snackbars#behavior.

In fact, even though we call them toast notifications, when they have a timeout, I was considering treat them as a snackbar. So, for me, one solution made more sense (regarding the order) than the other, but it would force to have 2 components, in 2 different positions, upper right corner for notifications and bottom left for snackbars.

After discussing this, we have ruled out tackling this task for now. We have an epic of accessibility and motion pending that will make us make a better decision from a system point of view.

Thanks @jbalsas and @marcoscv-work!

[marcoscv-work]

Thank you very much, guys!!!!

I really like animation/motion, one of my passions! I started working on motion 19 years ago (Vaillant e-Trainings, and Aena airports animation operations guidelines). And I can say it has been changing a lot during the last years!!! bit the bases are the same along all this time.

I define myself as a motion/animation passionate person and some people tell me I contradict myself when I say is better not to add animation but I really think on adding animation only when we have proves of the animation helps to understand something.

I really like global design systems because they have had to adapt to many persons and they know a lot about UI motion, I like your example because I usually use their checklist: https://www.ibm.com/design/language/motion-ui/resources#motion-evaluation-checklist

Some points I usually highlight from the checklist:

• Is your motion purposeful? What problem is motion solving? Does it enhance the user experience?

• Is your motion unobtrusive? The best interface motion may go unnoticed, because it often keeps users engaged with their tasks. Is your motion frequently noticed by the average users? If so, consider removing it, or minimizing it.

And some advice I really love on the bottom of the page:

• Provide alternative signifiers for devices with less computing power and users with disabilities.
• Consider motion-simplified designs for mobile and tablet.
• Make sure there is always a way to communicate the meaning behind a motion statically.

Thanks, guys, you have a beautiful job ahead of you, cheer up!

[d80wrk]

There's a case to be made for a universal modal to place multiple messages in. Keep it on the screen with a dismissible icon and treat it like a slider (carousel).

In other words I guess, pagination of multiple messages. https://github.com/liferay/clay/issues/1611

Keep up the good work.