Enhancement: Alert - Usability improvements to auto-dismiss.

[macandcheese]

Description

Two related proposals to solve potential annoyances for users:

• If an alert is auto-dismissible, currently we remove the close button. We should keep the close button there.

• If an alert is auto-dismissible, it may dismiss while a user tries to interact with it. We should pause the dismiss timer while a user is hovering over, or focusing on an element within an alert. I've seen this in the wild and its a very nice interaction (only reference I could find immediately was this https://bootstrap-vue.org/docs/components/toast#comp-ref-b-toast-props)

Which Component

Alert

Example Use Case

For the first - a user may want to dismiss the alert before the dismiss duration completes.

For the second, although disincentivized, apps may put actions or links inside of an auto-dismissible alert. Currently, the alert dismissal timer continues, even if they are hovering over the alert, or using keyboard to navigate and focus within.

[jul11557]

@macandcheese +100 on this! We have a custom alert in ArcGIS Mission that does exactly what you're suggesting:

• It allows users to manually dismiss the alert with an x button and we set an automatic dismiss timer on the alert. That way, we can allow un-intrusive messages to automatically disappear, and impatient users could easily tap the X to close.
• It remains on-screen when users click and hold the alert (allowing them more time to read and digest the message, if needed). I like the suggestion above about keeping it on hover.

We just swapped to the calcite alert, but are currently evaluating whether we should keep the calcite component or switch back to the custom alert we previously had. The lack of the close action might be the deal-breaker. The calcite alert looks more visually appealing, but without the enhancements you've listed in the issue above, the compenent can be a bit frustrating to interact with.

One interesting use case we have that may be worth considering:
Our app has enabled third-party sensor buttons. Someone can tap a smart button and it triggers an alert in the web app. These alerts are displayed with an alert component, and can include audio and sound. (Think of an emergency scenario: someone is responding to a search and rescue mission and has a sudden emergency. The person taps a button they are wearing on their vest, which triggers an emergency alert. An analyst, who is monitoring the mission from their desktop, sees the alert and hears sirens playing through the web app. The alert remains on-screen, un-blocked from the user's view, until the analyst has time to address the situation.)

[macandcheese]

Thanks for the additional use-cases @jul11557!

Implementer note - ensure we listen for touch events to allow mobile user's interactions to pause timer.

Just to check, does the sensor button use case require anything not outlined in the issue? Not sure if this helps or if I'm missing the ask but but we recently added a calciteAlertClose event you could listen for to determine when to stop playing that alert sound after user dismisses the alert: #3760

[jul11557]

No prob!

Thanks—we should be all set with the alert sound stopping. The only other requirement that we may need with regards to sensor buttons would be the ability to click or expand multiple alerts so they can be viewed in a vertically stacked position (when the alert is positioned on the far right side of the page). I know stacking is generally not the preferred practice, but in this particular case it would be helpful as helps improve our users' situational awareness. Can definitely chat about this separately if you need more info.

In general, this issue (as-is) would help us significantly with improving usability of the alerts 👍

[macandcheese]

The only other requirement that we may need with regards to sensor buttons would be the ability to click or expand multiple alerts so they can be viewed in a vertically stacked position (when the alert is positioned on the far right side of the page).

Agreed - this has been requested and although a bit stale can be tracked here: #2835

[ashetland]

Design complete in Figma. Updated design also addresses issues #5254 and #2382. cc: @geospatialem

[github-actions]

Installed and assigned for verification.

[geospatialem]

This looks good on next.668 with the exception of not closing when focused on child elements, which will be addressed in #5960.