Summary

To support data visualization best practices, we've anticipated alternatives to pie/donut/sunburst and have been implementing them as opportunity arises: treemap, icicle, flame.

Merging #1112 ensured that things are in place for mosaic plot, a.k.a. Marimekko or Mekko chart, which is often better than the analogous two-layer pie (sunburst) and sometimes better than the two-layer treemap.

Mosaic plots are often preferred over full, two-layer sunburst such as this. If the secondary partitioning is shared, eg. here, browsers, then sideways comparison is way more feasible than in the case of sunburst or treemap. In this case, the browser order should be shared too.

Mosaic plot is Lens friendly: it works with full-depth partitioning (Lens can't do heterogeneous depth such as general sunburst or icicle/flame). Mosaic plots are often a visual alternative to crosstabs.

Mosaic plot is activated by specifying partitionLayout: PartitionLayout.mosaic in the partition chart config, as usual.

Mosaic plots are great for 3+1 use case, as often, data is multidimensional and two dimensions can be simultaneously interesting.

"Other" slices can be also used, and placed on the top or bottom, irrespective of size, if we want to avoid too small areas:

Mosaic plots are a tool of choice in machine learning, statistics and analytics, as they're great for visualizing contingency tables aka. cross tabulation and they're sometimes good for showing a relationship between two variables:

(Article by Dr. Robert Grünwald)

Mosaic plots are like

• treemaps and icicle/flame, as they partiton the space with rectangles, which are easier to gauge than disk slices and sectors
• icicle/flame, as they follow a specific 1D orientation per layer, rather than 2D tiling aiming at squarish shapes like treemap
• sunburst, as they work best with two discrete dimensions

There's room for future PRs, eg.

• per layer specification of orientation (horizontal, vertical, squarifying) to meaningfully support arbitrary layer numbers (eg. 3)
• more configurability for in-shape text layouting, eg. cropping with ellipsis or vertical and horizontal text alignment (benefitting treemap too)
• code regularization for layout types, as the increasing number of options has made viewModel.ts etc. slightly more verbose and branching (ternaries) than ideal

Alternating among partition layouts, from the follow-up #1120:

Checklist

Delete any items that are not applicable to this PR.

• Any consumer-facing exports were added to src/index.ts (and stories only import from ../src except for test data & storybook)
• This was checked for cross-browser compatibility
• Proper documentation or storybook story was added for features that require explanation or tutorials