💔 Build Failed

• continuous-integration/kibana-ci/pull-request
• Commit: 0331658
• Storybooks Preview
• Pipeline Steps (look for red circles / failed steps)
• Interpreting CI Failures

Failed CI Steps

• Check i18n
• Check Types

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Thanks @markov00 for the ping! Colors are powerful, and their use should be justified, otherwise everything becomes colorful and all meaning is lost. For this reason I favor the greyscale bullet graphs by default, which is also a bit of a standard, unless the user specifically selects a color. Looks way better too I think, but that's a subjective argument

@monfera I see where you are coming from, but if a background palette is provided, and given this palette is following a shading scale as the greens one above, what's the advantage of a grayscale palette?

Also: is it valuable a bullet/gauge chart with no background palette at all as default?

Right now on this PR the default is no bands at all (just ticks placed by d3 linear nice) . @monfera are you suggesting to default to grey bands? I didn’t implement that because I couldn’t see how it would be universally the better choice. I expected people to configure very use case specific bands most of the time instead of just “increasing intensity“. Happy to change though

Thanks @dej611 and @flash1293 for the comments.

[Joe R.] are you suggesting to default to grey bands?

If the scope of the question is bullet graphs: yes, my conviction is that it'd be best to go with more or less the baseline aesthetics.

If the scope is gauge/goal (let's discuss it; see on the bottom): There, defaulting to no band shading, or greyscale band shading would be better than defaulting to color shading.

[Marco L.] but if a background palette is provided

This is more of a question about the meaning of a background palette; its purpose in Lens, and the related modality (statefulness, stickiness) of palette selection than is about bullet graphs. Ie. it's a concern about the Lens implementation and its interaction model, about which your knowledge is vastly superior. Lens design was partly informed by striving for good defaults, so Lens is, or should be conducive to good defaults (whatever consensus emerges on what a good default is, of course).

For example, if the user configured some likely colorful pie chart, or even, got a single-color green bar chart (which I firmly believe will default to greyscale at some point in the future too), and THEN switched to bullet graphs, greyscale should still prevail, in my opinion at least.

Also, we use non-colored things for everything anyway. Labels, text, axis lines, grid lines etc. are rendered with no color for a reason. The bullet graph bands have a bit more heft, but it's not a mandate to color it. It's a choice to channel or not channel color into things.

Currently, the use of color in Lens is somewhat semantic: it serves to differentiate categories.

A few of the reasons for considering no coloring by default:

• Color adds no information here; it's noise
• Useless color distracts (waters up) the attention of the user; color should be used purposefully, as it's such an attention grabbing preattentive visual attribute; see Knaflic's point starting here and till about 11:00 (spoiler alert, our dashboard is the "garage sale" category)
• It's a new chart type and our dasboards are already WAY overcolored and not in a very cohesive way. Introducing a new chart type that doesn't hinge on chroma is a great opportunity to weaken the grip of circus colors ("wanting to use every single crayon in the box")
• As mentioned, bullet graphs are a bit of a standard; unlike most viz, it has a nicely drawn up, explained and shared spec which is often observed in diverse products; and it's nice to stick to the well designed, widely known and identifiable aesthetics, as it shortens time to recognition and reading
• Coloring is not trivial; if we open up that box, the thin measure bar doesn't absolutely need to be black; so it means, there are alternative things to contemplate and decide on

Gauge/goal are controversial chart types, so let's go through a datavis product design process with round table participation from Product, Datavis, Design and Lens implementors before adding the angular gauge/goal chart. For example, Vijay, Design (Caroline) and Datavis all phrased concerns about pies already, so it's not taken for granted that all charts are mandatory, even if we attribute some likelyhood to it. Especially, the timing of the angular gauge/goal is not pressing. Why?

• gauge/goal are considered a problematic chart type, glad to list references if needed
• it doesn't currently exist in Lens; let us give time to contemplate the necessity, as once it's added, it's next to impossible to remove it
• Lens can however add an alternative, which is very often superior
• the user already has fallback: not just bullet graphs but also, vislib for existing charts, Vega etc.
• implementational: more work is needed for a real nice axis layout for the circly
• we don't really know the actual need for gauge/goal; Lens is certainly not attempting to implement all chart types ever, so there's a threshold for what is added or not (and as we try to encourage good practices even via the chart roster of Lens, the threshold is not the same for a sound chart type and a controversial chart type)

Let's go through the "chart type addition" process with the above participation, and gauge (haha) the actual user needs through related metrics, and maybe discuss with some of the users, before committing. We can also proactively communicate: with Lens, Elastic is pursuing datavis best practices and as a priority, Lens adds chart types that are effective and represent good practices for data visualization.

Just realized, whether background palette is a user facing or implementational term, using color as idle backdrop is precisely what would be great to avoid.

Color serves well to highlight things, or sometimes, to convey categorical data, ie. the opposite of background. It can be OK in stylized presentations, just not as a general default. Also, it's worth retaining color freedom to highlight areas that need special attention eg. negative numbers (due to business reasons, or due to the chart's nature)—though in the wild, negatives are often shown in grey too

@monfera thanks for the context. To summarize, these are your recommendations, right?

• Default to shades of gray bands for bullet charts
• Split out angled gauges/goals and go with straight bullet charts initially

Are you opposed to other user specified colors in the bullet bands configured by explicit user action? I think it makes sense to leave that as an option because it seems like there are good uses for color here (e.g classical red “danger” area or, as you mentioned, styling the chart for a nice looking dashboard)

@flash1293 thanks,

Yes for defaulting to grayscale, even if switching chart type from a colorful option eg. pies or bars

Yes, it's good to give coloring options for users, as long as it's not the default, and requires clear expression of intent (ie. this route requires the additional work, clicks etc.) and it's not sticky, ie. just because a user made a colorful one before doesn't imply that their future gauges should start with custom colors.

It'd be great to not offer gauge/goal in Lens at all for the time being, because

• it's a problematic chart type
• the users can get familiar with the bullet graph and may not ever request gauge/goal, or at least not in significant numbers
• users may be directed to our future blog post on the bullet graphs and the dataviz issues inherent with gauge/goal
• we would gain insight into our actual customer demand for gauge/goal, before seriously considering it

Tableau and some other tools don't support gauge/goal charts for a reason. It's possible to fake one with some composition; our analogous thing would be, a Vega chart for the hopefully small % of folks customers who insist on it.

Many analytics companies no longer put gauge, goal and donut charts in their public communication either, as they're passé and give the image of a dataviz-unaware or trailing edge product that's driven by mere momentum of legacy charts.

Of course, offering or never offering gauge/goal, or eventually considering it is in Product's volition to a great degree; I believe we shouldn't add them out of sheer engineering inertia, until there's a robust discussion about them with Product, dataviz and Design.

Short version is, it's the addition of gauge/goal that should need discussion and contemplation, rather than the removal. Ie. I believe it wouldn't be a good idea to add it even if it was implementationally easy. (It's a negative goal, rather than stretch goal or nice to have)

Also, where it'd be placed (split out or not) if/when it gets added, is therefore secondary. In that case it's still good to not advertise them, ie. I'd just make them available under the bullet graph chart type as an optional, "arc" aesthetic, rather than a top-level chart type of its own. I don't feel super strong about this; pros&cons, others may have a better idea. Once the robust process for including these dubious chart types got completed.

Closing as we have an idea about this now