Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Categorical ticks and gridlines halfway between category labels #2601

Closed
yangmqglobe opened this issue May 2, 2018 · 8 comments
Closed

Categorical ticks and gridlines halfway between category labels #2601

yangmqglobe opened this issue May 2, 2018 · 8 comments
Assignees

Comments

@yangmqglobe
Copy link

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?).

@alexcjohnson
Copy link
Collaborator

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 😄

@yangmqglobe
Copy link
Author

yangmqglobe commented May 3, 2018

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

@alexcjohnson
Copy link
Collaborator

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 #1461 - perhaps this could fit into that framework.

@yangmqglobe
Copy link
Author

yangmqglobe commented May 4, 2018

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.

@etpinard etpinard changed the title Categorical axis grid is wired Categorical ticks and gridlines halfway between category labels Sep 14, 2018
@nicolaskruchten
Copy link
Member

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

@alexcjohnson
Copy link
Collaborator

alexcjohnson commented Oct 9, 2018

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 #2601 (comment)). 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?

@nicolaskruchten
Copy link
Member

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

@alexcjohnson
Copy link
Collaborator

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 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants