bug(mobile): no navigation below 768px — hamburger menu missing #90

New Issue

marcel · 2026-03-27T12:19:10+01:00

marcel commented

2026-03-27 12:19:10 +01:00

Severity: Critical — blocks use

At every breakpoint below 768px the desktop nav (Documents, Persons, Conversations, Admin) disappears completely. There is no hamburger button, no drawer, no bottom nav — nothing. A user who opens any page on mobile is permanently stranded there with no way to navigate anywhere else.

Screenshots confirm this at 320px and 375px.

Options

Option A — Hamburger + full-screen overlay drawer

A button (☰) in the top-right of the header opens a full-screen or slide-in drawer containing all nav links, the language switcher, and the user avatar/logout. This is the most common and well-understood mobile nav pattern.

Pros: universally recognised, scales to any number of links, can also house language switcher and user actions, freeing header space.
Cons: requires one extra tap to reach navigation; not thumb-reachable if hamburger sits top-right on large phones.

Option B — Persistent bottom tab bar

A fixed bottom bar with 4 icons+labels: Documents | Persons | Conversations | Admin. Always visible.

Pros: zero extra taps — navigation is always one tap away; thumb-reachable; shows current section at a glance.
Cons: occupies ~56px of vertical space permanently on every page, reducing document viewer height; 4 items is at the upper edge of what works in a bottom bar (5 is too many); the Admin tab is a power-user action that arguably doesn't belong in prime real estate.

Option C — Hamburger with bottom-anchored trigger

Like Option A but the hamburger button is at the bottom-right (floating action button style), making it thumb-reachable.

Pros: thumb-friendly; doesn't permanently consume vertical space.
Cons: FAB-style navigation is less conventional and can conflict with other floating actions.

Recommendation: Option A (hamburger, top-right, slide-in drawer)

Reason: this app's primary interaction is viewing and browsing documents, not switching sections. Permanently consuming 56px for a bottom bar (Option B) measurably shrinks the document viewer — the most important UI element. A hamburger drawer is the correct trade-off here. The Admin link in particular is used rarely and should not occupy a persistent tab slot.

Implementation notes:

Trigger: hamburger icon (☰) top-right in the mobile header, 44×44px touch target
Drawer: slides in from the right, full-height overlay with backdrop-blur or dim background
Contents: all 4 nav links (44px row height each), language switcher, user name + logout
Close: tap outside, swipe right, or ✕ button
Current route highlighted in the drawer with brand-navy background or brand-mint left border
The existing language switcher in the header top bar can be removed on mobile once it lives inside the drawer

## Severity: Critical — blocks use At every breakpoint below 768px the desktop nav (Documents, Persons, Conversations, Admin) disappears completely. There is no hamburger button, no drawer, no bottom nav — nothing. A user who opens any page on mobile is permanently stranded there with no way to navigate anywhere else. Screenshots confirm this at 320px and 375px. --- ## Options ### Option A — Hamburger + full-screen overlay drawer A button (☰) in the top-right of the header opens a full-screen or slide-in drawer containing all nav links, the language switcher, and the user avatar/logout. This is the most common and well-understood mobile nav pattern. **Pros:** universally recognised, scales to any number of links, can also house language switcher and user actions, freeing header space. **Cons:** requires one extra tap to reach navigation; not thumb-reachable if hamburger sits top-right on large phones. ### Option B — Persistent bottom tab bar A fixed bottom bar with 4 icons+labels: Documents | Persons | Conversations | Admin. Always visible. **Pros:** zero extra taps — navigation is always one tap away; thumb-reachable; shows current section at a glance. **Cons:** occupies ~56px of vertical space permanently on every page, reducing document viewer height; 4 items is at the upper edge of what works in a bottom bar (5 is too many); the Admin tab is a power-user action that arguably doesn't belong in prime real estate. ### Option C — Hamburger with bottom-anchored trigger Like Option A but the hamburger button is at the bottom-right (floating action button style), making it thumb-reachable. **Pros:** thumb-friendly; doesn't permanently consume vertical space. **Cons:** FAB-style navigation is less conventional and can conflict with other floating actions. --- ## Recommendation: Option A (hamburger, top-right, slide-in drawer) Reason: this app's primary interaction is viewing and browsing documents, not switching sections. Permanently consuming 56px for a bottom bar (Option B) measurably shrinks the document viewer — the most important UI element. A hamburger drawer is the correct trade-off here. The Admin link in particular is used rarely and should not occupy a persistent tab slot. Implementation notes: - Trigger: hamburger icon (☰) top-right in the mobile header, 44×44px touch target - Drawer: slides in from the right, full-height overlay with `backdrop-blur` or dim background - Contents: all 4 nav links (44px row height each), language switcher, user name + logout - Close: tap outside, swipe right, or ✕ button - Current route highlighted in the drawer with `brand-navy` background or `brand-mint` left border - The existing language switcher in the header top bar can be removed on mobile once it lives inside the drawer

marcel referenced this issue

2026-03-27 12:22:01 +01:00

improvement(mobile): move language switcher out of mobile header into navigation drawer #103

marcel added the ui label 2026-03-27 12:28:16 +01:00

marcel referenced this issue from a commit

2026-03-27 12:39:13 +01:00

feat(#90): add hamburger menu and mobile nav drawer below 640px

marcel referenced a pull request that will close this issue

2026-03-27 12:40:40 +01:00

feat(#90): add hamburger menu and mobile nav drawer below 640px #104

marcel closed this issue

2026-03-27 15:48:21 +01:00