Cartodb: time series scrubber movement does not span entire widget / data

[andy-esch]

Context

A partner / client needs a time series map off of data that is simply three years: 2012, 2013, 2014. They created a time series widget off of it and got the following:

Notice that the scrubber seems to have a different width than the underlying histogram.

related #12640

Steps to Reproduce

Same as in #12640:

1. Import this dataset with the same time properties as the client/partner data: http://eschbacher.carto.com/api/v2/sql?q=select%20*%20from%20time_series_issue_data&format=csv&filename=time_series_issue_data
2. Create a map for this data
3. Create a torque map and select the year column
4. Set number of steps to 3 (and reduce time to 6 so it goes more quickly)

Current Result

The following time series widget scrubber behavior:

Expected result

Scrubber spans the entire width

Browser and version

Chrome 60.0.3112.90
macOS 10.12.5

.carto file

CSV: http://eschbacher.carto.com/api/v2/sql?q=select%20*%20from%20time_series_issue_data&format=csv&filename=time_series_issue_data
.carto file:
time series widget three years (on 2017-08-23 at 16.24.54).carto.zip

Additional info

Comes from client / partner request

cc @timoco @jaime @zingbot

[xavijam]

If they want to display those years with "numbers", they should change and adequate the number of buckets, if not the histogram will not make sense (take into account time-series with number columns will display 256 buckets by default). And with that, it will work properly:

Checking the problem with aggregation dates, because something weird is happening.

[andy-esch]

I guess part of the confusion is that a change of bins in Torque is not connected with the number of bins in the time series widget other than the initial creation of the widget from the Torque. Is that by design?

[timoco]

The data is an integer either 2015, 2016, or 2017, but that is when the 2.0k in the time series appears. I changed this to a date and then aggregated by year to try and fudge the data to fit the display. Ideally a 3 bucket time series with that integer field showing as 2015, 2016, 2017 would show. Or another idea was having a second density map on the visualization, but that doesn't seem to be allowed.
Thanks for the help with this.Tim.

On Thursday, August 24, 2017, 9:56:53 AM EDT, Andy Eschbacher [e-mail] wrote:

I guess part of the confusion is that a change of bins in Torque is not connected with the number of bins in the time series widget other than the initial creation of the widget from the Torque. Is that by design?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[timoco]

Any updates on this?Thanks.

From: Andy Eschbacher [e-mail]: CartoDB/cartodb [e-mail]: Timothy Morrissey [e-mail]; Mention [e-mail]: Thursday, August 24, 2017, 9:56:53 AM EDTSubject: Re: [CartoDB/cartodb] time series scrubber movement does not span entire widget / data (#12641)

I guess part of the confusion is that a change of bins in Torque is not connected with the number of bins in the time series widget other than the initial creation of the widget from the Torque. Is that by design?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[xavijam]

Hi @timoco. Not yet, we are fixing several issues about Time-series and this will be tackled too. You will be notified when we start with it ;).

[andy-esch]

@xavijam, I opened a separate ticket about the rounding of the x-axis values at the same time I opened this one: https://github.com/CartoDB/cartodb/issues/12640

Back to my question earlier, are the bins between the torque map and the time series widget out of sync by design? To me, it makes sense that changing one will change the other since they start out linked. Further, displaying the bins, like in your GIF above, my expectation is that if the scrubber is moving through a bin, it should be displaying the data associated with that bin.

[rubenmoya]

I've been doing some research and it's related to this PR opened 2 years ago in Torque: https://github.com/CartoDB/torque/pull/185

I'm not sure about how to approach this, since I was thinking about fixing it the same way that PR does it, but the comments the PR suggest that there is a better way to do it.

[rubenmoya]

So after some conversations with @javisantana and @ivanmalagon and a few hours trying different things, we're thinking this is more a design problem than a technical one.

If the user selects 4 steps and 4 buckets we're creating 4 frames in Torque with the aggregated data, the scrubber points to the starting point of the bucket, but we're showing the entire bucket, so, the time slider is showing the correct data, but it's pretty hard to understand since the scrubber it's at the start of the bucket instead of the middle.

If you see the next schema, you can see we're showing 4 steps, but the user is expecting the scrubber to go to the end of the last bucket, which has no data, if instead of showing the scrubber in the start of the bucket we place it in the middle, the 4 steps would be correct.

 Steps
 1     2     3     4
 |_____|_____|_____|_____|
    1     2      3     4 
 Buckets

cc @noguerol @CartoDB/design

[noguerol]

@CartoDB/design I agree with @rubenmoya

[arianaescobar]

IMO the scrubber should fall wherever the user clicks on the timeline (as it happens on a youtube video for example) and then it should keep moving forwards. I get that we are snapping filter handles to the limits of the buckets when we select them, but in this case, we're not making any selection, we're just moving along a timeline.

So, to clarify, the scrubber shouldn't jump between each starting point, it should move along the full width of the bucket.

[javisantana]

in a youtube video you have +25fps in torque you could have 0.01fps, how do you explain to the user the scrubber is moving but the map is not changing?

but that's not the main issue, this is different to a youtube video, torque shows data aggregated per time frame, it does NOT show data for a specific point in time (like a video), it shows data for a range of time.

[arianaescobar]

Ok, not the best example then. Take any video software (After Effects, Final Cut...). You have layers that last for a certain amount of time, and they could be static, but the scrubber keeps moving along the whole width of the layer. Nothing is changing in the actual video, but the scrubber keeps moving.

[javisantana]

video is not a good example because in video you expect a high frame rate and there is no time aggregation like torque.

In a video you are not able to show an aggregation of time, you show a frame. In torque you show an aggregation of "frames" therefore the scrubber should be a range, not a line.

If you want to make torque like a video, there are constraints we need to apply like minimum frames based on data and so on.

[arianaescobar]

I understand that, but when you put a play/pause button, a scrubber, and timeline, the collective mindset will go to videos and how videos work. That's why we find strange behaviours in the interaction like the one stated by Rubén or in the initial comment of this issue. Our minds are expecting a common behaviour and we're getting something else.

To the current presented issue, I don't see many more options. Putting the scrubber in the middle of the bucket is not something we do in any other scenario so I wouldn't recommend making an exception here just because that interaction feels off in this particular case.

[noguerol]

@javisantana I understand your reasoning, but with frames or not, there is an animation an a playtime going on and that's why a jumping scrubber looks so confusing.
While @arianaescobar proposal doesn't sound bad to me, there is another option: to make a scrubber as wide as the buckets. I guess this scrubber will probably won't be that much of a black line but a highlight for every bucket/frame.

[nobuti]

So, in order to unblock this, how should we proceed?

[noguerol]

This still needs a little bit of @CartoDB/design love

[andy-esch]

I like @noguerol's solution of a scrubber as wide as buckets -- it balances the user expectation with what's happening with aggregation/display of data.

There is a separate issue in this ticket, too: should a change in torque bins be linked to a change in time series widget buckets? I strongly think changing one should change the other. I also see situations where a user would not want them to be linked (and unlinking should remove the scrubber, and the widget acts more similar to the histogram widget). I'm happy to open a separate ticket about this.

[nobuti]

That would be great @andy-esch, open it, please. Also, could you dig deeper about those scenarios? I mean, when the user could prefer a widget linked vs an unlinked one.

[noguerol]

Good question @andy-esch. I think they should be related, yes, but I would really like to know more about those decoupled use cases.

[alrocar]

Stale issue. Closing 👋