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);
Ok. What's the desired behavior in your mind?
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?
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:
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)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.
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:
The last two points are tricky, but so is the current scaling heuristic, as it is undocumented and not necessarily intuitive.
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?
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.
Most helpful comment
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:
sizemin,sizemode, orsizeref- 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 thecalcdatapoints containmrc(marker radius calculated) which we can convert back to a diameter-based reference-1 size easily (just doubling it, I think)