[Lens] Add Heatmap option to show cell values

[dej611]

Describe the feature:

Add new control option to show/hide cell values in heatmaps.

Elastic-charts reference: https://elastic.github.io/elastic-charts/?path=/story/heatmap-alpha--categorical

[elasticmachine]

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

[dej611]

Done a first prototype with the feature and it seems there are some overlapping issues in some heatmap configurations.

When there are few buckets on the Horizontal Axis labels seems to be a good fit (even tho there's no contrast evaluation):

When the number of buckets start to be more than 10/15 (for instance with many top values or a date histogram) then there's no fill check for the cell space (both vertically and horizontally):

Perhaps a combination of configurations as min/max font size + overflowConstraints + textContrast may help here. Wdyt? cc @stratoula @markov00 @monfera

[markov00]

For those cases, isn't better to use a table with dynamic colors?
There is also the possibility to paginate the heatmap to avoid very short cells as ML is doing. I can provide you with an example on how to handle pagination.
Few other options are:

• add a different formatter for values (use reduced number of digits or just use multipliers K M G T)
• rotate labels, or better, rotate chart: when you have more columns than rows you can rotate the chart to improve readibility

[dej611]

For those cases, isn't better to use a table with dynamic colors?

Maybe. I would argue that even in the "good" cases it is still better a table.

There is also the possibility to paginate the heatmap to avoid very short cells as ML is doing. I can provide you with an example on how to handle pagination.

That would be helpful to evaluate.

Few other options are:

• add a different formatter for values (use reduced number of digits or just use multipliers K M G T)
• rotate labels, or better, rotate chart: when you have more columns than rows you can rotate the chart to improve readibility

I think that these routes are pretty hard if we want to move forward with this feature. Probably rotated labels are the best thing we could achieve, but that should be a chart feature (I've actually looked for that but could not find an option for heatmap).
Rotating the chart requires the update also the Lens configuration panel accordingly and it is a bit tricky right now.

[stratoula]

Yes, I would really like to see how pagination works!

I see that the legacy heatmap hides the labels when they don't fit in the cell. It would make sense to also have it here (and in the legacy one when we replace it with elastic-charts).

The ideas of rotation and text contrast are also something that I think we should explore.

[dej611]

Just discussed a bit with @markov00 offline and wondering: does it really make sense to enable this feature when it only works for very few cases?

The problems above show that we may think of mitigations for those, but even these mitigations leads to sub-optimal solutions.
For instance not rendering a value label if the cell of the chart is not "big enough" is a very bad solution, as it does not provide value to the final user. He already knows the value range, but is interested into the specific value: not showing it is a non-solution currently for what he is looking for.
Also rotating labels or pagination are kind of half-backed solutions: in one case the solution is required only for technical reasons and the result is harder to read, while for the other case the chart still requires interactivity to show all values, so no particular value when the user wants to project the chart statically somewhere.

Datatables are better off to provide this kind of solution, now that dynamic-coloring/value-based coloring, is available. Would it be a better idea to help the user migrate from a heatmap to a datatable with dynamic-coloring already configured and matching the same palette? What do you think?

[monfera]

@dej611 putting aside the issue of overlap for a minute, one area of improvement that leaps out at us is the vertical alignment of the decimal point within the same column. With this, if the user specifies a monospaced font for the numbers, then the sloppy mess of random numerical alignment, which we get with center alignment, can be solved

[dej611]

@dej611 putting aside the issue of overlap for a minute, one area of improvement that leaps out at us is the vertical alignment of the decimal point within the same column. With this, if the user specifies a monospaced font for the numbers, then the sloppy mess of random numerical alignment, which we get with center alignment, can be solved

Why the monospaced font is a requirement? I see it can speed things up a bit, but I guess it just an implementation optimization rather than a requirement.