[Lens] Improve range formatting

[flash1293]

Currently the range field formatter uses ≥ and <. This is not optimal as it's hard to understand for some users and we can't show an exemplary tooltip in all places.

Copying over @cchaos writeup how it could work (with Lens as an example):
I still find the format ≥ 0 and < 1000 extremely hard to read. I understand that the distinction is necessary when creating to interval, but I think we can do better for giving understanding to the viewer of the chart.

How I see it is that ≥ 0 and < 1000 is roughly 0 - 999 but not necessarily because it could be 0 - 999.99999 as well. So here what I'm seeing is that the end value depends on the decimal place. What this means is that we still need to use the "Value format" options we have for Top values in Ranges as well.

Then using that format, we can properly display the actual value range instead of the hard to understand mathematical range.

Here are 2 screens that emulate what I mean and a Prototype

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[dej611]

There's also another proposal of using the within semantic of 7≤ and < 10

[wylieconlon]

I like the idea of representing the range by showing the approximate maximum value, but I don't think the symbol - should be used as the separator because it also looks like math. My preference it to join it with the word to, for example:

1024.00 to 2047.99 when given 1024 and 2048 as inputs.

[flash1293]

There are some edge cases where this breaks down. I'm not saying they are blocking this proposal but we should be aware of them.

E.g. if a field has a byte formatter configured, we would want to use that formatter for the individual values. So in the case of @wylieconlon s example from above it would say 1KB to 2KB (hiding the information about which value is inclusive and which isn't). This happens because the byte formatter does some rounding:

The same would happen in other cases as well (e.g. the duration formatter)
There are a few option what to do with this:

• Just ignore these cases - if the formatter does rounding, inclusiveness isn't important anyway)
• Do not apply the configured formatter, but always fall back to one which does have digits after the decimal point to make that clear (this would look ugly for bytes)
• Handle this case in a special way - do 1.99KB even if the regular formatter wouldn't do it

Another example: A field configured to not show digits after the decimal point. In this case, Kibana formats like this:

raw	formatted
5	5
5.99	6
5.99999	6

If a range is configured on this field, the user can use a range like 4 (inclusive) to 6(exclusive). How should we show this range on a chart? I see three options:

• 4 to 6 (this is what the number formatter would do automatically, because it rounds 5.999 to 6) - it's confusing because it hides the inclusiveness
• 4 to 5 (just cutting off everything after the decimal point instead of rounding) - this is confusing as well, because if the user would look at the underlying data, the value 5.6 shows up as 6 in Discover, but is grouped into the 4 to 5 range in the Lens visualization
• 4 to 5.99 (adding decimal points even if the regular formatter wouldn't do it) - based on the case this is confusing as well, because for some values decimal points just don't make sense (e.g. count of items)

[flash1293]

@dej611 Thanks for listing out that proposal (7≤ and < 10) as well. Personally I'm not a fan because I don't think it's an improvement over what we have today. It might be just me but I think it's harder to parse than our current state.

[dej611]

I see what you mean.
The thing I like about that is its consistency with the form format which uses the within math expression as well.

Perhaps having different formats rather than a single universal one could be a potential option - in particular for those open ranges.

[dej611]

Here's a small PoC to add alternative range formatters: master...dej611:feature/range-alternative-formatter (it is using the within format above, but it the copy can be changed as we wish).

[flash1293]

Talked offline with @AlonaNadler and we agreed the edge cases mentioned above are not a problem to implement the proposal as long as we also provide a way to set custom labels. If a user runs into an edge case where they feel the labels on the chart are misleading, they can easily change it, but for the 99% use case it's a net improvement.