responsive-ui-engineering

Responsive UI Engineering

Purpose

Make the interface adapt structurally rather than merely shrink between two screenshots.

When to use it

• For every new or materially changed user-facing layout.

Instructions

1. Identify the content hierarchy and minimum viable space for each region.
2. Use intrinsic layout, sensible min/max constraints, wrapping, and container behavior before adding breakpoints.
3. Define how navigation, columns, tables, controls, overlays, and dense content reflow—not only their widths.
4. Test representative narrow, medium, and wide viewports plus 200% zoom.
5. Test long labels, localization expansion, empty values, large datasets, soft keyboard/touch behavior, and safe-area constraints when relevant.
6. Preserve readable line lengths, touch targets, focus visibility, and logical DOM order at every layout.
7. Capture evidence at the narrowest and widest supported states and at each structural transition.

Output format

A responsive contract: hierarchy, layout transitions, overflow behavior, viewport/content cases tested, failures found, and screenshots or observations.

Anti-patterns

• Desktop first followed by arbitrary media-query patching.
• Hiding required content on small screens without an equivalent path.
• Horizontal page scrolling, clipped focus rings, or visual order unlike DOM order.

Verification checklist

• No important content or action becomes unreachable, clipped, or ambiguous.
• Layout transitions follow content pressure and remain usable at zoom and with long text.

Apply context-discovery before broad scanning: use a supplied context capsule first; otherwise check context frontmatter freshness, read .agent/context/routing.md, load only relevant summaries, and verify critical claims against source.