Plotly.js: Categorical ticks and gridlines halfway between category labels

Created on 2 May 2018  路  8Comments  路  Source: plotly/plotly.js

When use categorical axis, the grid still drew in the middle of a category which you can find in here. By the way, the striped-rows style would be great for this situation(Yes, it is a table, but it can be used in plots right?).

feature

Most helpful comment

for now I would just get a flag that works for categorical axes

Hence my comment:

which I realize we need not support now, just want to ensure our solution will extend

As I was thinking it through, I initially thought a different approach would be needed for dates, in which case for consistency we'd have wanted to change categories too. But in the end I believe ^^ (with whatever terminology we settle on) will work for both cases 馃帀

All 8 comments

Good point, ticks and gridlines halfway between the category labels is often better than aligned with the labels, as they are for numeric or date axes. Not always, for example label-aligned may be better for scatter/bubble plots. Also I'm not sure what the right behavior is when categories get too dense and we can't show them all...

Striped rows is interesting, I see a few examples of it elsewhere, like here - it's not an effect I'd use myself, I think it makes interpreting the data harder. But we'd entertain a PR to add it 馃槃

em...My idea is not striped rows but striped columns, so the two adjacent category can distinguish easily, this will highly affect the group boxplot, group violin plot, which you can check out here. Another advance would be the category region hover highlight, which you can check out here

striped rows but striped columns, so the two adjacent category can distinguish easily

Nice, I'd call that the same feature (just applied to the x axis instead of y) but that does seem like a more useful application of it. Note that if you zoom out in your example you can see the issue I was worried about, when categories get too dense and the stripes (and/or ticks/lines) get put in what's suddenly a weird place:
screen shot 2018-05-03 at 10 02 50 am

Another advance would be the category region hover highlight

interesting, kind of a generalization of the idea of spikelines https://github.com/plotly/plotly.js/pull/1461 - perhaps this could fit into that framework.

In my opinion, for the dense data, user/developer should change their design like zoom their axis or change the plot type like this one
image
When there are too much bar, then you should use polar coordinates, so I think the stripe style should be an option weather for xaxis or yaxis, but the user/developer should consider is it fix to their work.

Basically here we just want a new ticksbetweenlabels boolean to start right?

Yep, a simple switch of some sort, at least for category axes. But ticksbetweenlabels: true sounds to me as though it could be enabling minor ticks, rather than just moving the existing ticks. How about boundaryticks: true? Or tickson: ('labels'|'boundaries')?

I think the desired behavior is unambiguous for category axes - the labels always align with the data points, and ticks (and gridlines, and stripes if we do that) always go half a category to the left (NOT necessarily halfway between the ticks, in case dtick !== 1, see https://github.com/plotly/plotly.js/issues/2601#issuecomment-386312022). But for date axes (which I realize we need not support now, just want to ensure our solution will extend) there are two cases of ticks not aligning with the labels, based on the ambiguity over whether a date/time value represents an instant (eg the timestamp midnight January 1) or an entire time period (eg the month of January - and in fact the period in question could be anything as well - a day, month, quarter, year... I suppose period of < 1 day is also possible but once you have a time in the data it's implied you're describing exact instants):

  • Data values are the beginning of the period they represent. You want the labels to line up with the data but the ticks offset by half the period. For example your data is ['2018-01', '2018-02', ...] but this represents each calendar month, not the instant each month starts, so you want labels January, February... but ticks half a month before the labels. If you were to zoom out on this data so you only get year labels, the ticks must still be shifted half a month left, not half a year, but also the year labels should be shifted to the middle of the year.
  • Data values represent precise instants. You want the ticks lined up with the data but the labels in the middle of the period. We may need some new formatting for some cases, for example "Jan-Jun" or "Apr 4-10"

You could imagine combining period and timestamp data, or data of different period, on the same date axis; for example you have monthly sales data (period is a month) and you overlay it with daily weather data (period is a day, or precisely timestamped). For this reason it seems to me that for date axes, the right way to do this is very different from category axes:

  • ticks/gridlines stay where they are
  • our new switch attribute, when enabled, shifts both the tick labels AND any data that has a period associated with it. So for example if there's a trace.x, there should also be a trace.xperiod, and we might try to automatically determine its default value - if the data is all truncated to months we can infer xperiod: 'M1' for example.

I don't see a reason to extend this behavior to numeric axes; seems to me if someone wants behavior like this for numbers of some sort they can just display those numbers on a category axis. Can anyone think of a situation in which this wouldn't work?

I think what you propose makes sense but for now I would just get a flag that works for categorical axes :)

for now I would just get a flag that works for categorical axes

Hence my comment:

which I realize we need not support now, just want to ensure our solution will extend

As I was thinking it through, I initially thought a different approach would be needed for dates, in which case for consistency we'd have wanted to change categories too. But in the end I believe ^^ (with whatever terminology we settle on) will work for both cases 馃帀

Was this page helpful?
0 / 5 - 0 ratings

Related issues

chriddyp picture chriddyp  路  3Comments

boleslawmaliszewski picture boleslawmaliszewski  路  3Comments

danielsamuels picture danielsamuels  路  3Comments

nicolaskruchten picture nicolaskruchten  路  3Comments

jonmmease picture jonmmease  路  3Comments