Esri / calcite-design-system

A monorepo containing the packages for Esri's Calcite Design System
https://developers.arcgis.com/calcite-design-system/
Other
282 stars 76 forks source link

[Alert] - use single auto-close speed #6395

Open macandcheese opened 1 year ago

macandcheese commented 1 year ago

Description

Initially brought up as a comment on https://github.com/Esri/calcite-components/issues/6363, we should consider a single, recommended auto-close duration and not have a configuration option. Fast is too fast and can be frustrating for users.

Defer to @ashetland @SkyeSeitz on the appropriate value for this.

Acceptance Criteria

A single, recommended, usable speed is used for ‘auto-close’ to reduce fragmentation.

Relevant Info

No response

Which Component

Alert

Example Use Case

No response

Esri team

Calcite (design)

ashetland commented 1 year ago

It'll likely require some testing to get this one right. At first glance the current medium speed isn't too bad, but the fast speed, in hindsight, maybe isn't terrible either. So maybe somewhere in between would work best.

The visual of the decreasing bar adds a sense of urgency that I don't find appealing, if I'm honest. It makes all the speeds feel faster than they actually are. It might be worth exploring an alternative way to represent that the Alert will be closing by itself. Just spitballing here, but if auto-closing Alerts had a place to go instead of disappearing entirely then the countdown would be less necessary — similar to notification/notification center patterns.

macandcheese commented 1 year ago

I do think it's important to maintain separation of intent between Alerts and something like a system-wide notification system and aggregation of such to a user-store.

There's definitely possible overlap where, say, an alert that messages to a user a process has begun, has a reciprocal system-notification available, but for the time being that seems out of scope for the simple Alert component, which should really only be used and displayed to immediately respond or message based on user interaction.

I'm not sure we've received much feedback on the progress bar itself (save for times when the alert's contents "processing begun" have been conflated with that process itself, but that likely isn't a great use case of an auto-closing alert for that reason). Auto closing alerts that dismiss without warning can be a frustration point for users if it dismisses right before they "reach it", so to speak. We could explore alternative displays though.

geospatialem commented 1 year ago

This also is a consideration as part of https://github.com/Esri/calcite-components/issues/6358, where alert has some pretty noticeable animations when animations are disabled/reduced on folks' OS.

As part of this effort, we should consider disabling auto-close for those with this feature enabled. If we do decide to do so, we should also document the support so devs know the auto close feature will not be available when animations are disabled or reduced on the users OS.

In looking at other design systems, wasn't able to spot a good example where alert supports a timed close and supports disabled/reduced animations.

geospatialem commented 1 year ago

Assigning this one to our June milestone to determine next steps on the design and dev side.

geospatialem commented 4 months ago

Related https://github.com/Esri/calcite-design-system/issues/6793

geospatialem commented 4 months ago

Proceeding to use the "medium" speed and moving this to a future milestone for development efforts.

ashetland commented 4 months ago

Proceeding to use the "medium" speed and moving this to a future milestone for development efforts.

Marking ready for dev based on this comment.

github-actions[bot] commented 4 months ago

cc @geospatialem, @brittneytewks