E3.13.4cascade blocks cross-level comparisondesign

Cascades are a poor fit when levels must be compared

Aliases: cross-branch compare · cascade versus table · hidden siblings

What it is

A cascade opens one path at a time; siblings and side branches are hidden by default. When items under different parents must be compared — prices across cities, similar models under different categories, headcount in two departments — the cascade locks the objects into a serial “change parent, then look at children.” Cross-level comparison needs leaves from different branches in view together. A cascade is navigation, not a comparison table. If the task is comparison, do not use a cascade as the selector.

Why it happens

Comparison depends on several objects being in the visual field at once. A cascade’s child roster belongs only to the current parent; changing parent replaces the whole roster and the leaf just seen disappears. Working memory has to hold “that value in the last city” and find the counterpart in the new roster; load rises with the number of branches to compare. People take notes, open extra windows, or give up and pick from impression. The deeper the cascade, the less cross-branch information can be seen at once.

A multi-select tree, a dual list, or a table can pin leaves from different branches in one view. A cascade cannot pin, because the child view is a function of the parent value; change the function, withdraw the view.

Where it stops holding

When the user already knows the unique target and only needs to walk a path, comparison is not required and a cascade fits. Comparison inside one parent (cities of one province) uses the child roster itself as the table; the cascade is fine. When comparison must cross branches but the end result is still one path, browse first in something that can stay open (table, map, search hits), then write the chosen item back into the cascade field — do not finish the comparison inside the cascade. Screen-reader users pay more for comparison because a serial list cannot glance at a side branch; still less should a contrast task live in a cascade.

Applying it

  • If the task includes “which of these leaves is better,” expose them in a table, an expandable tree, or search results; do not use a cascade as the comparison tool.
  • Let the cascade only mean “I have decided; drop me on a legal path.”
  • If cascade entry must stay, put a read-only cross-branch browse beside it and backfill after a pick.
  • How to check: give a task that must compare leaves under two parents. If people keep changing parent and writing down what they just saw, the structure is wrong.

Related

  • Within the group: E3.13.1 Each next level’s options depend on the parent choice · E3.13.2 A parent change must clear or revalidate the child · E3.13.3 Too many levels make the cascade path too long
  • Adjacent: E3.16 Tree Multi-Select and Parent-Child Coupling · E4.03 Tables
  • Search terms: cross-branch comparison · cascade versus table · sibling comparison

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E3.13.4