[RFC][Maps] Adding a timeslider to Maps

[thomasneirynck]

RFC for adding Timeslider to Maps.

A timeslider is a long-standing feature request for the Maps application: #27714

A working end-2-end POC is available here: #96791

We are looking to gather feedback since a timeslider would be more broadly useful in other Kibana apps as well.

Please comments on the doc https://github.com/elastic/kibana/pull/98355/files#diff-215d9ecb40e59418874139a12cb2fbde9d15d51dad380f0c947119b606980e7d . Depending on what the kind of questions and scope of feedback, we might spin these off in a separate Github discussion.

Thanks!

[nreese]

Thanks for putting this together. Its great and really captures timeslider and all of its details.

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[elizabetdev]

Thanks for making the changes that we discussed on Slack. It looks good! 🎉

[nreese]

just some minor suggestions.
LGTM

[kmartastic]

lgtm

[stacey-gammon]

I'm not entirely convinced of this, but I don't think it has any effect on this RFC, which looks great to me. Since I don't think the current implementation plan will back us into any corners one way or the other, LGTM!

[thomasneirynck]

thx @stacey-gammon

Yes, we can spin-off the discussion of adding new embeddable state. It agree it might not be necessary from a high level (e.g. timeslider as an Embeddable).

The reason we raised it here, is because keeping timeslice and timerange separate does solve a particular problem for Maps. It allows some layer-types to prefetch data: ie. get all the data within the entire timerange up-front, and then do client-side filtering to respond to timeslice-changes. This avoids round-trips to Elasticsearch. But this is definitely an optimization.

[AlonaNadler]

LGTM
One question, Im sure you thought about it and there is a reason. One of the things people expect from time slider is the ability to horizontally drag and manually play. In the current implementation, users can only click the arrows. it harder to see in a smooth way the changes there are no overlapping it immediately jump to the next interval. I'm guessing it is a decision based on performance?

[kmartastic]

LGTM
One question, Im sure you thought about it and there is a reason. One of the things people expect from time slider is the ability to horizontally drag and manually play. In the current implementation, users can only click the arrows. it harder to see in a smooth way the changes there are no overlapping it immediately jump to the next interval. I'm guessing it is a decision based on performance?

Yeah @AlonaNadler.

We're planning incremental improvements for the timeslider.
We do not want to release playback without a smooth playback experience.

Current milestones we're planning right now look like these:

1. Step through a time range with a time slice.
2. Seamless playback (and sliding manual drag) of the time slice across the time range.
3. Add context and interactivity with a histogram of the time range.

[thomasneirynck]

We're going to close this. Thx for all the feedback - on and offline.

@flash1293 had prepared an outline for how a timeslider could behave on a dashboard, and the implications wrt implementing this. https://gist.github.com/flash1293/3a9cf36c331e3f59ed85f0843e68f94e

It makes roughly a similar determination for dashboards as we're doing here for Maps:

• prefetching will be hard, especially for aggregated data, which is the default for most visualizations on a dashboard. The same concerns exist for Maps, and we will not want to explicitly address it. That's why any prefetching we see as feasible in the near-term would only focus on layers with individual documents.
• client-side caching: this could/should happen transparently. @flash1293 proposes the existing client-side cache, something which Maps can leverage too for e.g. choropleth maps, where the relevant data is just term-aggs. In addition, Maps can leverage the transparent client-side caching of tiling the data as well. This is an optimization that already will be in effect when toggling back&forth between timeslices when the data is tiled (ie. using the .mvt format).

@flash1293 also proposed a "third" "hardest" way, which would combine caching and pre-fetching somewhat "automagically". That is not something we're entertaining short term for the Maps implementation.

For completeness, wrt prefetching: The first PR for the Maps timeslider, #99661, removes any pre-fetching logic. This because we are running in more edge-cases than anticipated. We're hoping to dial in prefetch optimizations at a later time.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 98355 or prevent reminders by adding the backport:skip label.