Treemaps encode shares as areas of nested rectangles
Aliases: treemap · rectangular treemap · hierarchical area
What it is
A treemap is a space-filling hierarchy of nested rectangles, not a node-link tree. Leaf area is proportional to a nonnegative magnitude, while a parent rectangle encloses its descendants and represents their aggregate. Within one parent, child areas show shares of that parent's total. Treemaps fit compact overviews of hierarchical composition and leading items, but area is weak for exact read-off, and internal nodes share physical space with descendants rather than forming independent magnitude marks.
Why it happens
Recursive subdivision partitions the root canvas by child weights and repeats within each child. When values share a unit, are additive, and each parent equals its displayed children, leaf area also remains proportional to global value; local share is leaf area divided by parent area. Spatial containment encodes membership while area encodes magnitude. This overlap saves space but requires readers to understand hierarchy and proportion together. Area judgment, layout shape, and boundary visibility jointly determine performance.
Studying it
Compare treemaps, indented tables, bar-based hierarchies, and node-link trees on largest-leaf lookup, within-parent share, path identification, global leaf comparison, and exact read-off. Manipulate imbalance, value distribution, layout algorithm, labels, and viewport; measure errors, time, path confusion, and confidence. State internal-node aggregation and omitted children, because an error may originate in the data contract rather than the graphic. Transfer any area advantage only to the tested overview task.
Where it stops holding
The area measure needs nonnegative, same-unit values with explicit aggregation semantics. If a parent includes hidden items, deduplication, or a nonadditive metric, visible children cannot silently fill its region. Small area does not imply low semantic importance; consequential tail items may need another route. Pixels do not expose hierarchy, order, and values to assistive technology, and hover alone does not cover touch, keyboard, or static export.
Applying it
- Record entities, parent-child keys, measure, unit, and aggregation at every level; validate the relation between parent and visible children before layout.
- Use area for share overview and labels or details for exact values. Show current parent, path, total, and any unallocated remainder.
- Provide an expandable hierarchical table or tree control exposing name, depth, parent, value, and share, rather than making rectangle position the only relation.
- Test within-parent share, path, and global-leaf tasks. If readers confuse parent and leaf values, revise labels and boundaries or choose a more explicit hierarchy.
Related
- Same group: U2.11.2 Deep-node areas get too small to read; cap the depth · U2.11.3 Layout algorithms fix aspect ratios; thin strips resist comparison · U2.11.4 Adjacent rectangles need borders or gaps to show hierarchy · U2.11.5 Treemaps cannot show negatives or support cross-branch comparison
- Adjacent: U1.04.1 Perceived area systematically underestimates actual area · U1.13.3 Common region can replace the legend for belonging
- Search terms:
treemap·space-filling hierarchy·nested rectangles·part to whole