[Frontend] Make WikiArticle usable at phone width #376

Closed
opened 2026-08-25 20:42:15 +00:00 by claude-bot · 2 comments
Contributor

Impact: HIGH

Found in the August 2026 session lifecycle review (#319). (inferred) — this conclusion is drawn from JSX/Tailwind classes, not a running app at that viewport; the arithmetic below is the audit's estimate from those classes, not a measured screenshot.

This is the one visual-layout fix filed in this navigation/attention-focused milestone: it is a single-class change, not a redesign, and without it the article page has essentially no usable body on the smallest common phone width. The rest of the mobile/responsive rebuild is intentionally out of scope here and covered by a separate milestone.

What the user experiences

Opening any wiki article on a phone leaves almost none of the article readable. The infobox sidebar has a fixed width and sits beside the article body with no responsive breakpoint to stack them, so at a 375px viewport the article body is left with roughly 39px of horizontal space.

Evidence

  • webapp/frontend/src/pages/WikiArticle.jsx:1857<div className="flex gap-8 w-full"> wraps the article body and the infobox with no flex-col fallback for narrow viewports.
  • webapp/frontend/src/pages/WikiArticle.jsx:432 — the infobox aside is a fixed w-64 xl:w-72.
  • (inferred) at 375px inside px-6 padding: 375 − 48 (padding) − 256 (infobox) − 32 (gap) ≈ 39px of article body remaining.

Why it matters for a hosted product

The product's stated context of use includes reading and referencing wiki content live at a table, frequently on a phone. This single missing breakpoint makes the article page — one of the product's core content surfaces — effectively unusable there.

Proposed fix

Add flex-col lg:flex-row (or equivalent) to webapp/frontend/src/pages/WikiArticle.jsx:1857 so the infobox stacks above or below the article body below the lg breakpoint instead of squeezing it. This is the audit's P22.

Acceptance criteria

  • The article body and infobox stack vertically below the lg breakpoint instead of sitting side by side.
  • At a 375px viewport the article body has its full available width, not a ~39px sliver.
  • No other layout regression on desktop widths where the two-column layout is intended.
**Impact: HIGH** Found in the August 2026 session lifecycle review (#319). **(inferred)** — this conclusion is drawn from JSX/Tailwind classes, not a running app at that viewport; the arithmetic below is the audit's estimate from those classes, not a measured screenshot. This is the one visual-layout fix filed in this navigation/attention-focused milestone: it is a single-class change, not a redesign, and without it the article page has essentially no usable body on the smallest common phone width. The rest of the mobile/responsive rebuild is intentionally out of scope here and covered by a separate milestone. ## What the user experiences Opening any wiki article on a phone leaves almost none of the article readable. The infobox sidebar has a fixed width and sits beside the article body with no responsive breakpoint to stack them, so at a 375px viewport the article body is left with roughly 39px of horizontal space. ## Evidence - `webapp/frontend/src/pages/WikiArticle.jsx:1857` — `<div className="flex gap-8 w-full">` wraps the article body and the infobox with no `flex-col` fallback for narrow viewports. - `webapp/frontend/src/pages/WikiArticle.jsx:432` — the infobox aside is a fixed `w-64 xl:w-72`. - **(inferred)** at 375px inside `px-6` padding: 375 − 48 (padding) − 256 (infobox) − 32 (gap) ≈ 39px of article body remaining. ## Why it matters for a hosted product The product's stated context of use includes reading and referencing wiki content live at a table, frequently on a phone. This single missing breakpoint makes the article page — one of the product's core content surfaces — effectively unusable there. ## Proposed fix Add `flex-col lg:flex-row` (or equivalent) to `webapp/frontend/src/pages/WikiArticle.jsx:1857` so the infobox stacks above or below the article body below the `lg` breakpoint instead of squeezing it. This is the audit's P22. ## Acceptance criteria - [ ] The article body and infobox stack vertically below the `lg` breakpoint instead of sitting side by side. - [ ] At a 375px viewport the article body has its full available width, not a ~39px sliver. - [ ] No other layout regression on desktop widths where the two-column layout is intended.
Author
Contributor

Picking this up as part of v4.3.0 phase 1 (#514), shipping early as v4.2.3. Stacking below lg and freeing the aside's fixed width when stacked; nothing else in the layout changes.

Picking this up as part of v4.3.0 phase 1 (#514), shipping early as v4.2.3. Stacking below `lg` and freeing the aside's fixed width when stacked; nothing else in the layout changes.
Author
Contributor

Done in PR #515 (merged), shipping in v4.2.3. The article/infobox wrapper is now flex flex-col lg:flex-row, and the infobox aside is w-full lg:w-64 xl:w-72 so it takes the full width once stacked instead of holding its fixed 256 px. The article comes first in the wrapper, so on a phone the infobox lands below the text rather than over it. One render test asserts the classes; desktop layout above lg is unchanged. This was inferred from classes rather than measured on a device, as the issue itself notes; worth a glance on a phone after the v4.2.3 deploy.

Done in PR #515 (merged), shipping in v4.2.3. The article/infobox wrapper is now `flex flex-col lg:flex-row`, and the infobox aside is `w-full lg:w-64 xl:w-72` so it takes the full width once stacked instead of holding its fixed 256 px. The article comes first in the wrapper, so on a phone the infobox lands below the text rather than over it. One render test asserts the classes; desktop layout above `lg` is unchanged. This was inferred from classes rather than measured on a device, as the issue itself notes; worth a glance on a phone after the v4.2.3 deploy.
rbrooks referenced this issue from a commit 2026-09-06 02:00:15 +00:00
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#376
No description provided.