Bug 1590202

Created attachment 1450445 [details]
Hidden content on a form

Here is an example of the issue. In some cases when the environment is busy there is almost no chance to remove these popups and it prevents the user from using the portal.

Definitely an issue, and I can think of a few ways to solve from a UX perspective.

Liz, can you provide your opinion?

I agree with Greg, not necessarily disable completely, but do some UX magic to make it more consumable and less disturbing.

Hi all,

I think allowing the user to disable notifications as a feature, close all, or snooze are features that are avoiding the current problem. It would be great if we could pick up on the situations where we could let the user know in "bulk" that a number of things have happened. In this specific case, it would be really nice for the notification to be "6 VMs have been removed...". The user wouldn't feel like they've gotten a storm of notifications and it would scale to 100s of notifications if needed. Would it be technically possible to lump these together into one notification?

In some cases, the application might be experiencing the same issue over and over in which case it would be great to identify if that's happening and just notify the user once rather than with multiple. (This could be a case for allowing an action of "Don't notify me again about this"). Here's an example of ManageIQ handling this situation:
https://github.com/ManageIQ/manageiq-ui-service/pull/751

I think if we come across a use case where it does make sense to list out each toast notification individually, we should consider a "Clear All" feature, but it would be good to understand if there truly is a use case for this, or if we just need to be careful and considerate about which actions might cause a number of notifications at once.

What do folks think?

Thanks,
Liz

(In reply to Liz from comment #5)
> Hi all,
> 
> I think allowing the user to disable notifications as a feature, close all,
> or snooze are features that are avoiding the current problem. It would be
> great if we could pick up on the situations where we could let the user know
> in "bulk" that a number of things have happened. In this specific case, it
> would be really nice for the notification to be "6 VMs have been
> removed...". The user wouldn't feel like they've gotten a storm of
> notifications and it would scale to 100s of notifications if needed. Would
> it be technically possible to lump these together into one notification?
> 
> In some cases, the application might be experiencing the same issue over and
> over in which case it would be great to identify if that's happening and
> just notify the user once rather than with multiple. (This could be a case
> for allowing an action of "Don't notify me again about this"). Here's an
> example of ManageIQ handling this situation:
> https://github.com/ManageIQ/manageiq-ui-service/pull/751
> 
> I think if we come across a use case where it does make sense to list out
> each toast notification individually, we should consider a "Clear All"
> feature, but it would be good to understand if there truly is a use case for
> this, or if we just need to be careful and considerate about which actions
> might cause a number of notifications at once.
> 
> What do folks think?
> 
> Thanks,
> Liz

1. We might need some event supression mechanism. It sometimes may not make sense to output the same / similar event to the user multiple times in succession.
2. Do events by other users pop up?
3. I wonder if we should not pop up events for items originated from the API (not sure how feasible this is!)
4. Perhaps just alerts/warnings/async tasks?

@QE, to test, you'll need to do a mass operation that will cause 3 or more toast notifications to occur within 8 seconds.

WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops

Verified in
rhvm-4.3.0-0.8.rc2.el7.noarch
ovirt-engine-webadmin-portal-4.3.0-0.8.rc2.el7.noarch

New button Dismiss All and all the Do Not Disturb buttons work as expected.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085