Kibana: [discuss] Toast UX improvements: dismiss all, group similar, show more

[Dosant]

We use notification's service toasts to inform users about errors and warnings.
Sometimes those errors come from deep inside of codepaths without any orchestration before getting into notification service.
This could lead to following experience:

)

Initially with @elastic/kibana-app-arch we wanted to fix this particular issue https://github.com/elastic/kibana/issues/62649 on consumer side by adding errors debounce logic before calling notification service. But then during the discussion we agreed that this looks like a common issue that could be addressed inside notification service.

Some quick ideas we had:

• Have useful "Dismiss all" button to quickly close all of those notifications
• Have logic inside notifications service to group similar notifications (define similar)
• Implement some kind of show last N notifications and have "show more" button

[elasticmachine]

Pinging @elastic/kibana-design (Team:Design)

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

IMHO:

Have useful "Dismiss all" button to quickly close all of those notifications

Makes sense, most of the toast libraries provide such an option. Design support would be necessary though.

Have logic inside notifications service to group similar notifications (define similar)

Seems like out of the scope / responsibilities of the toast core service to me. We could eventually regroup toasts defined as 'similar' by the API consumers (with something like 'category' field maybe, or something else), but I don't see it being a default / automatic behavior of the service.

Design support would also be necessary here.

Implement some kind of show last N notifications and have "show more" button

Having more toasts displayed than the screen height allows is imho an anti pattern of what toast notifications should be. As a user, I will personally NEVER want to scroll / expand a toast notification list, as that are supposed to be non-mandatory, volatile information messages.

Some quick ideas we had:

From the issue example, wouldn't basic toast orchestration from the consumer using ToastsApi.remove before adding a similar toast answer your need?

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[Dosant]

I closed #69697 as duplicate,
Carrying over from there nice suggestions from @philippkahr:

---

I can think of two improvements:

1. there should be some close all toasts button somewhere.
2. Stack toasts notifications and add close all something like this:

When stacking we could go even further a stack similar errors into a stack. E.g. essagg error vs timeline error toasts.

[myasonik]

So many toasts really feels like abuse of what toasts are meant to be... It really seems like we're trying to screw in a nail or hammer a screw or otherwise misuse our ~metaphors~ tools.

To actually solve our Toast problems, we need a notification center of some sort and not continue to overload Toasts with more actions and complexity.

[iankoetter]

Just came to look if there was an issue related to improving toasts after for the Nth time I spammed myself with toast errors on a dashboard.

It's really annoying to have to acknowledge each toast on a dashboard that can generate 10+ of them on a single syntax error query.

_dismiss all_ where are you?

[cchaos]

I will carryover my comment from #69697

Kibana should consider not duplicating the same error messages and/or grouping all similar errors into one toast.

The previously mentioned potential solution is problematic because it could possibly obscure more "important" notifications. The user would have dismiss each one to find out which one is important. It's better to display them all with a simple scroll mechanism to easily scan for any that need attention.

What I'm seeing from the original screenshots are that 5 of the 7 (and all 3 of the second screenshot) are the same message (no extra information provided, no action to be taken). There should only be a single toast of it's kind no matter where the errors are coming from or how many times it occured.

[marius-dr]

We could probably change from "similar" to identical. That's the most common case encountered: opening a saved dashboard and each visualization on it errors out due to something like a missing index pattern. This will shove however many toasts as visualizations we have with the exact same message. In this case having them grouped up makes sense.

Just like the comment above, I found this issue when I wanted to open my own due to how bad it is for the user when this happens.

Having a good user experience when something goes bad is just as important (regardless if they are the ones that broke something) because it help debugging so much more. Right now I feel it only hinders the user.