Responsive navigation adaptation

Problem Context

• A product supports compact phones, tablets, desktop browsers, resizable windows, split-screen modes, foldable postures, or embedded webviews.
• The same destination set may need bottom navigation, rail, drawer, side navigation, or top overflow depending on space and destination count.
• Users may be mid-task with filters, drafts, scroll position, selected objects, badges, an open drawer, or keyboard focus when the layout changes.
• Responsive navigation adaptation sits near global navigation, bottom navigation, navigation drawer, side navigation, header, tabs, breadcrumbs, utility navigation, and safe-area handling.

Selection Rules

• Choose responsive navigation adaptation when the navigation surface itself must change across viewport, posture, orientation, or destination-count constraints.
• Keep destination identities, labels, icon meanings, badges, order, and selected state consistent across adapted surfaces.
• Use bottom navigation for three to five compact primary destinations, rail or side navigation for medium and expanded persistent access, and drawer or labelled overflow for secondary or too-many destinations.
• Define what happens when a drawer is open, focus is inside navigation, the keyboard appears, or a user resizes while an unsaved task is in progress.
• Use global navigation, side navigation, bottom navigation, navigation drawer, or header patterns directly when the layout does not need to adapt across surfaces.
• Do not hide destinations, rename labels, reset state, create duplicate primary nav surfaces, or move current-view actions into destination navigation at breakpoints.

Required States

• Compact width with bottom navigation or labelled compact menu.
• Medium width with navigation rail, condensed side surface, or drawer-triggered navigation.
• Expanded width with persistent side navigation or global navigation plus local navigation.
• Destination count overflow state where secondary destinations move into a labelled More or drawer surface.
• Current destination preserved across resize, rotation, split-screen, and back/forward navigation.
• Open drawer or menu state that adapts safely when the viewport changes.
• Keyboard, safe-area, system gesture, and bottom inset state on compact mobile.
• Badge, unread, filter, scroll, draft, and nested route preservation state.
• Focus recovery state when an active control moves, hides, or changes container.
• Failure state for unsupported layout, missing destination, or layout measurement delay.

Interaction Contract

• The adapted surface changes presentation, not the user's destination model.
• A selected destination remains selected and reachable after every breakpoint transition.
• Labels, accessible names, badges, and order stay stable unless a documented overflow rule moves lower-priority destinations.
• Opening, closing, resizing, rotating, and keyboard appearance do not trap focus in hidden navigation.
• If a destination moves into overflow, the overflow control is labelled, reachable, and announces where the destination went.
• Navigation adaptation preserves local route state, filters, drafts, scroll position, and unsaved work unless a real route change requires warning or save.

Implementation Checklist

• Inventory destinations, hierarchy, priority, badge needs, frequency, and action-versus-destination ownership before choosing responsive surfaces.
• Map compact, medium, expanded, landscape, split-screen, keyboard-open, and dense-destination states to concrete surfaces.
• Use container or viewport breakpoints tied to available navigation space, not arbitrary device names.
• Keep labels and accessible names consistent across bottom bar, rail, drawer, side nav, and overflow variants.
• Preserve selected destination, nested route, filters, drafts, scroll, and badge state through layout transitions.
• Move focus to the equivalent adapted control or main heading when a focused navigation control disappears.
• Test safe areas, system gestures, software keyboard, high zoom, long localized labels, and screen-reader navigation at every breakpoint.
• Avoid rendering duplicate primary destination sets unless one is clearly an overflow or temporary disclosure surface.

Common Generated-UI Mistakes

• Treating responsive navigation as separate mobile and desktop information architectures.
• Changing destination labels or order across breakpoints.
• Removing low-priority destinations instead of putting them in overflow or a drawer.
• Resetting the selected destination or local state on resize.
• Duplicating primary destinations in bottom navigation, a drawer, and a side nav at the same width.
• Using icon-only compact navigation for unfamiliar destinations.
• Letting safe areas, bottom sheets, or keyboards cover navigation.
• Leaving focus in a hidden drawer after adaptation.

Critique Questions

• What is the single destination model that all responsive surfaces represent?
• Which destinations stay visible at compact width, and where do secondary destinations go?
• How do current state, labels, badges, route, filters, draft state, and focus survive a breakpoint transition?
• Does any breakpoint duplicate or remove destinations rather than adapting them?
• What happens when the drawer is open or focus is inside navigation during rotation or resize?
• Is this really responsive navigation adaptation, or is the problem owned by global navigation, bottom navigation, navigation drawer, side navigation, or header?