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

[mathematicalmichael]

what's the thought around showing numbers on the right side of each axis, making use of the whitespace that's currently there now? will that whitespace stick around?

(if you help me get centered with developing on this repo, I actually would be interested in trying out a version that does 90º labels for my use-case to avoid the whitespace)

[danthe3rd]

Hi @mathematicalmichael

Sure. Can you follow the instructions here to get started with developing HiPlot? (let me know if something is unclear, so I can update the doc accordingly)

Then what you want to modify is:
(1) The right margin
(2) The actual rotation angle (and maybe the font size as well)

hiplot/src/parallel/parallel.tsx

Lines 692 to 693 in 6930017

	this.style.fontSize = newFontSize + "px";
	this.style.transform = "rotate(" + (360 - ROTATION_ANGLE_RADS * 180 / Math.PI) + "deg)";

[mathematicalmichael]

@danthe3rd I just tried upgrading from 0.1.28 to 0.1.33 and noticed the rotated labels.

After many years... I still think rotation 90 degrees is the best option. Can handle lots of columns and won't cause padding issues. Thoughts?

Sorry I never got around to editing the typescript. Just felt really out of my comfort zone back then when I tried it.

[mathematicalmichael]

well, I finally figured out how to compile and ship this by parsing the CI/CD config. The website really isn't complete for someone trying to fork it and make changes.

this is the bastardized build script that I cobbled together from the circleCI yaml. (I manually edited setup.py and package.json) and published my own package hiplot-mm for use in my application.

build.sh:

rm -rf hiplot/static/built/*
rm -rf dist && mkdir dist pypi-build
mkdir -p npm-build/dist npm-build/dist-dev dist
cp .circleci/hotfixes/internmap.js node_modules/internmap/src/index.js
npm run build-dev
mv dist/* npm-build/dist-dev/
npm run build
npm run prepublish
mv dist/* npm-build/dist/ && mkdir -p hiplot/static/built/ && cp npm-build/dist/hiplot.bundle.js hiplot/static/built/

mkdir -p npm-package/hiplot

cp -r package.json tsconfig.json webpack.config.js README.md LICENSE src npm-build/dist npm-package/hiplot
rm -rf npm-package/hiplot/dist/hiplot-*  # Leftover from setup.py
python setup.py sdist bdist_wheel

I managed to rotate labels to vertical and shift the left-side over to make six-figure numbers visible.
work is here https://github.com/mindthemath/hiplot/tree/viz-updates

appreciate you pointing me in the right direction!
live example: https://oracle.math.computer/drake

also patched what I believe is a bug where refreshing the page causes ordering to swap, noticed it as a consequence of trying the latest hiplot version. see #288

assignment of e swapped. can't explain why but this helped...

.bind(this)).reverse().sort(function(this: ParallelPlot, a: string, b: string) {
      const pda = this.state.order.findIndex((e) => e == b);
      const pdb = this.state.order.findIndex((e) => e == a);
      return (pdb == -1 ? this.state.order.length : pdb) - (pda == -1 ? this.state.order.length : pda);
    }