[Lens] API for Styling Lens Embeddables

[clintandrewhall]

@wylieconlon asked I create this issue to track/discuss theming of Lens Embeddables in Canvas.

Canvas now supports Lens Embeddables. We'd like to work with the Lens team to define and utilize an API for altering various visual attributes of a visualization from our context.

Background

Canvas allows users to define their own CSS style definitions for any Canvas element. This flexibility has made Canvas easier to customize. While we don't expect Lens visualizations to duplicate these granular levels of style flexibility, as Lens approaches GA and visualizations are added to Canvas workpads, the expectation of being able to customize at least some parts of the visualization will be there.

This is something we may be able to leverage in Elastic Charts or other HTML-based embeddables. We're currently exploring options.

Feature Request

While this list may not be exhaustive, we'd like Lens Embeddables to support changing the following attributes:

• Font, including family, style, weight and size
  • It might be prudent to define classes of text-- like label, heading, primary or secondary-- which can customize the above. Viz like Metric might have primary and secondary, for example.

• Palette, including a gradient option

• Line and Border, including color, width, and style (dotted, dashed, etc)
• Background, including color, opacity, perhaps image?
• Fill, including color, opacity
• Scale

We can certainly update/flesh out this list as the conversation proceeds. Thanks!

[elasticmachine]

Pinging @elastic/kibana-canvas (Team:Canvas)

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[flash1293]

There is no generic "dark mode" flag, will something like this just be done with the detailed color settings?

I wonder whether we can distill this list into a typescript interface and make it part of the expression context like the "searchContext". This way visualize can integrate with it as well (I guess Canvas has the same requirements there). cc @ppisljar

[wylieconlon]

I'm concerned about defining an API that ignores the visualization subtypes, and is trying to be too broad- is it possible that what we actually want is a "Lens styling editor" which can be configured differently for the XY charts, pie charts, tables, etc?

[ppisljar]

i agree with @wylieconlon proposal. in canvas visualizations will have arguments that allow you to override the default sytling, for example pie function has font and palette properties. We plan to follow the same with our chart functions, for example metric_vis function has a property font as well as colorSchema which unfortunatelly doesn't use the pallete (something we should definetelly align on)

then of course editor needs to be registered with canvas for every function, which would expose the ui to configure this. we are not providing canvas ui's for our chart functions, but canvas team could definitively implement them, and i would suggest to do so if you find yourself in need of a chart that we support (for example tagcloud ?).

so i think lens team should do the same, xy_chart function should have font property and palette property, probably all the others (i am wondering are they not there already maybe?). however as lens is not GA yet i would suggest canvas team not to try to implement editor for xy_chart function at this point but rather wait until it becomes a bit more stable.

What I think would be very valuable (and this issue is the start of it) is to start listing things that are common across different functions/charts in our teams and start aligning on those. for example lets all use the same font function to configure fonts for our charts, and lets all call the argument for that configuration the same.

Clint's list is a good start, but i think its important that we don't just list those, but add a function (existing or a link to an issue describing it) that you should use and the argument name and type.

for example:

• charts should allow font configuration. they should use font argument type which can be produced with font function
• charts should allow pallete configuration. they should use pallete argument type which can be produced with pallete function
  ^^ here actually i think we have a problem as we are all working with different pallete types and this needs to be aligned first
• if chart allows you to configure a specific color it should use color argument type which can be produced with color function

[wylieconlon]

@ppisljar I'm not sure I see it in your proposal above, so I want to clarify: the way that Canvas is using both Lens and Visualize charts is using the Embeddable API, through a custom wrapper function. Nothing in our current APIs would let the Canvas editor distinguish between a "Lens pie chart" and "Lens table", or "Visualize pie chart" and "Visualize table"- because the only thing available is the ID of the saved object. Do you see the problem, and do you have a proposed solution?

I would expect two possible solutions:

• We accept a limited set of styling options that are shared by all visualizations
• We build a new type of editor component that is able to read the Visualize and Lens saved objects and construct the right type of UI for styling them.

[ppisljar]

my proposal is that canvas uses expression functions direclty. Its fine that there is a way to add embeddable, but if embeddable is based on expression canvas should allow you to "inline" the embeddable, basically replacing embeddable with actual expression powering it. This is when canvas users would get full control over pallets, fonts, all the settings pretty much.

when using embeddables, i am not sure we can really do something for "all the embeddables". it will be hard to enforce all embeddables are using some parameters passed on the input, also we probably want a fallback in case the parameters are not provided. Currently color pallete is something that is configured on the chart level and its different for every chart. Most likely also those settings won't make sense for every chart, and i guess users will be confused if they are setting the color pallete (in canvas) and the chart doesnt change (either because we forgot to use that input or because its irrelevant .... for example in table chart)

[clintandrewhall]

@wylieconlon While a provided UI is useful, it won't be everything Canvas needs. We'll want to default colors/font/etc programmatically as well as provide one-off customization to the user.

@ppisljar We shouldn't limit this to the realm of expressions, (e.g. "we'll place a parameter in the expression"). I agree that having these customizations there is useful as well as germane... but we can't discount programmatic customization.

I think we can get around this with my forthcoming proposal on defaulting in Expressions. But I hope we can find a great way to pass styling/theming through an embeddable to a Lens/Chart renderable easily.

[wylieconlon]

@ppisljar Your proposal of using the Lens functions directly is not something that I'm comfortable doing until we are GA, because we intend to change the API soon. The same goes for Visualize: we should find a solution that lets us style the embeddable from the outside.

@clintandrewhall If we don't provide an editor for use by apps like Canvas, then Canvas will have to provide the same kind of styling options for all Lens visualizations. I think it will be a better user experience with a UI that is able to understand the type of visualization.

[clintandrewhall]

@wylieconlon I'm not arguing against a UI. I'm saying I'd prefer it not be the only avenue of styling Lens visualizations. If a user has 10 Lens viz on a Canvas workpad, I don't want them having to style each one individually because Canvas has no way to manipulate it programmatically.

[ghudgins]

Related visualization issue: #2207

[stratoula]

I am closing this as work for canvas has been deprioritized. We are in discussions on allowing styling changes as fonts etch but we are tracking them on different issues