Funnel charts

[nicolaskruchten]

Funnel charts are kind of interesting because they're kind of like stacked bar charts, with variable width bars, often with sloping sides, which makes for the potential for double-encoding. A standard stacked bar chart has each segment with the same width, and the height of the segment encodes the datum. On the other extreme you can have bars where each are the same height, and the width encodes the datum, like this: https://www.amcharts.com/demos/funnel-chart/

In both of those cases, the area is proportional to the datum. If you start sloping the sides, then the area no longer matches the datum and it's just the height: https://jsfiddle.net/gh/get/library/pure/highcharts/highcharts/tree/master/samples/highcharts/demo/funnel/

So we could maybe add some options to bar to make the version without sloping sides, but it may make more sense to create a new trace type here. We'll want some special legend and color handling, as well as some computations for hovertemplate like 'percentage of total' and 'percentage difference with previous stage' etc.

[nicolaskruchten]

Another way to think about funnels is as lines... The point where two stages meet is the datum in this case, and the sloped segment between the points indicates the 'rate of loss' between points.

[alexcjohnson]

I really dislike the version where the whole side is sloped - I get that this makes the analogy to an actual funnel clearer, but it makes the data value highly ambiguous. But connecting bars with a sloping region in the gap, like the amcharts example does, strikes me as really cool, and would be a nice addition to regular bar charts too. This came up recently, I can't seem to find it now, but it's a great effect for stacked bars with some sort of stack sorting, because it shows you when two series change order in the stack.

At that point it would be fairly easy to imagine this just as another attribute to a bar chart to shift it to symmetric about the size-axis origin, but perhaps enough of the default attributes should change that it's worth making a trace type for it (and just use the bar code to render it)

[nicolaskruchten]

Yup, that about sums up my feelings after writing this up. I wonder if a new trace type might not be better just in terms of usability, rather than having to juggle x and y etc. Also right now this would have to be trace-per-funnel-stage to get the stacking right, which is awkward, so maybe a funnel is more like a pie than a bar actually, in terms of the colouring and stacking behaviour.

[alexcjohnson]

Oh I was thinking of this not as stacked at all, but a single trace of horizontal bars of equal height. That's how the amcharts example does it, and it shows you all the relevant information clearly: the total starting size, the size and amount lost at each stage, and it's intuitive that each stage is a subset of the previous stage.

The way that highcharts example shows it, where the vertical size of each segment is different, strikes me as totally inappropriate. Yes, it shows you the size at each stage (at least if you can figure out how to interpret the sloping sides), but the total stack size is completely meaningless and there's no way to visually see what's lost at each stage.

[nicolaskruchten]

OK, so then a pie-like thing makes sense, if we want to be able to let people have different colours for each stage. I actually think that separate legend items per stage could be problematic if we allow click-to-hide :)

[alexcjohnson]

Related potential use for a bar trace positioned symmetrically about the origin of the size axis: check out the "neutral" trace here https://peltiertech.com/charting-survey-results/:

The final piece we'd need to make this plot I guess is an attr to say "stack this trace on the negative side" for the "hate" and "dislike" traces. Or perhaps that would happen automatically if "neutral" is the third trace in the stack but it has an attribute saying "position this trace symmetrically"?

[nicolaskruchten]

So what can we converge on in terms of an API here? The key question in my mind is: is this pie-like in the sense that one funnel = one trace? Or bar-like in the sense that one funnel stage = one trace?

In general I feel like this is quite pie-like, even perhaps to the point of not actually rendering axes etc.

[alexcjohnson]

Definitely one funnel = one trace. I'm not sure it has any practical implications but to my mind it's much more like horizontal bars than pie. Perhaps we don't draw them by default, but I certainly think we want it drawn on cartesian axes, so that you can overlay it with other traces matching at least the category axis, and probably so you can stack funnels like https://stackoverflow.com/questions/45421748/making-a-stacked-funnel-chart-in-excel

[nicolaskruchten]

Ok for one funnel per trace. It’s very common to want each bar a different color however (much more than to segment each bar like in the image above) so I would want built in support for this, like in pie.

[nicolaskruchten]

• new trace type
• bar-length encoding only, no variable width
• no neck.
• ability to center the thing
• no negative values
• accepts stacking, grouping, overlaying
• x, y (cartesian subplots) with magic to hide the grids
• ability to display on-plot and/or in hover the "percentage of first" and "percentage of previous"
• connecting lines
• ability to hover on connecting area to see delta in hover
• ability place delta% text on the intermediate area

[chriddyp]

• in addition to the delta% (from one stage to the next), it seems like many of the charts have percentages based off the value (value / total)

[nicolaskruchten]

So that's interesting: I guess there are two ways of seeing funnel charts.

It's either "each step contains a subset of the previous step" meaning each unit appears in N stages. Or it's "each step contains a unit in its current position" meaning each unit is accounted for in one stage at a time.

[nicolaskruchten]

Note that at the moment we're not considering building the ability to make the above chart with the sloping sides, as it's very ambiguous/incorrect to encode something with height while you're narrowing the width. @chriddyp do you think it's very important to support this kind of thing with a constant slope?