Pie/sunburst chart - discussion about small slices

[monfera]

Hi @cchaos, I'm looking forward to your input and suggestions on this, textual and image / drawing / interaction alike 🙇

This is a quick example for a sunburst diagram that has vanishingly small slices, potentially subpixel territory even at the outermost ring:

cc @nickofthyme @snide @miukimiu @markov00

[cchaos]

Crudimentary prototype

Essentially, all of the slices that cannot display a label would have a single overlay hover state encompassing all slices. It would highlight that entire section and then onClick would display a tooltip of all the slices and their values.

Static screenshot of after the click event:

[nickofthyme]

@cchaos exactly what I was envisioning! Thanks for mocking up the visual.

I think for the sake of filtering/selection of a specific slice we should allow the tooltip to be interactable, which would be new, such that the user can hover and click on any of the "other" values and on hover the selected slice would be exploded or highlighted.

This is crude example with the limited tools on my mac 😞 (using @cchaos's as a base 😅)

[monfera]

Looks good! Below are a few consequences:

1. The cutoff could/should be configurable, for example, anything smaller than x% (or arc length of n pixels) should be lumped into this "other" group - for example, here, the "other" group is quite large, much larger than the approx. minimum of what can be reasonably hovered over for a tooltip, while still respecting Fitts law.

Note: it may easily be the case that there are numerous slices which are still easy to hover over, but won't have static text labels associated with them due to their small size, ie. no room inside or outside to render text (I'm just trying to make it explicit that the "other" group is mostly a hover-convenience, as vanishingly small slices can't be hovered over. While it may be a point we all agree on, it looks like more than a coincidence that the cutoff on @cchaos's mock just happens to be past Netherlands, which is the last item with a static text label)

2. In case of the sunburst, these vanishing slices can happen anywhere, as also seen on this example. So we need to support an arbitrary number of "other" groups (though not too many, as the very point of the "other" group is that it's hefty enough on its own)
3. There's no bound to the number of slices in an "other" group. So the "tooltip" will potentially need to be scrollable.
4. It's not a conventional hover tooltip, because a hover tooltip would go away before the user has a chance to hover within the over tooltip 😸 So it feels more like a modal overlay, a table component (possibly an infinity revolving scroller) that is in some relation with the pie chart it overlaps - but it could even be outside. As we already have a table component, it shouldn't be written from scratch; but there should be an interfacing option. Another interaction design challenge is to have both a scroll and a hover function in the table. Other questions may come up, like should the table be sortable by name, or by ascending order
5. Due to subpixel slices, it will be the case that hovering over rows with small values will just highlight a single radial line which won't apparently move - could be unintuitive for the user
6. If there's any kind of affordance that relayouts the chart, eg. width or height changes due to enlarging the browser window, or the user configures the pie with a larger radius in Lens, then it'll recompute the basis for what goes into the "other" group. Eg. a larger disk can lead to an arc-wise smaller "other" group, as pointer hit areas become larger. There are a few config options that can influence this. A consequence of this is that there should still be a config option for limiting eg. the count or minimum value or angle of slices in the non-other category, because in this case the other vs. not other classification won't shift around.
7. In case of sunburst, like here, it can happen that even an internal disk/ring has "other" groups. Inner "other"s will, I suppose, always have a common "other" outer sector. Then hovering over such an outer sector should show a tooltip table not only with the country, but also with the product.

I'd like to mention that there are other options for those slices which are too small for static text, but large enough for hovering. For example, if other settings allow it, render their linked text on hover even at the expense of temporarily removing text from nearby slices.

In short, let's continue to distinguish among

• too small to have a text inside, or too small (or just got unlucky) to have a linked text outside
• too small to sensibly hover over
• too small to even tell it apart from neighboring segments

I'll think a bit more—feel free to discuss ideas, or question anything I said or implied.

[nickofthyme]

I agree with everything you said and great clarity on the issues we could run into.

RE: 4 I think the EUI popover type of component is what we need, but not using EUI 😞. Secondly, is it typical to sort sunbursts? I would say that we avoid allowing sorting in a sunburst.

I like the 3 designations you made between the slice "types"

[monfera]

@nickofthyme In point 4 I didn't mean sorting the sunburst slices themselves, but simply, the rows in a tabular, scrollable popup (which is a consequence of the proposal, as there can be an infinite number of items in the tooltip, so it's gotta be scrollable, and also, it's a multicolumn table, because there's name and value / % as a minimum; user may want to see alphabetical or value sorting)

[VijayDoshi]

FWIW I'd encourage us to look at the same scenario but use a hierarchical treemap layout. In treemap the consumer can visually compare the size of the cells, label only the biggest cells and hierarchy can be established via border size. Example: https://finviz.com/map.ashx

[monfera]

Update with the #493 merge:

1. Treemap has been added; it uses the same exact configuration as sunburst (partitioning is a unified implementation) and currently needs to be activated via

   <Partition
   /* ... */
   config={{ partitionLayout: PartitionLayout.treemap }}
   >

   

2. The small slices in pie charts had, in part, been addressed by

   • A. rendering vanishingly thinner lines as the slices get smaller, so the borders don't burn out (partly then fully overpower) the sector fill ink
   • B. tapering off the border thickness toward the center of the pie, to avoid burnout in the middle - ie. the border is not actually a Canvas2d stroke - it's instead a dedicated, very thin pentagonal polygon that appears like a border but vanishes into zero at the center of the chart - based on @markov00's suggestion it's only done if the slice is small (currently, less than 15deg) to avoid visibly tapering off

Burnout before adding 2A:

Residual burnout in the middle after adding 2A but before 2B:

No burnout after 2A and 2B (this shows the tapering off even for larger slices, so its mechanism can be seen, but is no longer currently perceptible):

Again, these don't directly address the grouping of slices into an "other" category, but is related to the discussion about numerous, therefore vanishingly small slices.