Default color ramp order

As Schloss et al. shows that quantitative color maps normally have dominant dark-is-more effect, unless there is apparent variation in opacity.

The results suggest that if a design goal is to produce colormaps that match people’s inferred mappings and are robust to changes in background color, it is beneficial to use colormaps that will not appear to vary in opacity on any background color, and to encode larger quantities in darker colors.

I think we should consider two things:

1) Scheme config for config.range should support reverse. For example, many people may want to make their theme reverses the viridis color map by default. (Yes, people can always apply reverse in each spec, but that means that our config doesn’t really support this common theming use case.) Supported

1. Re-consider our default "heatmap" scheme. (It should be reversed?) –

This may be considered as a breaking change, and thus may be harder to do than 1).
That said, I doubt if people really uses config.range.heatmap that often in Vega. (Vega-Lite’s rect and geoshape use heatmap range by default for color – and this is a good time to break it since we haven’t release 3.0)

FWIW, this example is driving me crazy every time I look at it. (Why is yellow the highest value?)

[jheer]

Regarding point (1), you can already do this using the extent parameter. To simply reverse an existing scheme, use "extent": [1,0].

I’m open to using a consistent color map (blues from [0.2, 1]) for all defaults. This might be considered a breaking change though so I will hold back for now. I’d also like to see the new palette that @domoritz mentions!

If you’re OK with the above, how about we close this issue, and raise the question of changing the default as a different issue to track.

[domoritz]

@jheer commented on the color scales today so he might be in favor. Also, I mentioned that Maureen designed a new color palette that might be interesting for us as well.