Narrow viewports need a restructured table, not a uniform scale

What it is

When the viewport narrows, a table must not shrink as a whole. Uniform scale drives type, column width, and hit height under readable and tappable floors, and the comparison surface exists only on paper. Table reflow is a different structure that still serves the original job: key-value cards, a two-stage master-detail, or a few key columns plus a way to inspect the rest. Scale changes size. Reflow changes how a record is read to the end, and how it is compared, on a narrow screen.

Why it happens

A table’s comparison advantage is column alignment, and alignment needs horizontal resolution. When that resolution runs out, two failures appear. One shrinks everything: type drops below a reading threshold, row height drops below a hit threshold, alignment is still there but cannot be seen or tapped. The other keeps type and jams the table sideways: a row has to be assembled with horizontal panning, and by the time the next row is compared the column has already slid away — alignment is split across time. Reflow admits that the horizontal budget is gone, and changes the task shape: a row becomes a key-value card, comparison moves between cards; or the identity column stays, and the rest expand one at a time. Either way, “every column on stage at once” is dropped on purpose to buy reading and pointing. Uniform scale buys neither; it just prints the desktop table at an illegal physical size.

Studying it

Run the same comparison and identification tasks on a desktop table, a uniformly scaled narrow table, and a card or master-detail reflow. Measure readability (read-aloud errors), pointing (misses), comparison accuracy, and horizontal pans needed to finish a row. Independent variables: viewport width, reflow strategy, which columns are kept. Dependent variables: completion, pan distance, whether people still feel they are “using a table.” If shrinking breaks reading and tapping first, while reflow slows comparison but still finishes the job, structure should change rather than size.

Where it stops holding

A table of two or three short columns may still be a table on a phone; reflow is surplus. Experts on a landscape tablet who still need multi-column comparison can keep the table and pan — that is admitting the comparison surface is still alive, not scaling it. Print and projection have physical lower bounds; scale will ruin type before reflow is considered, so change the page or the type area. Turning every row into a wholly different card layout drops magnitude alignment, and the old comparison task may need new sort and filter to compensate. Reflow is not free.

Applying it

• Name one reflow for the narrow viewport: a key-column list, row-as-card, or master-detail — not a whole-table scale.
• On reflow, keep the identifier and one or two comparison fields; send the rest to detail. Do not pile every column back onto the card.
• If multi-column comparison must survive, keep type size and row height, allow horizontal pan, and keep the identity column present while panning.
• How to check: answer the original comparison question on the target narrow screen. If the system text size must be enlarged to read, or rows cannot be hit, you are still scaling. If the question can be answered by filtering and then reading cards, reflow has taken the job.

Related

• Within the group: E4.03.1 A table is a surface for comparing attributes, not for reading a single record · E4.03.2 Right-align numeric columns and left-align text columns · E4.03.3 Column width should follow the type of content
• Adjacent: E4.04 Sticky headers and horizontal scroll · E4.08 Split views and master-detail · E4.19 Dialog size and responsiveness
• Search terms: responsive table · table reflow · card reflow