Categorical coloring has many variations, and this issue will serve as a checklist of possible functionality to build. This issue will describe both the user perspective and how we will implement this behavior:
Defining a categorical color function
Defining the behavior of colors in terms of functions is the most flexible way to work with colors. If we want to define a simple color function that requires no configuration, we can. If we want to define a complex color function that needs a specific setup, we can do that too.
This approach is heavily based on @monfera's work on the colorAccessorFn property of the pie chart and treemap visualizations, but expressed in a way that is specific to our use case in Lens.
Every color function returns a single color or "no color", given this input:
- The name of this series
- The rank of the series relative to its parent, grandparent, etc
- The name of the series parent, grandparent, etc to get grouping information
- The total number of series at this level, as well as parent and grandparent level
To explain why this is the shape of the categorical color function, we need to look at examples of different types of coloring that this function lets us do.
Keeping the Lens default color function
Lens has two default color functions today, for XY charts and for pie/treemap charts:
- The XY chart color function uses the Rank only. It assigns colors in a round-robin fashion based on the Rank, by iterating over the EUI palette.
- The pie chart color function is similar, but it uses the parent or grandparent rank + depth of the series to choose the color. This is how we get the "sunburst" effect.

Using the name to assign custom colors
Another way of defining a color function is to assign specific values to specific series, such as what the Maps application does:

Assigning colors from an external service
One of the missing features in Lens is the ability to share colors with the dashboard. If we have a color function that takes the Name as input, then we can make this an option that the user can choose.
More possibilities
One of the most interesting color options that we haven't been able to do before is grouped coloring, and this type of color function allows it. One example of this is this palette, where each group gets a unique part of the spectrum:

Which functions should Lens provide users with by default?
- Current default for XY charts, EUI with round-robin
- Current default for pie charts, EUI with round-robin
- Use 7-color Visualize palette with hue-shifting, but no shared state with dashboards
- Pick colors using Dashboard color function
- A grayscale/light blue function
- A function that assigns by name
What does this look like?
At various places in the UI, we will have a "color function picker" which is similar to a palette picker, but with extra options. The user will see the preview of the colors that would be used:

Because many of these functions will require additional arguments, this palette picker might be best implemented in an extensible way. For example, the "choose color by name" function requires the user to type a name, and would be best with an autocomplete.
Picking colors from the function
Once the user configures their color function, we need to actually call the function with the right information. There will be a hierarchy of color functions, and if any function lower in the hierarchy returns "no color" then we will use the higher level. This lets the user override the color function in specific cases, while keeping the overall feel. For example, the user could configure a grayscale palette except for the top ranked series.
- A color function can be provided to the Lens embeddable (mostly for Canvas)
- A color function can be provided by the Lens editor, which lets us share an editor for multiple visualizations
- Each layer can have a color function
- Individual series can have a color function as well
It is up to the visualization to compile the necessary arguments, because the arguments depend on the structure of the data. We can use a lot of the same logic as the pie charts to do this.
Categorical coloring has many variations, and this issue will serve as a checklist of possible functionality to build. This issue will describe both the user perspective and how we will implement this behavior:
Defining a categorical color function
Defining the behavior of colors in terms of functions is the most flexible way to work with colors. If we want to define a simple color function that requires no configuration, we can. If we want to define a complex color function that needs a specific setup, we can do that too.
This approach is heavily based on @monfera's work on the
colorAccessorFnproperty of the pie chart and treemap visualizations, but expressed in a way that is specific to our use case in Lens.Every color function returns a single color or "no color", given this input:
To explain why this is the shape of the categorical color function, we need to look at examples of different types of coloring that this function lets us do.
Keeping the Lens default color function
Lens has two default color functions today, for XY charts and for pie/treemap charts:
Using the name to assign custom colors
Another way of defining a color function is to assign specific values to specific series, such as what the Maps application does:
Assigning colors from an external service
One of the missing features in Lens is the ability to share colors with the dashboard. If we have a color function that takes the Name as input, then we can make this an option that the user can choose.
More possibilities
One of the most interesting color options that we haven't been able to do before is grouped coloring, and this type of color function allows it. One example of this is this palette, where each group gets a unique part of the spectrum:
Which functions should Lens provide users with by default?
What does this look like?
At various places in the UI, we will have a "color function picker" which is similar to a palette picker, but with extra options. The user will see the preview of the colors that would be used:
Because many of these functions will require additional arguments, this palette picker might be best implemented in an extensible way. For example, the "choose color by name" function requires the user to type a name, and would be best with an autocomplete.
Picking colors from the function
Once the user configures their color function, we need to actually call the function with the right information. There will be a hierarchy of color functions, and if any function lower in the hierarchy returns "no color" then we will use the higher level. This lets the user override the color function in specific cases, while keeping the overall feel. For example, the user could configure a grayscale palette except for the top ranked series.
It is up to the visualization to compile the necessary arguments, because the arguments depend on the structure of the data. We can use a lot of the same logic as the pie charts to do this.