Skip to content

Bubble chart marker sizes affect legend symbols #2080

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

Closed
BobAvatar opened this issue Oct 11, 2017 · 9 comments
Closed

Bubble chart marker sizes affect legend symbols #2080

BobAvatar opened this issue Oct 11, 2017 · 9 comments
Labels
feature something new

Comments

@BobAvatar
Copy link

Below a certain "small" number for marker.size of a trace, the size of the legend symbol becomes smaller as well. This leads in extreme cases to single pixel legend symbols.

Minimal example:

var trace1 = {
x: [1, 2, 3, 4],
y: [10, 11, 12, 13],
mode: 'markers',
marker: {
size: [10, 6, 8, 5],
sizemode: 'area',
}
};

var trace2 = {
x: [1, 2, 3, 4],
y: [14, 15, 16, 17],
mode: 'markers',
marker: {
size: [400, 600, 800, 1000],
sizemode: 'area'
}
};

var data = [trace1, trace2];

var layout = {
title: 'Bubble Chart Size Scaling',
showlegend: true,
height: 480,
width: 640
};

Plotly.newPlot('myDiv', data, layout);

@etpinard
Copy link
Contributor

Ok. What's the desired behavior in your mind?

@BobAvatar
Copy link
Author

BobAvatar commented Oct 11, 2017

That the symbol size in the legend stays constant, no matter how tiny the corresponding bubbles might be. Does the size of the legend symbol scale in any other case? Would that be useful at all?

@alexcjohnson
Copy link
Collaborator

For context, the relevant code is in legend/style

That line bounds the size to between 2 and 16 px. I gather you'd like the 2 to be bigger? It's often helpful to have them different for different traces, particularly when size is a constant per trace. I suppose there would be an argument though that when size is an array we should choose some constant for all of them... But I also see two other problems here:

  • we should adjust this range based on the legend font size.
  • the size we pick doesn't account for sizemin, sizemode, or sizeref - the latter in particular can mean the legend size has no relation to the actual marker size. So we don't need to reinvent the wheel there, I'll note that the calcdata points contain mrc (marker radius calculated) which we can convert back to a diameter-based reference-1 size easily (just doubling it, I think)

@Wils0751
Copy link

I agree with BobAvatar. Perhaps rather than increasing the Min Size from 2px to larger, add a toggle to allow the developer to decide if they want constant bubble size or scaling size. I am doing usability testing and users are saying they don't like the scaling size difference. Its often hard to see with some bubbles being so small.

@BobAvatar
Copy link
Author

BobAvatar commented Oct 12, 2017

Many thanks to alexcjohnson and Wils0751, there are good points in your comments. Going forward, I'll try to summarize the desired behavior covering the mentioned aspects:

  • Minimum legend symbol size should definitely be larger than 2px.
  • If sizes for bubbles are given as an array, the legend should not try to infer a size for the legend symbol as it cannot do so in a generic manner.
  • To be future proof (high-dpi) the max legend symbol size should be linked to the legend font size
  • For cases, where size is a constant per trace, it might be desirable for the legend symbol to scale. However, any scaling needs to take sizeref, sizemin, and sizemode into account, otherwise awkward legend symbol sizes will occur, for example in the case where sizeref is much smaller or much larger than 1.
  • Alternatively to the last point, automatic scaling could be removed altogether, and the legend symbol size could be directly set to the given size when it is a constant across the trace (maybe within constraints that should be documented). This way, client code would be responsible for scaling the legend symbol in any desired manner. A problem with this approach would be, that any connection to font size would also be in the responsibility of the client code.

The last two points are tricky, but so is the current scaling heuristic, as it is undocumented and not necessarily intuitive.

@etpinard
Copy link
Contributor

related #1560

@fsmeier
Copy link

fsmeier commented Sep 25, 2018

I am also running into this problem while increasing the marker size while hovering: The legend uses the hovered marker size as well. :/

The defined wanted behaviour defined by you @etpinard is quite a big block. Can we maybe split it in subtasks? - Where to start?

@bearmountainsolutions
Copy link

Main problem is that color-scale legend entry sizes are tied to the data(!).
This can easily be seen by changing the size vlaue for “central coast” in this page you previously linked to https://codepen.io/etpinard/pen/LBWKBJ?editors=1010.

How could color-scale legend entries possibly be sized to what’s in the data? What would be driving the size of the bubble in the legend? The average across the trace?

This type of legend behavior makes this entire chart type a nonstarter. It’s impossible to show a bubble chart with categorical coloring, if one of the categories has an unusual value in the size variable. I’ll need to revert to normal scatterplots where this behavior is not broken.

Please please have a look at ggplot and the correct treatment of chart aestetics and mappings. Color and size are 2 different aesthetics, mapped to 2 different scales, and should have different legends, each of which show variation in that 1 aesthetic. I dunno guys, plotly has some really cool features but coolness doesn’t override readability. And personally i can’t be spending hours trying to make legends do what legends should do. Which is explain whats in the chart in a clear way.

@etpinard
Copy link
Contributor

etpinard commented Apr 5, 2019

Now in #3735

@etpinard etpinard closed this as completed Apr 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new
Projects
None yet
Development

No branches or pull requests

6 participants