Every list of records is a table, and at mobile width tables scroll sideways #170

New Issue

2026-10-06T08:51:18Z

cgalo5758 commented

2026-10-06 08:51:18 +00:00

The question

The design system makes every list of records a table that scrolls sideways at narrow width, so the columns that matter most, status and actions, fall off the screen. The member's FedWiki sites list is one example: at 390 pixels wide, Status and the row actions are reached only by scrolling.

Current interfaces express a list in other ways too: cards, thin card rows, a table that reflows into stacked label and value blocks, columns that hide by priority at narrow width, a list beside a detail view. Which form does each kind of list take, and does a list change form with the width?

What depends on the answer

Every list page and every list inside a record page, on both surfaces. The design system's flush-list and record-table parts. The screenshot baselines at mobile width.

Options known so far

Research first: how current design systems express a list of records, and when each form is used.
Cards for lists a member reads (sites, plans, invoices); tables kept for lists an operator scans and compares.
One list part that renders as a table when wide and as cards when narrow.

Decided when

The design system names the forms a list can take and when each is used, and the list pages follow it at both widths.

## The question The design system makes every list of records a table that scrolls sideways at narrow width, so the columns that matter most, status and actions, fall off the screen. The member's FedWiki sites list is one example: at 390 pixels wide, Status and the row actions are reached only by scrolling. Current interfaces express a list in other ways too: cards, thin card rows, a table that reflows into stacked label and value blocks, columns that hide by priority at narrow width, a list beside a detail view. Which form does each kind of list take, and does a list change form with the width? ## What depends on the answer Every list page and every list inside a record page, on both surfaces. The design system's flush-list and record-table parts. The screenshot baselines at mobile width. ## Options known so far - Research first: how current design systems express a list of records, and when each form is used. - Cards for lists a member reads (sites, plans, invoices); tables kept for lists an operator scans and compares. - One list part that renders as a table when wide and as cards when narrow. ## Decided when The design system names the forms a list can take and when each is used, and the list pages follow it at both widths.

cgalo5758 added the

kind

design

area/operator-ui area/member-ui labels 2026-10-06 08:51:18 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#170