[Lens] Metric - Ability to fill color when using a defined maximum

[ghudgins]

Describe the feature: There is no way to set a max AND see coloring for the entire panel at the same time.

Background: The behavior today switches the color controls from filling the entire panel to one of 2 "progress bar" options as soon as the user sets a maximum. I believe the intent behind this is it's a sensible default and best use of the full information in the vis (the progress bar conveys more information than the color alone). However, the user is unable to achieve both a fully colored metric vis while also setting an explicit maximum domain to get the right color stops when using a relative measure like percentage.

Proposed solution (discuss w. @MichaelMarcialis & @gvnmagni )

• Modify the "Bar direction" setting so it can have 3 logical options - Bar Vertical / Bar Horizontal / Fill
• Preserve the existing default behavior
• Consider moving this "Bar direction" setting (with its 3 options) to the primary dimension next to the other color controls.

Describe a specific use case for the feature:
When I am highlighting performance in a known domain
I need to set the metric panel to color the entire panel based on the known domain
So I can further visually emphasize a negative range

Today when you attempt to fill the entire panel with a color you must remove the "max" value which results in an artificial "red" value for "richard" below.

This is the desired configuration if the additional option was available

[elasticmachine]

Pinging @elastic/kibana-vis-editors @elastic/kibana-vis-editors-external (Team:VisEditors)

[flash1293]

Worth noting that you can do this for static “max” by switching the palette to number mode and hard-coding the ranges for the colors. Still leaves the case for dynamic max to be desired

[MichaelMarcialis]

Worth noting that you can do this for static “max” by switching the palette to number mode and hard-coding the ranges for the colors. Still leaves the case for dynamic max to be desired

Correct. In fact, by default, the color ranges are only able to be in number/absolute mode in a metric visualization when no maximum value dimension is populated. Are we saying that it is a common case that our users will instead want to apply a maximum value dimension just to get access to the percent/relative mode in the color range UI? That seems to be the core question here.

[flash1293]

It's not just that, there's also the use case with basic the coloring on a dynamic max. So adding this ability would have two use cases:

• Being able to color the full cell based on a percentage palette bounded by a dynamic max function instead of the value range of the primary values (this behavior can't be replicated with other means at the momnent)
• Convenience function to set a max, then use it to be able to define a percentage palette (helps e.g. when the max is changed at some point, all the palette stops follow along instead of requiring the user to edit every single value)

[gvnmagni]

Coming back for a second on Graham original request, are we sure that is a good idea to allow that behaviour? I am a little afraid of what could happen with lot of colors (side bar + cell background) all together. Could it be allowed only for negative values since there is no way to display a negative bar? Let's discuss it because I believe I have no clear overview of all the possible scenarios and I don't want to jump to conclusions

[ghudgins]

I wasn't proposing to show the bar AND the background fill....but proposing to allow background fill as an option instead of the bar when there is a defined maximum.

[gvnmagni]

I wasn't proposing to show the bar AND the background fill....but proposing to allow background fill as an option instead of the bar when there is a defined maximum.

100% agree!

[flash1293]

I think it's a nice feature, but it would be confusing as "Fill" only makes sense if dynamic coloring is active. Otherwise the user sees this:

• Configures a max
• The get the vertical bar
• Switches to fill
• The tile turns blue (it's just a static color, so it won't help with anything)

Should we disable "fill" as long as dynamic coloring is not enabled?

[MichaelMarcialis]

I think it's a nice feature, but it would be confusing as "Fill" only makes sense if dynamic coloring is active. Otherwise the user sees this:

• Configures a max
• The get the vertical bar
• Switches to fill
• The tile turns blue (it's just a static color, so it won't help with anything)

Should we disable "fill" as long as dynamic coloring is not enabled?

Forgive me for playing devil's advocate here, but is it worthwhile for us to be so restrictive? Would it hurt the user experience to continue to offer fills with a static color in such a scenario? Sure, it wouldn't be actively using the defined maximum value dimension, but I personally don't think it's worth it to throw a roadblock up for the user to keep them from applying a static color until they've removed the maximum value dimension. Perhaps we can just default to dynamic color instead? Thoughts?

Secondarily, with the newly proposed addition of this "fill" option, I'm also starting to wonder if the choice between horizontal bar, vertical bar, and fill should now be a setting in the primary metric dimension (and only appearing when a maximum value dimension is populated). The reason I'm starting to think in this direction is because the color configuration for the bars and fills occurs in this dimension. It feels odd to suggest splitting the configuration across two dimensions in this case (primary metric and maximum value).

[flash1293]

You are probably right, it's not worth adding the additional complexity. This specific combination of settings might not make much sense, but preventing the user from configuring might make it harder than necessary to get the chart they want.

[drewdaemon]

Secondarily, with the newly proposed addition of this "fill" option, I'm also starting to wonder if the choice between horizontal bar, vertical bar, and fill should now be a setting in the primary metric dimension (and only appearing when a maximum value dimension is populated). The reason I'm starting to think in this direction is because the color configuration for the bars and fills occurs in this dimension. It feels odd to suggest splitting the configuration across two dimensions in this case (primary metric and maximum value).

You're right—giving the user some control of the background color in the max dimension editor and the rest in the primary dimension feels disjointed.

But is it a problem that when the user configures a max dimension, nothing in the UI will indicate where to configure these?

[MichaelMarcialis]

Secondarily, with the newly proposed addition of this "fill" option, I'm also starting to wonder if the choice between horizontal bar, vertical bar, and fill should now be a setting in the primary metric dimension (and only appearing when a maximum value dimension is populated). The reason I'm starting to think in this direction is because the color configuration for the bars and fills occurs in this dimension. It feels odd to suggest splitting the configuration across two dimensions in this case (primary metric and maximum value).

You're right—giving the user some control of the background color in the max dimension editor and the rest in the primary dimension feels disjointed.

But is it a problem that when the user configures a max dimension, nothing in the UI will indicate where to configure these?

Yeah, it's definitely an issue worth noting. It's also an issue that is prevalent in other visualization types as well, not just the new metric visualization (with new settings being revealed or hidden in dimension configurations other than the one currently being viewed). It's something we struggle with because of how Lens splits out the configuration of dimensions into separate flyouts (so a single visualization has multiple configuration flyouts).

We could show these sorts of conditional controls in a disabled state with a tooltip to explain how they can be re-enabled, so users are at least aware of the presence of those controls. However, we've tried that direction in areas of Lens previously, only to find that it ends up bloating and overwhelming the interface (given that Lens has so many conditional controls).

In this case (unless others disagree), my first instinct is to note it, monitor for feedback, and take this issue into account if/when we decide to make larger IA changes to Lens in the future (as rethinking the notion of separate configuration flyouts for each dimension in Lens is a very large, foundational change that shouldn't be taken lightly).