elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.69k stars 8.12k forks source link

Default short links to using absolute time when opened on Dashboards and Discover #189156

Open jloleysens opened 1 month ago

jloleysens commented 1 month ago

Describe the feature:

Mostly when sharing a short link to discover (or a dashboard) I'd like to share the current view of data not the view of data when someone else follows the short link. IMO the easiest way to do this could be to default the short links to include absolute time ranges (at the time of copy) so that later viewers see the data of concern immediately when following the link. Perhaps via some kind of "absolute time range" toggle?

Right now I manually change the time ranges to absolute before sharing.

Screenshot 2024-07-25 at 10 03 19

Is there a different way to achieve this?

elasticmachine commented 1 month ago

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

elasticmachine commented 1 month ago

Pinging @elastic/appex-sharedux (Team:SharedUX)

Dosant commented 1 month ago

@kevinsweet, could you take a look please. Look like a good feature request, but we just went through simplifing the sharing dialog

kertal commented 1 month ago

@kevinsweet, could you take a look please. Look like a good feature request, but we just went through simplifing the sharing dialog

I like the recent simplification a lot (sharing a screen so the most recent state is visible)

Bildschirmfoto 2024-07-29 um 19 05 01

rather than adding a toogle, it could be a 2nd button/link to copy the state with absolute time range

tsullivan commented 1 month ago

I'm not certain this is what we want to do. When we add a toggle or a 2nd button it complicates the UI in ways that we worked hard to fix with the latest redesign.

Another option would be just to display a short summary of what is being shared, including the time range and selection format (relative or absolute). That way, instead of complicating the modal, we would just be more up-front about what the copy button is copying.

jloleysens commented 1 month ago

Nice! I wasn't aware of these in flight changes.

When we add a toggle or a 2nd button it complicates the UI in ways that we worked hard to fix with the latest redesign.

What about updating the behaviour of the copy button to understand click and double-click? Ex: click would copy current time range and double click would copy absolute time range. The only extra UI element might be a tooltip?

more up-front about what the copy button is copying

I'm not sure this addresses the heart of the issue but I totally hear your point about keeping things simpler.

davismcphee commented 1 month ago

I don't have strong opinions on the UX, but in general I think it makes sense to support this capability. Links with relative time ranges are useful when you want to generate a link like "Last 24 hours of logs", but in general when sharing a link from a Discover investigation, I imagine most users want to share the exact documents they were looking at with an absolute range. Supporting both scenarios with a clear UX would be valuable IMO.

tsullivan commented 1 month ago

I agree that in the new UX of using modals for sharing content in different ways, we do have more screen real estate to do this enhancement. The simplicity we have achieved in the latest UX has some room for this kind of growth.

My preference would be to have:

  1. If the user has a relative timepicker range selected:
    • A checkbox appears in the "Share Link" modal to let the user to either retain their relative selection (default), or use the absolute time that the range has selected.
    • New text showing the selected date range, which updates based on the setting of the relative/absolute checkbox.
      • Allows the user to confirm our date conversion if they switch the checkbox to "absolute."
      • Helps the user understand what the checkbox does.
  2. If the user has an absolute timepicker range selected:
    • No change from current UX

This is a high-traffic part of our UI, so I think this merits having a designer resource take a look. Pinging @ek-so

tsullivan commented 1 month ago

The discussion part of this issue is through, but anyone is still free to add more thoughts or concerns as needed.

Putting this back to triage so it can be estimated and prioritized.

petrklapka commented 3 weeks ago

@kevinsweet @ek-so - Looks like a good candidate for next quarter planned work. Maybe refine design and functionality and we'll throw it on the pile for Q3?