display data range for histogram hover text

[chriddyp]

In this histogram, my data is binned by month. However, when I hover over a bar, I see the midpoint of the data. I wasn't sure whether to interpret this as the midpoint of the histogram bar or the start of the histogram bar. I would prefer if this was more explicit and said: October 1-September 1

[alexcjohnson]

related: #69 - this would be nice for all histograms, not just on date axes.

[etpinard]

I'd vote for merging this with #69

[etpinard]

or maybe closing #69 and keeping this thing.

[alexcjohnson]

Closing #69 and bringing the important comments here.

I said:

What I'd prefer to do is make smarter hover text for histograms. So the axis labels (which may or may not correspond to bins) can stay as they are, unless you use ticktext, but the hover text will be smarter - perhaps even showing the actual range of data aggregated in the bin, which would provide more useful information than just what the precise edges of the bin are.

@mewalig replied:

in case it is helpful to know, in my experience documenting ranges for financial services transactions, being able to show the ranges in the form of "x.00 - y.99" (to however many zeros and nines the creator wants/needs) is the most useful, because it shows not only the exact range, but also conveys the rounding approach that was used (e.g. "first round to two decimal places, then put in the corresponding bin"). I'm not saying that is what this library should default to, but it would be great if it was able to support a way to achieve that.

[alexcjohnson]

Actually might be natural for me to tackle this alongside #2071

[alexcjohnson]

It turns out to be super easy to have this report the actual data range in each bin, and there's something nice about this from a theoretical standpoint as it gives you more real information about your data, rather than just clarifying the meaning of what you can already see on the plot.

If the data in the bin span a range, you see that range:

If the data in the bin are all at the same value, you just see that value:

On the other hand I suspect a lot of users are more interested in clarification, but also when you see Jan 1, 2012 .. Jan 5, 2012, 13:45 it could be confusing to know what the bin size actually is, or be interpreted to mean that a sample before Jan 1 would go in the previous bin, even though that bin really goes back to mid December.

Figuring out what to display as the range for a bin otherwise - ie to get 0 .. 0.99 rather than 0 .. 1 (which would make it ambiguous which bin 1 goes into) - is a little bit tricky, but I think we can do it directly from the data without asking the user to specify it. In our algorithm a value at the bin start is included in that bin, and at the bin end is excluded, so basically my thought is: what we need is to find how many digits (or date parts) you need such that the range from bin start (rounded to that value) to bin end minus that value (again rounded to that value) always encompasses the min and max values within that bin. We'd also notice if all data is at bin center and fall back on the current behavior.

A disadvantage of that scheme is that it doesn't allow you to express increments other than full digits or date parts. So if you data is on ten-minute increments, you'd get one-minute precision from the bin, and if your data has increments of 0.05, you'd see 0.01 precision from the bin. I feel like this is acceptable for a first cut though, and if people want more control we can add an attribute for it later.

Thoughts @chriddyp @etpinard (and @mewalig if you're still interested)?

And a separate question: thoughts on the format, 0 .. 0.99 vs 0 - 0.99?

[etpinard]

On the other hand I suspect a lot of users are more interested in clarification, but also when you see Jan 1, 2012 .. Jan 5, 2012, 13:45 it could be confusing to know what the bin size actually is, [...]

I agree here. Although showing the data range might very useful, making this the default hover behavior is bound to confuse users. Showing the bin range feels less confusing to me.

So if you data is on ten-minute increments, you'd get one-minute precision from the bin, and if your data has increments of 0.05, you'd see 0.01 precision from the bin. I feel like this is acceptable for a first cut though

I agree. It feels acceptable for the first cut. But we should start thinking about those future attributes now. I'm thinking of putting them in the xbins / ybins containers:

x: [/* */],
xbins: {
  hovermode: 'range', // or 'data'
  hoverformat: '' // or maybe hoverprecision ...
}

And a separate question: thoughts on the format, 0 .. 0.99 vs 0 - 0.99?

I prefer 0 - 0.99 as long as we use unicode minuses (not simple - dash) to show negative numbers.

[etpinard]

@alexcjohnson do you want to keep to one open, or is #2115 enough now?

[alexcjohnson]

closed by #2113