[meta] Gauge/goal/bullet graph discussion in relation to legacy kibana features and open feature requests

[sulemanof]

Features expected in kibana gauge/goal:

• Small multiple for gauges/bullet graph #1235

To Discuss

• Add legend about bands/range with color picker #1236
• Show ticks without labels #1237
• Auto-compute nice ticks for linear scales based on range #1238

Not sure what it means

• fill an empty band with actual value

Nice to have but

• Display the needle/pointer for Gauge/Goal charts kibana#23264

Kibana Cross Issues

• [Meta][Lens] Styling and Chart configurability kibana#57707
• Kibana Goal/Gauge, Unable to set range from higher value to lower value kibana#28053

[markov00]

I think we should carefully design the visualization instead of coping the errors of the existing one.
@sulemanof please ping me when the comparison is done and we can schedule a meeting with design to go through a review of the gauge/goal visualization design

[monfera]

Just for the record, the question of needle is not a gap, as it's not supported by Kibana, so it'd be great to either change the title of the issue, or remove the needle from this specific ticket. As @markov00 implies, it needs deliberation with Product (cc @ghudgins), Design, Datavis and Kibana App to even determine what legacy features should be exposed in Kibana, whether or not that feature is technically possible in elastic-charts.

The automatic tick value determination is a good feature on the face of it, and once the quantitative (usually, Y) projection / axis is extracted out of the Cartesian charts, it could be reused for tick generation.

However, given the use case of the gauge/goal/bullet charts, it's neither always a good idea, nor it is necessary. The reason for this is that the entire point of these charts is to show some value as a fraction of a stable, constant, predetermined domain. Otherwise people who glance at the dashboard will be misled. Moreover it's generally best to determine that data domain in function of natural or customary domains, not driven by currently shown data. For example, show water temperature on a scale of 0..100 degrees celsius, or ratio from 0 to 100%, or car forward speed, 0...250km/h. This means that even the regular "tick nicing" isn't generally doing a good job.

So the upshot is that even under the best circumstances, what the good ticks are are context dependent. Still, niced tick generation should eventually be added, after the Cartesian axis is extracted.