Column width should follow the type of content

What it is

Column width is not what remains after an even split. Content-typed column width makes each column obey the perceptual job it has: a short code only needs the widest legal code, money follows magnitude, names take flex space, and a long description must not steal width from a code column just to fill the row. Equal columns look tidy and still wrap fields that must not wrap, while truncating fields that needed to grow, so comparison and identification fail together.

Why it happens

Width decides which characters of a row are on stage at once. Identity codes, statuses, and dates usually discriminate within a fixed character budget; a column narrower than that budget wraps or truncates, splits the identity across two vertical pieces, and lets one field hijack row height. Money and counts need room for the largest magnitude plus a sign, or right-aligned place-value is broken by an overflow mark or a wrap. Names and titles are flex fields; extra viewport width is useful there. Giving every column the same share pretends these jobs need the same horizontal resolution. Header labels are often longer than cells (“last synchronised” versus “3 min ago”). Sizing to the header leaves empty cell space and lowers comparison density; sizing only to the current page lets a longer value on the next page blow the layout. The width to follow is the legal range of that content type, not the strings that happen to be on this screen.

Studying it

Compare three sizing policies on one table: equal split, fit to the longest cell on the page, and min/max widths by field type. Tasks: identify a named row, compare one numeric column, then repeat after turning to a page with longer values. Independent variables: sizing policy, viewport width, whether the sample covers extremes. Dependent variables: unexpected wraps, identification errors from truncation, horizontal scrolls to finish a cell. Logging “which column stole row height” usually points at the mistyped width.

Where it stops holding

On a professional table whose columns can be dragged, the initial widths should still follow type, but after that the user’s setting wins — do not snatch it back on refresh. On a very narrow viewport the type constraints cannot all be met; that is a cue to restructure the table, not to keep squeezing. Icon and checkbox columns have a fixed control size and should not join the flex pool. Type-based width assumes you know the legal range. Free text with no cap can only get a flex column plus a truncation rule; there is no “just right” width to pretend exists.

Applying it

• Sort columns into fixed, flex, and capped: codes and controls fixed, names flex, descriptions capped and truncated or moved into an expanded row.
• Measure minimum width against legal extremes (longest stock quantity, longest personal name, full date format), not against page one.
• If a header is too long, shorten the header or let it wrap; do not widen the whole column to humour the label.
• How to check: load a page of extreme values and a page of short ones. Look for columns that go hollow on short data or wrap on extremes. If a wrap changes row height, retype that column’s width.

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.4 Narrow viewports need a restructured table, not a uniform scale
• Adjacent: E4.04 Sticky headers and horizontal scroll · E4.02 List items
• Search terms: column width · table layout · content sizing