You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 12, 2024. It is now read-only.
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)
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)
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.
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.
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.
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)
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?
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!
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 ...
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)
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)
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.
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...
Activity
danthe3rd commentedon Oct 25, 2021
Just for context, the change in columns display was made to address this issue: #147
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 commentedon Oct 26, 2021
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
translatecould 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 commentedon Oct 26, 2021
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
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
expnotation 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 commentedon Oct 27, 2021
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
expnotation meaning like1E4,1.34E5etc? 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 commentedon Oct 27, 2021
Yes on both
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
< 1at the bottom, and the value10at the top alone.Percentile scale will spread them uniformly in between (
0.3will be at the middle of the scale)mathematicalmichael commentedon Oct 28, 2021
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
expnotation? 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 commentedon Oct 28, 2021
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
expis 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 commentedon Oct 28, 2021
Yes I believe that's the correct solution
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
That's indeed something I didn't try at this point, and I don't believe it works out of the box ...
danthe3rd commentedon Nov 4, 2021
Reopening for the large numbers representation improvement
mathematicalmichael commentedon Nov 4, 2021
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 commentedon Nov 5, 2021
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
mathematicalmichael commentedon Dec 9, 2023
@danthe3rd I just tried upgrading from
0.1.28to0.1.33and 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 commentedon Dec 9, 2023
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.pyandpackage.json) and published my own packagehiplot-mmfor use in my application.build.sh: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
hiplotversion. see #288assignment of
eswapped. can't explain why but this helped...