search

Esri / calcite-design-system

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

Epic: Tooltip - Improve component timing #6396

Closed geospatialem closed 1 year ago

geospatialem commented 1 year ago

Actual Behavior

tooltip lags to open or close, where a delay is evident when hovering on/off the reference element. 🐢

Expected Behavior

A more speedy response when interacting with the tooltip 🐎 🏎️

Should allow devs to turn off the response, if they wish to do so.

Related issues

Reproduction Sample

https://developers.arcgis.com/calcite-design-system/components/tooltip/

Reproduction Steps

  1. Open the component sample
  2. Hover over the reference element
  3. Wait
  4. Observe the tooltip is displayed after a lag
  5. Hover off the reference element
  6. Wait
  7. Observe the tooltip disappears after a lag

Reproduction Version

1.0.3

Relevant Info

Related to discussions from https://github.com/Esri/calcite-components/issues/6393

Regression?

No response

Impact

Moderate

Esri team

ArcGIS Online

tannerjt commented 1 year ago

We've noticed this as well. Specifically, when using referenceElement on Safari v16.3, the lag is about 2x longer than on Chrome v109.0.5414.87.

jcfranco commented 1 year ago

@tannerjt What you're experiencing is a side effect from a polyfill we use to position floating-ui elements in non-Chromium browsers. https://github.com/Esri/calcite-components/pull/5542 has more info and also a workaround if you need to disable it (disabling will lead to incorrect positioning in some cases).

driskull commented 1 year ago

When clicking on an action, the tooltip still shows

The tooltip has a property closeOnClick which is false by default. We could change this if necessary.

According to w3c...

A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. It typically appears after a small delay and disappears when Escape is pressed or on mouse out.

https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/ https://www.digitala11y.com/tooltip-role/

Some docs say 1-5 seconds. Currently, I think its at a half second (500ms). I don't know if we should shorten more than that.

geospatialem commented 1 year ago

Design research is needed to determine timing, and if users can modify the timing.

driskull commented 1 year ago

@geospatialem any idea when we'll have the timing decided?

geospatialem commented 1 year ago

@geospatialem any idea when we'll have the timing decided?

@driskull Timing will be investigated in June, so feasibly development could start in June or July. However, there is a regression (not-timing related) with https://github.com/Esri/calcite-components/issues/6278 slotted for May.

ashetland commented 1 year ago

After digging into this, we've decided on the following:

See this Figma prototype for a demonstration with Action Bar and Alert. Full design file also available.

cc @macandcheese @SkyeSeitz

driskull commented 1 year ago

Ability to disable delay entirely with something like delay-disabled

The issue with this is that a user won't be able to hover over the tooltip to keep it open if the delay is disabled since there will be no time to move the mouse over the open tooltip.

It must stay open when the mouse moves over the tooltip itself, and should also close when the user presses the Escape key.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tooltip_role

I would advise against having the delay-disabled because of this.

When multiple Tooltips are adjacent to each other, subsequent Tooltips appear instantly and without animation

I'm not sure its feasible to know when tooltips are adjacent.

ashetland commented 1 year ago

If it turns out to not be feasible to know when Tooltips are adjacent to each other, then I'd suggest reducing both delays to 300ms to help speed things up. Also updated the original comment regarding disabling since it's not recommended.

driskull commented 1 year ago

Yeah, its tricky with the "instant" part because we want to give the user time to mouse over the open tooltip before opening any other tooltip that might be "in the way".

I actually like the 300/500 because it gives time for a user that might not be so fast to get over the tooltip. 300 might be a bit too fast to dismiss but I'll defer to the UX people if we want to do 300 for both.

ashetland commented 1 year ago

I'm good with 300/500. Is it worth exploring if the "instant" behavior could be added to Action Bar at least? My thinking is that's a scenario that could benefit from it the most and the user would still have time to mouse over the open tooltip to keep it open. The Figma demo for Action Bar doesn't keep the tooltip open, but you can see 500ms gives enough time for that to occur.

driskull commented 1 year ago

We could potentially do the "instant" opening if an existing tooltip is already open and another tooltip is being triggered. My only hesitation is cases where another tooltip could be triggered while trying to mouse over an already opened tooltip. It would probably need some testing if we wanted to pursue that. There would still be a CSS animation when the tooltip is set to "open".

ashetland commented 1 year ago

I'm not sure we'd want to get into a state where more than one tooltip could be open at the same time and with the timing changed to 300/500 I think it would feel like that. Agree that we wouldn't want another tooltip triggered while trying to mouse over an already open tooltip. I think in the case of Action Bar, this is less of an issue because the hit targets for the Actions are large enough to, hopefully, provide enough separation. The inspiration for this "instant" behavior came from this, but it's worth noting that the tooltips in the video don't stay open while hovering on them.

https://github.com/Esri/calcite-components/assets/108549080/1c272efc-92bb-42a9-a07e-922b124a3de3

ashetland commented 1 year ago

At the very least, shortening the open delay will help things feel more snappy across the board.

driskull commented 1 year ago

I don't think we can do different things for tooltips used by specific components. We don't know what is triggering the tooltip.

The tooltip is already setup so that only one can be visible at a time.

ashetland commented 1 year ago

Gotcha. Sounds like just an improvement to the delay then, 300/500ms?

driskull commented 1 year ago

Gotcha. Sounds like just an improvement to the delay then, 300/500ms?

Yeah we can do that.

When multiple Tooltips are adjacent to each other, subsequent Tooltips appear instantly and without animation

The problem with this is that we have no way of knowing adjacency. What we do know is if a tooltip is already open. So we could say if a tooltip is already open and a different tooltip is hovered then open immediately.

Tooltips appear instantly and without animation

Tooltip animation is triggered by being set open. So if we need to disable that animation in certain cases we would need to think of a way to do that.

github-actions[bot] commented 1 year ago

Installed and assigned for verification.

geospatialem commented 1 year ago

Verified mouse enter and leave speeds from https://github.com/Esri/calcite-components/issues/6396#issuecomment-1581607578 in 1.5.0-next.4