Cartodb: Time Series Widget - Keep animation when filtering histogram

[ivanmalagon]

Created based on the designs provided in https://github.com/CartoDB/design/issues/597 and the discussion in https://github.com/CartoDB/design/issues/597#issuecomment-303150294

We have to keep the animation playing when a range is selected in the time-series widget. Of course, the animation should be restricted to the filtered range.

[rjimenezda]

Blocking because while moving the play / pause I discovered this works almost out of the box, so I'll do it there.

However:

@saleiva @noguerol There's one small issue. When selecting a range, the whole animation duration is the same as if you selected the whole histogram, but applied to a smaller set of data, so it just feels much slower.

Calculating the new duration is not hard, but @xavijam pointed out that it might be tricky updating it, since we might have to destroy & recreate the widget, which would look awful when selecting a range.

So before we try anything else, do we want the range animation to:

a) Last as long as the original animation.
b) Have the same duration as that range had on the original animation.

Don't know if I explained myself 🤔

[saleiva]

well, at the end of the day, what the user perceives is the speed and not the duration, so we should try to keep the same speed even when it's filtered – tell me that we don't need to recreate the whole thing or I would start crying –.

[rjimenezda]

I'll look into it, just wanted to make sure.

[rjimenezda]

Pinging @CartoDB/frontend for feedback. Sorry for the _ladrillo_ post

So it is technically possible to alter the duration on runtime without recreating the widget, the question & the challenge is how and where do we do it.

Disclaimer: I personally think that if you have a set of data to play an animation from, and select a range, it makes sense to always adjust the playback speed and steps proportionally, not just for our widgets / builder. However this is a more strategic decision, so it's not up to me.

On deep-insights

If we want to do it purely from deep-insights, we can modify CartoCSS on the fly. However, this poses several challenges. It's not trivial to track what the original duration was or handling changes coming only from the form in order to always calculate the correct one.

Pros:

• We don't mess with torque or carto.js, so nobody else is affected.

Cons:

• Messy, prone to desync bugs

On carto.js

Torque-layer-view-base is a good place to handle this update:

  _renderRangeChanged: function (m, r) {
    if (_.isObject(r) && _.isNumber(r.start) && _.isNumber(r.end)) {
      this.nativeTorqueLayer.renderRange(r.start, r.end);
    } else {
      this.nativeTorqueLayer.resetRenderRange();
    }
  },

nativeTorqueLayer is already torque, one of the implementations based on the map library. All of them have an animator property who's responsible for, well, animating the steps.

At this point we can keep track of the original duration by reading it from CartoCSS or caching the one that nativeTorqueLayer.animator has, and we have the number of steps and the range, so we can easily update the animator duration.

Pros

• We don't mess with people using torque

Cons

• We mess with carto.js users, maybe.

All around

We could add an animationDuration property to the torqueLayerModel, update it on deep-insights and handle it on carto.js so it updates torque. To be honest I haven't investigated this course of action, it might be tricky since torque reads duration from cartocss at this moment.

I guess it's similar to the second solution, only we're exposing an interface to do it from outside instead of implicitly doing it.

Main pro is that the responsibility is on whoever wants to update the model, so we can do that on deep-insights & leave the rest of users to do what they want.

[xavijam]

Thanks for the explanation and possible solutions @rjimenezda 👏 . The solution should be taken by us, but it is true it is difficult to choose the correct place. IMHO, we should move the logic to Deep-Insights, because it belongs to the widget implementation, but man, I really trust on you so, what do you feel it is the best option?

[rjimenezda]

I think the current behaviour is a bug 🤷‍♂️

If there was no concept of 'range' to be played in carto.js / torqueLayers, then it would be fine, but I don't think it makes any sense to support ranges and not adapt the playback speed.

That being said, maybe it's overall better to attempt the third solution. It's not intrusive, and maybe carto.js users already expect the current behavior.

[rjimenezda]

So this won't come out with the play / pause changes, it's almost ready but some corner cases are trickier than expected.

So please, keep it blocked until #12387 is resolved, all improvements will be deployed with that branch. I will disable the play button for now.

In case somebody else grabs this while I'm out, or in case I forget everything:

What works:

• Selecting a range & playback, the speed is adjusted.
• Selecting a range, playback & updating the speed on cartocss / builder works, it recalculates the speed appropriately

What doesn't work:

• Changing other torque fields, like the number of steps, 'resets' the visualization and while the widget still plays a small segment of the data, the map goes through the whole dataset.

As you can see, the thing that doesn't work is purely a builder editor issue, it should work pretty OK on the embed view.

[matallo]

sorry to get late to the conversation, but as saleiva suggests, and in my opinion, the animation duration and steps should change depending on the animation range, so the perceived speed is the same

take this example (the original Torque) http://www.globalforestwatch.org/map/3/15.00/27.00/ALL/grayscale/loss,forestgain?tab=analysis-tab&begin=2001-01-01&end=2005-01-01&threshold=30&dont_analyze=true

[xavijam]

Unblocking it after merging last changes about time-series.

[rjimenezda]

Unassigning since I'll be out for a while. There's some progress on branch 12449-keep-playing (on Cartodb, DI & Cartodb.js).

One of the big problems why this remained on limbo for a while is that while having an animation playing on a selection worked fine, whenever the user changed some torque-related CartoCSS (namely resolution or steps) the animation went back to the whole map, while the filter stayed set, so it looked inconsistent.

As a workaround, we're clearing the filter when user changes some cartocss that triggers a vis reload.

I've done this because it _seems_ like tiler is fetching the whole range, ignoring the previously defined filter. It's not a big deal, it only affects builder (not embed), but @dgaubert should check out if that's the intended behaviour or not, whether we're missing something on our side or not 🙏

Regarding my post from a while ago: the speed is now consistent on a selection. Unfortunately the steps are not, and I've been unable to adapt the number of steps on a selection. The only consequence of this is the animation looks more fluid on a selected range (same steps, less or equal time). I've tried several approaches to no avail.

[noguerol]

thanks for the update, @rjimenezda

Any user where we can test this?

[alrocar]

Stale issue. Closing 👋