Display bugs with rotated labels

[danthe3rd]

Original change in #213
Workaround: Use version <= 0.1.28

hi there. I've tried to track down which recent changes to hiplot resulted in my plots getting significantly harder to read, and narrowed it down to 0.1.28 -> 0.1.29 and believe this is the PR responsible.

This perfectly readable and stacked display: turned into which cuts off the final column name if I make the window any more narrow and causes a weird spacing issue on the right-side.

I very much support improving the visual interface of hiplot but I believe this hurt the overall experience. Would you be open to discussing some of the changes made here and perhaps a partial revert? Or am I best served maintaining a separate fork of the project? (I am not a front-end developer but am trying very hard to use hiplot in a tool I am building).

The above screenshots were in Opera (I've noticed Safari has had existing trouble with dragging columns). I also noticed that on Safari, this same change resulted in "ghosting" of the headers upon scrolling (and did not fix the aforementioned problem):

(that's the "rearranging" problem in safari I mentioned, the annotation divorces from the column)

(original report in #214 from @mathematicalmichael )

[danthe3rd]

Just for context, the change in columns display was made to address this issue: #147

Would you be open to discussing some of the changes made here and perhaps a partial revert?

I'm totally open to discussing these changes, and even to partially revert them if it makes sense, but I would like to still fulfil these criteria:
(1) Be able to support many columns (writing text horizontally does not really scale for that matter)
(2) Still be easy to use (would like to avoid the user having to specify which type of label orientation they want, or other low-level stuff)

Now just for me to understand the issue, are you unhappy with the labels being rotated? Or unhappy with the weird spacing on the right side?

Is sticking to an older version an acceptable temporary solution for you right now?

(Regarding the Safari scroll/drag issue, that's a bug that is definitively fixable will be addressed)

[mathematicalmichael]

hi there!
thanks for opening an issue, I should have just gone ahead and done so myself at a certain point. Yes I am fine using an older version pinned for the time being.

I don't have a problem with orienting labels at different rotations and also want to support many columns. vertical labels are sort of the "limit" I suppose, so the primary complaint was about the non-flush spacing + the ghosting issues that arose with the rotated labels (so strange).

I suppose the following expands the scope of the issue to just "display problems" in general but I figure it's relevant as it arises from trying to support the request in #147. I'll follow this repo more closely to stay abreast of active changes and conversation now... I've been working a while siloed away on core functionality and now I'm focusing on improving user-experience which largely depends on hiplot being an amazing tool.

On a similar note with a lot of columns: addressing scale of the numbers being presented. When numbers are more than five digits (e.g. over 10k), the leftmost column has its tick labels cut off / unreadable. The "percentile" scale is very helpful in addressing this though it does not get triggered by default.

I would think you could make the right-side spacing symmetric on the left side and this way keep the plot symmetric but readable, but I actually feel this would actually make it more difficult to use when the number of columns is high (you want as much horizontal room as possible, whitespace should be avoided), which leads me to propose that the leftmost and rightmost columns are handled in a different manner than all the central ones (for example, displace the location of the vertical column + tickmarks but not points to which the lines are anchored. I messed around with offsets in the web inspector and found that using translate could achieve the desired effect.

to

by editing `transform="translate(0,0)"` into `transform="translate(30,0)"` (perhaps a bit much, and the percentile-scale via autodetect may still be a better solution, just tossing out ideas, perhaps doing some simple math to optimize the translation parameter or decide on the "best" scaling for a column)

I published some examples yesterday to make it easier to reference test-cases I'm working on: oracle.math.computer/examples where I've sculpted the URLs to reorder and re-scale columns to maximize initial readability. If you re-run (save -> run) any of the examples, you'll get a "default view" as hiplot's returned html. The images above are from the wasting example.

[danthe3rd]

so the primary complaint was about the non-flush spacing + the ghosting issues that arose with the rotated labels (so strange).

The safari bug is definitively on my todo-list (I'll work on that in the coming weeks hopefully)
Regarding the added space on the right-side: it's there to make space for the rotated label

The "percentile" scale is very helpful in addressing this though it does not get triggered by default.

I'm not sure if we want the percentile scale to apply by default, as it's also distording the scale. Ideally, we want the linear scale to use exp notation to display big numbers I would say.
Another thing that could help would be to display the labels on the right side of the tick (left side currently) - which would also align them with the rotated labels.

[mathematicalmichael]

thanks!
and yeah, that's a fair point re: percent scale. somehow though large numbers shouldn't be cut off. switching which side they're on actually sounds like a fairly elegant solution (moreso than translating the axis). linear scale using exp notation meaning like 1E4, 1.34E5 etc? is that what log + percent use?

Makes me unsure I understand what "percent scale" does... I do notice it changes scale, but also notation format. What's the transformation applied there?

I guess there's a distinction between format and transforms. log performs a tranform and it seems percent does too, so yeah, something that changes format but preserves distance between points on the axis is indeed a desirable solution. Question is what is better: that or switching label sides? I suppose the latter could lead to unreadable collisions with high number of columns.

[danthe3rd]

linear scale using exp notation meaning like 1E4, 1.34E5 etc? is that what log + percent use?

Yes on both

What's the transformation applied there?

Percentile scale will scale according to values distribution.
Let's say you have the following values: [0, 0.1, 0.2, 0.3, 0.4, 0.5, 10]
Linear scale will put values < 1 at the bottom, and the value 10 at the top alone.
Percentile scale will spread them uniformly in between (0.3 will be at the middle of the scale)

[mathematicalmichael]

ah I see. that makes a lot of sense. since my data is generated from a uniform distributions, the transformations are barely perceptible. The extreme example is helpful to understand when this would be desirable for readability.

so regarding the unreadability issue for long numbers, is the proposed action to scale them to exp notation? seems like it'll solve that problem for sure.

as for the rotated labels, 90º rotations would solve all the problems except that it probably wont look very nice. taking away space from the columns for a label is not ideal either. so, special rules to handle spacing at the rightmost-side?

what if the language being used for annotation labels is written right-to-left, I suppose that would mean that you'd handle it similarly on the left side instead?

[mathematicalmichael]

reading back on the thread, moving the numbers to the right-side of each axis would be interesting as a solution if the whitespace on the right-side must remain, because it would fill the empty space with numbers (perhaps long ones), though I still think exp is appropriate after a certain number of digits in any of the values on an axis, or maybe the range of data (e.g. if max - min is O(4) or more, transform).

still aesthetically, i dont know if sacrificing that much space is worth it, but perhaps making the minimum rotation a larger number (closer to 90º) would minimize the whitespace. I do understand why this change was made now quite clearly, and am seeking a least-bad solution. I appreciate your prompt responses and explanations very much!

[danthe3rd]

ah I see. that makes a lot of sense. since my data is generated from a uniform distributions, the transformations are barely perceptible. The extreme example is helpful to understand when this would be desirable for readability.

so regarding the unreadability issue for long numbers, is the proposed action to scale them to exp notation? seems like it'll solve that problem for sure.

Yes I believe that's the correct solution

as for the rotated labels, 90º rotations would solve all the problems except that it probably wont look very nice. taking away space from the columns for a label is not ideal either. so, special rules to handle spacing at the rightmost-side?

Currently the rotation angle depends on the number of columns (more rotation for more columns). The rightmost column has its font-size scaled down so it fits on the screen

what if the language being used for annotation labels is written right-to-left, I suppose that would mean that you'd handle it similarly on the left side instead?

That's indeed something I didn't try at this point, and I don't believe it works out of the box ...

[danthe3rd]

Reopening for the large numbers representation improvement