[Lens] Set Y-axis extents to custom values

[bobonacus2]

Please can you add the ability to change the Y axis scale on a line graph in Lens

I have a Lens line chart values between 40,000 and 45,000 over a 12 month period so I need to be able to change the scale on the Y-axis to be able to see the trend as it looks just like a straight line

[timroes]

Could you please clarify, if you mean by "scale" changing the range of that axis between linear and logarithmic, or if you mean, that you'd want to change the range it's using (e.g. make the min value of the axis 40k and the max value 45k)?

[elasticmachine]

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

[bobonacus2]

I mean to change the range to either custom extents or set bounds around the values of the data

[wylieconlon]

We've had some discussions about this feature recently and realized that line charts are the only chart type where this makes sense. It would render in a misleading way for bar charts or area charts.

[pgraca-38]

Hi wylieconlon, what would be your decision then? When we want to do X/Y graphs without time (let's say compare population size by coutry/ Temperature over position/etc... ) is there a way to do it in Kibana without the Line graph?

[flash1293]

@pgraca-38 As a workaround for now you can use the aggregation based visualizations instead of Lens - there you can set the axis extends for all types of xy series.

@wylieconlon Let's discuss this offline, but we have to think through how this will work in the Lens UI (e.g. in the case of mixed xy chart)

[VijayDoshi]

Could we have for line charts (and bar charts) an option to constrain the extents to the variation in the data in addition to or instead of fixed extents like what exist in TSVB.

[flash1293]

@VijayDoshi that makes sense. In Visualize we allow the following settings:

• Absolute specified bounds
• "Scale to data bounds"
  • Optional setting to specify the margin of the bounds to the data extents

[maatthias]

Is this feature (scaling the y-axis to the data bounds) planned for a coming release?

[flash1293]

@maatthias There is no fix release date yet, but we take Github engagement (like your comment) into account for our next planning round. As this is a small feature, there's a good chance to make it into one of the next release (>= 7.14)

[ghudgins]

Cloud SRE filled out an ER for an auto y-axis option similar to how TSVB behaves.

[ghudgins]

from give-feedback@:

Bar Chart - Able to set the range to linear, square root, or Logrithmic

[GrahamHannington]

@wylieconlon wrote:

line charts are the only chart type where this makes sense. It would render in a misleading way for bar charts or area charts.

I have field values that indicate the percentage of a particular area of memory in use by each process running on a computer.

I want to chart the maximum value (for a given time period) of that field, by process (probably, top 10). Probably on a vertical bar chart, in descending order.

I'm undecided about wanting to set the maximum Y-axis value on this chart to 100 (that is, 100%).

On the one hand, the percentage values are typically low, so setting a fixed maximum Y-axis value of 100 would mean that, typically, the chart would be mostly white space. On the other hand, perhaps I want that: typically, values that appear on the chart as reassuringly low.

Anyway, this is a use case for a fixed Y-axis (maximum) extent in a chart type other than line. Feel free to push back if you disagree.

[wylieconlon]

@GrahamHannington do you have a screenshot of the chart you're talking about? I think I see what you mean, but it could help to include a visual aid. It sounds like you are asking for a chart type that you can build using the "aggregation-based vertical bar chart" because you are allowed to choose custom extents for the Y axis.

[GrahamHannington]

This particular example has percentage as a secondary Y-axis. It would be nice to have the option to set the Y-axis maximum extent to 100 (percent).

[GrahamHannington]

It sounds like you are asking for a chart type that you can build using the "aggregation-based vertical bar chart" because you are allowed to choose custom extents for the Y axis.

Yes, you're right. I might be wrong about the nature of this issue: I thought it was specific to Lens; I thought the idea was to add this feature to Lens. More broadly, I gather that Lens is the way forward for visualization in Kibana, so the general idea is bring in features from other visualization/panel editors (such as the aggregation-based editor). Am I close?

[wylieconlon]

@GrahamHannington Sorry I wasn't clear: I was suggesting a workaround of using the other chart type which already has the feature.

Your example makes sense, and I think we can use this to make a more nuanced rule than "never use custom extents on a bar chart". If I were to propose a new rule, it is:

• Line charts can have any min/max extent on the Y axis
• Bar/area charts must always include 0. We should throw an error if the user tries to enter a custom Y axis extent that is missing 0. Imagine that you are looking at volume in decibels, which is often represented in negative values but where anything above 0 is beginning to distort. The user could display this as a bar chart from [-32, 2] where the flipping of the bar indicates distortion. However we would prevent them from trying to display [-32, -16] for visualization best practices.

Does this make sense?

[flash1293]

Moving the discussion here:

This is the UI/feature set I'm seeing here based on the discussion:

• Part of y axis config popover
• Separate sections for upper bound and lower bound
• Upper bound:
  • Switch: Scale to data (on by default) - if toggled off, a static value can be provided
  • As long as scale to data is on, input for bounds margin setting (default to 0)
• Lower bound:
  • Switch: Scale to data, maximum 0 (on by default) - if toggled off, a static value can be provided
  • Can’t be toggled off for bar charts
  • As long as scale to data is on, input for bounds margin setting (default to 0)

[wylieconlon]

@flash1293 Yes, that looks like the set of inputs that I was imagining as well. 👍

[flash1293]

Great, I think next the step would be to build a version of this so we can iterate on the specific form elements.

[ghudgins]

@flash1293 should we move the range type aspect of this (linear, log, sqrt) to a separate issue? this setting applies to both the upper/lower bounds.

edit: done #98186

[flash1293]

@ghudgins changing the axis scale should definitely be a separate issue - I thought we had one already, but I can't find it. Could you create one?

[flash1293]

I have a question about how the UI for this should look like. At first I tried to build something like in #67614 (comment) , but I really don't like it:

• There are a lot of inputs, and in most configurations most of them are disabled
• elastic-charts only allows a single margin setting (not separate ones). Thinking about it a bit more, I'm not sure why users might want to tweak this anyway.

So this is my new proposal:

• There are three states: auto (which is the default), data bounds and custom
• Margin can't be configured, it defaults to 5%
• For bar charts, data bounds is disabled and custom extents shows a warning if lower bound is larger than 0
• In auto and data bounds, the lower/upper bound inputs show the current numbers from the chart
• Switching to custom, it pre-populates the values with the current state from the chart

IMHO this balances giving control to the user, keeping data viz best practices and keeping the UI simple.

What do you think @ghudgins @MichaelMarcialis

[ghudgins]

@flash1293 I think your iteration on the original idea has resulted in something that's easier to parse. Lower/upper being on the same line helps me understand the values when setting the extent.

Regarding extents, I think the options you have are probably the best I can think of if we want all 3 options....and I think Data bounds is nice for volatile data...I always think of the price of securities as an example where this is really useful. However, if we keep all 3, I wish there was a better name for Auto as both Auto and Data bound are a form of auto. "Zero to Auto"? "Zero Anchored Auto"? "Zero Anchored"? Those are all bad to me but I really want there to be a good name for this as anchoring to zero is the most honest to the data. Maybe it's okay that Auto is not explicit in its labeling as you can toggle between the options or read the bounds to see what it's doing (this toggle is even faster with 7.13's performance changes).

edit: other ideas: Zero Bound | Data Bound (or maybe Zoom to Data) | Custom

Anyway, the above non-solutions withstanding, it looks good to me.

[flash1293]

@ghudgins I went through the same thought process with the "auto" label - in the end I settled with it because I couldn't find a good name either and "auto" is just short for "Lens will handle it, don't worry".

I think there are good use cases for all three - if we drop the auto bounds though we could simplify the UI and just offer two inputs (lower and upper bound). As long as they are empty, they are working like "auto", once the user fills in a value, it becomes custom. IMHO the extra complexity is worth it though and we should build the three-state UI.

Other possible names for "auto": "zero to data", "default"

[MichaelMarcialis]

@flash1293: Wow, excellent job on refining your original concept! This is really looking great. Here's some of my quick feedback and questions based on your screenshots:

• Would it make sense to hide hide the lower/upper bound fields when custom mode is not selected? Assuming it's not important that users be able to see the values for the lower/upper bounds in the other two modes, it might be nice to remove form elements from the popover that are disabled outside custom mode.

• Similar to @ghudgins' comment, I'd also love to have "Auto" changed to something that separates it from the also-automatic "Data bounds" mode. What about something as simple as "Full" (as in seeing the full scope of the chart)?

• For the bar chart scenario, I wonder if it would be possible to change the current (max 0) label suffix to instead be help text under the field (helpText prop on the EuiFormRow component). Doing so would give us a bit of additional room to be slightly more explanatory like: "Max of 0 for bar charts"

[flash1293]

Would it make sense to hide hide the lower/upper bound fields when custom mode is not selected?

We can definitely do this - I like how it simplifies the popover. I added them because I thought it would be nice to show the currently applied extents, but it's not strictly necessary.

What about something as simple as "Full" (as in seeing the full scope of the chart)?
For the bar chart scenario, I wonder if it would be possible to change the current (max 0) label suffix to instead be help text under the field

"Full" isn't bad - what about solving both of these things by showing the helpText below the button group and explaining the currently selected mode?

• Full: Extend axis to show all data points, always include 0
• Data bounds: Limit extents to range of data points
• Custom (bar chart): Manually specify extents (lower bound has to be 0 or below zero for bar charts)
• Custom (other chart types): Manually specify extents

[MichaelMarcialis]

"Full" isn't bad - what about solving both of these things by showing the helpText below the button group and explaining the currently selected mode?

• Full: Extend axis to show all data points, always include 0
• Data bounds: Limit extents to range of data points
• Custom (bar chart): Manually specify extents (lower bound has to be 0 or below zero for bar charts)
• Custom (other chart types): Manually specify extents

We could do that if there is a concern that users will not understand the difference between the three modes base on their names alone. Personally though, I think the only aspect that definitely requires additional help text is the limitations (0 max) for bar charts in custom mode, so I'd be ok with just that given the appropriate conditions (i.e. bar chart in custom mode).

[flash1293]

@MichaelMarcialis Please check out the PR here: #99203 and let me know what you think