Default circle scatter appearance

[bryevdv]

Looking at this comparison:

https://share.streamlit.io/discdiver/data-viz-streamlit/main/app.py

We have the smallest default circle marker by far.

Should we bump the default size 10-15%? Should we consider adopting some of the different default visual highlights ala altair (light fill) or seaborn (light border)?

cc @bokeh/dev

[p-himik]

I don't see any problem with it by itself.
Increasing the size might make some plots ugly, but also might make fewer users change the default size.
The latter can potentially be checked to see how many users explicitly set the size to some value that's a bit larger. I think there's a way to do it via GitHub query functionality, but I've never used it.

[bryevdv]

I don't see any problem with it by itself.

@p-himik just to make sure I am interpreting correclty: you don't see a problem with increasing the default size, correct?

The latter can potentially be checked to see how many users explicitly set the size to some value that's a bit larger. I think there's a way to do it via GitHub query functionality, but I've never used it.

RIght I think this is the CodeQL functionality from their acquisition of Semmle. I have never tried to use it either but agree it might potentially be a valuable tool to leverage.

[p-himik]

you don't see a problem with increasing the default size, correct?

Vice versa. :) I don't see a problem with the sizes being the smallest. Not much smaller than Plotly or Altair.
All libraries are different in many regards, and when it comes to quantitative stuff, there will always be some at max and some at min - doesn't mean it's bad or even that it needs adjusting. But some additional info from CodeQL might at least hint at that.

[bryevdv]

Vice versa.

Ah, good I asked. Altair uses a different (attractive) fill style. And Plotly applies a better default palette. I guess I should clarify that my question is not strictly about the size being the smallest, per se. It's more that IMO I think our default looks the worst.

I guess this a meta question: what are ways we can make output look better by default

So then another idea: Is there any way we can make better colormapping with a default palette even simpler?

Looking at plotly's

color="species"

We already check to see if the value is a column name, we could go a step further and apply a default colormap if the first value is not actually a valid color value.

[bryevdv]

I'm also willing to bet there is academic research that could inform this question but I am not sure where to look for it.

[jbednar]

I'd consider the default size to be important not just for how it looks, but for how usable it is. When coloring by category as in this plot, it can be difficult to make out the colors of small dots. E.g. if the blue and green dots overlapped more as in this example, it would be very hard to see which is which;colors show up much more clearly with larger dots.

As for light fill or light border, I vote in favor of a light border, because it helps make overlap more visible, alerting users to overplotting issues. Light fill has some advantages for how it behaves when overplotting, but that seems too opinionated a change to make to the defaults at this stage in Bokeh's history.

In both cases I'd think any changes to the defaults should be for 3.0 to avoid breaking existing plot appearance for users of bokeh 2.x.

[p-himik]

I guess this a meta question: what are ways we can make output look better by default

Ah, OK. In this case, I agree that it's worth pursuing. I don't know of any ways other than to either go through a multitude of plots and come up with something or to vote on one style among many.

we could go a step further and apply a default colormap if the first value is not actually a valid color value.

I'm definitely against it.
It's something very implicit, almost magic, and it always becomes a source of errors by implicitly reducing extensibility, at the very least.
To elaborate: suppose someone uses something like that colors="species" and it works.
Someone else on the same team uses the same data source for some other plot in the same document and decides that the DS needs a column named species. And everything explodes.
Pandas has the same problem with its indexing, for example. I haven't used it in more than a year, but the last time I checked, the issues were still there - all the magic just breaks everything with even minor updates. And debugging it is a nightmare.
To summarize - everything should be as explicit as possible. If something is already implicit, it's not a good excuse to add even more implicit stuff.

[bryevdv]

In both cases I'd think any changes to the defaults should be for 3.0 to avoid breaking existing plot appearance for users of bokeh 2.x.

Tangentially this gives me an idea related to major versioning: we won't guarantee that minor releases won't break code but we could guarantee that the same code won't look different. I will raise that in the other issue, though, lets not get off track here.

I'd consider the default size to be important not just for how it looks, but for how usable it is. When coloring by category as in this plot, it can be difficult to make out the colors of small dots.

This is also explicitly one of my concerns with how our output looks, relative to the others. If we had automatic and better default colormapping, we could pick colors that are highly distinguishable by default. Then perhaps the small size woud affect usability less. But we don't have that.

@p-himik what is a compromise that makes colormapping still explicit, but also much easier and simpler than it is currently? Currently it requires something like

from bokeh.palettes import Spectral6
from bokeh.transform import factor_cmap
fill_color=factor_cmap('fruits', palette=Spectral6, factors=fruits))

and I can state unreservedly that that is alot more work than many users want to have to do just to get a nice colormapping. Not even just the actual code, it's a bunch of "stuff" that they have to navigate unfamiliar docs to try to learn before even getting there. Simply specifying some palette as a default would go a little way:

from bokeh.transform import factor_cmap
fill_color=factor_cmap('fruits', factors=fruits)

But you still have to provide the unique factors. We could potentially defer that (if asked to) e.g

fill_color=cmap('fruits')

where cmap is new thing that looks at the actual column at some point an "tries to do a sensible thing" (again: when asked to) Is that explicit enough? It would still require an extra import. In my ideal world there is a way to get this (explicit magic, only when asked) but also not require more imports.

[p-himik]

I think it's good!

In this case, I think reusing factor_cmap is possible - omitting factors would just make them automatically computed based on the field and the data source.

It would still require an extra import

Glyph functions do a lot of stuff. cmap or factor_cmap can just create a named transform that can be created manually without any imports, which an appropriate glyph function would then turn into a proper transform specification. So it would be more data-driven, at least at the point of initial creation.
Something like

p.circle(color=dict(type='cmap', column='fruits'), ...)

[mattpap]

It would still require an extra import

p.circle(color=dict(type='cmap', column='fruits'), ...)

This prevents any hopes for auto-completion and won't provide a focused docstring. In fact, we would like to proceed the other direction and reduce usage of dict type in place of well defined data structures. However, we could appease to both sides and add bokeh.all module, which would export most of bokeh's high-level functionality, at the same time not degrading import bokeh's time.

[bryevdv]

I agree that it would be good to move away from dicts as they are not discoverable. Rather than bokeh.all I would just put more of these things in bokeh.plotting since that is what they will be used for. In the past I was somewhat negative on transitive imports just for rearranging API, but only because they are a little more difficult to document. But we can figure that out.

@p-himik re:

In this case, I think reusing factor_cmap is possible - omitting factors would just make them automatically computed based on the field and the data source.

This is definitely an option. The reason I suggested cmap is 1) because it is shorter and 2) as long as we are offering explicit magic, it might as well be really good magic. e.g. a new cmap could detect numeric values and add LinearColorMapper by default when appropriate

---

Summarizing the current discussion as I understand it so far:

• make colormapping simpler as described above in the 2.x timeframe
• change default visual style (e.g. larger, add light border) in the 3.0 timeframe