Settings pages: responsive card layout on mobile (Rules, Users, Tags)

Finn the Weaver — Frontend Engineer

In one breath

Three settings pages that were effectively unusable on phones — Rules, Users, and Tags — now render as scrollable card lists on mobile, with tap-safe action buttons, while the desktop table layout is untouched.

By the end of this chapter you’ll understand:

• What the shared MobileDataCard component provides and how it is reused across all three pages
• How each page conditionally switches between the card stack and the table using the useIsMobile hook
• Why action buttons use ActionIcon size="lg" on mobile and what the 44 px target means

Settings pages: responsive card layout on mobile (Rules, Users, Tags)

Status: Delivered
CAS: CAS-2461
Delivered: 2026-05-12
PRs: #631

What’s new

Three settings pages that previously showed desktop-style tables — Rules, Users, and Tags — now render as scrollable card lists on mobile. Each card presents the row data vertically with tap-safe action buttons. Desktop layout is unchanged.

How to use it

On any phone-sized screen (≤ 768 px):

• Settings → Rules: each rule appears as a card with name, condition summary, enable/disable toggle, and Edit/Delete buttons.
• Settings → Users: each household member is a card with display name, role, and action icons.
• Settings → Tags: each tag is a card with colour swatch, name, and action icons.

On desktop the existing table layout is shown as before — no change.

What changed under the hood

• New shared MobileDataCard component wraps GlassCard with a title slot, optional prefix (colour swatch or badge), stacked label/value field pairs, and an actions slot.
• UserSettingsPage, TagSettingsPage, and RuleTable each conditionally render either the new card stack (mobile) or the existing table (desktop) using the useIsMobile hook.
• All row-level action buttons use ActionIcon size="lg" (≥ 44 px touch target) on mobile.

Why we built it

The mobile UX audit (CAS-2390) found that three core settings pages were effectively unusable on phones: wide table columns overflowed the viewport, row data was clipped, and action buttons were too small to tap reliably. This delivery applies a single shared card pattern across all three pages in one go, closing the overflow and tap-target findings from the audit.

Known limitations / follow-on work

• The card pattern is applied to Rules, Users, and Tags only; other settings pages (Notifications, License) were not in scope for this audit cluster.
• MobileTransactionList (a parallel mobile list component for the Transactions view) was filed separately and is not part of this delivery.

See it as

A restaurant that keeps its full menu for dine-in guests but prints a condensed card menu for take-away — same dishes, same kitchen, different presentation suited to how the customer is reading. The cook does not need to know which format a dish is going into; the front-of-house decides at serving time.

Recap

• MobileDataCard is a shared wrapper component with title, optional prefix, stacked label/value pairs, and an actions slot — one component applied to Rules, Users, and Tags.
• Each settings page checks useIsMobile() at render time and conditionally renders the card stack or the existing table; no API or data model changes were needed.
• All row-level action buttons use ActionIcon size="lg" (≥ 44 px touch target) on mobile in line with the iOS Human Interface Guidelines minimum.

What changed {#what-changed}

This feature shipped in CAS-2461. See: CHANGELOG → 2026-05-18