Desktop web adaptation research (2026-10-06)

Status: Draft · Date: 2026-10-06 · Purpose: ground the round-2 desktop board (wireframes/web-app-2). Owner feedback on the 1440px build: "can be better adapted to the web UI/UX". Every claim below carries a URL; where a source does not publish a number, this note says so rather than inventing one.

1. Material 3 adaptive guidance

• Window size classes: compact <600, medium 600-839, expanded 840-1199, large 1200-1599, extra-large >=1600 dp. Large and extra-large exist in the Compose adaptive API behind supportLargeAndXLargeWidth = true. https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes
• Three canonical layouts: list-detail, supporting pane, feed. List-detail shows both panes at expanded width and one at a time below. https://developer.android.com/develop/adaptive-apps/guides/canonical-layouts
• Supporting pane: primary area about 2/3, secondary about 1/3; equal split at medium; below that the support content moves under the main content or into a sheet. https://developer.android.com/develop/adaptive-apps/guides/canonical-layouts
• Feed: single column on compact, a multi-column grid on larger windows, cards sized flexibly "to create visual hierarchy"; the reference grid uses GridCells.Adaptive(minSize = 180.dp), i.e. column count falls out of a minimum card width. https://developer.android.com/develop/adaptive-apps/guides/canonical-layouts
• Pane widths: the supporting pane is fixed at 360 dp and the list pane of list-detail is 360 dp with a flexible detail pane; custom pane resizing offers 360 and 412 dp (search summary of the M3 panes page; the page itself is script-rendered and could not be fetched). https://m3.material.io/foundations/layout/scaffold/panes
• Decide layout at the app level from the window class, keep nested components flexible (size a card from its own container, e.g. maxWidth < 400 narrow vs wide), and always pass all data even if a width hides some of it. https://developer.android.com/develop/ui/compose/layouts/adaptive/support-different-display-sizes
• Navigation: M3 pairs compact with a bottom bar and wider classes with a rail (the 240px labeled sidebar at large is our extension, consistent with Apple below). https://developer.android.com/develop/adaptive-apps/guides/get-started-with-adaptive-apps

Takeaway for us: our WINDOW_BREAKPOINT and the 340 pane / 360 list widths already match M3. Gaps are inside the panes: M3's feed adapts the card to a minimum width, and the supporting pane should carry content that is "meaningful only in relation to the main content".

2. Apple HIG (iPadOS / macOS)

• Sidebar + content + inspector is the canonical three-pane order: sidebar leading (navigation), content centre, inspector trailing (supplementary information, editing tools, metadata). Dividers are 1 pt, panes have sensible min/max sizes, and every pane must be hideable with a toolbar button, menu command and keyboard shortcut. https://developer.apple.com/design/human-interface-guidelines/split-views
• Sidebars: no more than two hierarchy levels; consider auto-collapsing when the window narrows; sidebarAdaptable switches between tab bar and sidebar by width. https://developer.apple.com/design/human-interface-guidelines/sidebars
• Toolbar anatomy: leading = back + view title (+ document menu); centre = common controls, collapses into overflow; trailing = inspector toggle, search, more menu, and the single primary action. At most three groups; prefer symbols to text; no toolbar backgrounds. Search sits at the trailing edge. https://developer.apple.com/design/human-interface-guidelines/toolbars
• Type: default body is 17 pt on iOS/iPadOS and 13 pt (line height 16) on macOS; minimum 11 pt iOS vs 10 pt macOS. Desktop type is smaller than phone type, not larger. https://developer.apple.com/design/human-interface-guidelines/typography
• Pointer: hover feedback comes in three strengths (highlight for transparent controls, lift with shadow for opaque ones, custom hover for large elements); avoid scaling table rows; hit regions around bezel-less elements extend about 24 pt. https://developer.apple.com/design/human-interface-guidelines/pointing-devices
• Keyboard: support full keyboard access, do not repurpose standard shortcuts, reserve custom shortcuts for frequent app-specific commands. https://developer.apple.com/design/human-interface-guidelines/keyboards
• Density: macOS apps should use large displays to "present more content in fewer nested levels". https://developer.apple.com/design/human-interface-guidelines/designing-for-macos
• Layout: restrict text width for readability; order content by importance from the leading/top edge. https://developer.apple.com/design/human-interface-guidelines/layout

3. Product references

• Strava web. The profile page is two columns: a main column (header, calendar, overview, photo feed, charts) and a right sidebar of personal statistics tables. https://support.strava.com/hc/en-us/articles/216917697-Your-Strava-Profile-Page The activity detail page was redesigned (April 2025) as "an immersive, full-screen layout" that leads with route, photos and videos. https://press.strava.com/articles/strava-updates-features-to-help-users-easily-plan-and-share-their-activities Lesson: stats live in a side column, the route hero earns full-bleed only when it is the product (for us the map is a fact, not the product). Pixel widths are not published.
• Meetup web. A full redesign of web shipped October 2025 ("better spacing, stronger contrast, clearer hierarchies"; navigation simplified); mobile followed in December. https://finance.yahoo.com/news/meetup-unveils-fresh-design-gen-130000959.html and https://www.meetup.com/blog/2025-meetup-progress-report/ The sources give no column widths or RSVP-card geometry; the new event-card layout raised iOS RSVPs 20 percent. Treat Meetup as direction only.
• Band (band.us). PC web exists since April 2013 with posts, chat and calendar; Naver positions Band as mobile-first versus Cafe, which is PC-first. https://namu.wiki/w/밴드(SNS) No layout or width documentation found; no concrete values recorded.
• Linear (dense productivity reference). March 2026 refresh: dimmer navigation sidebar so content stands out, headers/navigation/view controls made identical across projects, issues, reviews and documents, tabs more compact with smaller icon and text. https://linear.app/changelog/2026-03-12-ui-refresh Design intent: "information-dense elements carry equal visual weight, navigation recedes", built on alignment of labels, icons and buttons. https://linear.app/now/how-we-redesigned-the-linear-ui j/k move down/up a list. https://shortcut.fyi/linear-shortcuts Third-party marketing-site token dump (not the product): body 14, caption 12, desktop control target >= 40 px (>= 44 mobile), buttons 8x14 padding, 2px focus ring at 50 percent. https://github.com/voltagent/awesome-design-md/blob/main/design-md/linear.app/DESIGN.md
• Notion. Pages are a centred reading column with a per-page "Full width" and "Small text" toggle; a default full-width setting is per database only. https://www.sparxno.com/blog/notion-full-width-layout Lesson: width is a reading choice, offered not forced.

4. Pointer-density values

• WCAG 2.2 AA minimum target is 24x24 CSS px (44 only as the stricter recommendation), so 32-40 px rows are compliant. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• Focus: a 2 px outline at >= 3:1 change satisfies the (AAA) focus-appearance criterion; use it as the rule. https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html
• Type deltas: iOS body 17 vs macOS body 13 (-4 pt); iOS line 22 vs macOS 16. https://developer.apple.com/design/human-interface-guidelines/typography

5. What this means for TwoMore (recommendations carried to the board)

1. Title, count, period controls and primary action share one toolbar row (Apple toolbar anatomy: title leading, controls centre, action trailing).
2. Feed cards adapt to a minimum width and may change shape; a horizontal row card at >= 840 is a legitimate feed variant (M3 feed: flexible sizing; Apple: more content in fewer levels).
3. Detail pages: reading column 680 plus a 340-360 inspector that carries supporting facts (M3 supporting pane 360; Apple inspector trailing); hero media shrinks into the pane.
4. Pointer density is a token set from $expanded: rows 40 px (36 for dense lists), body one notch smaller (16 to 15), hover = lift/outline inside the element, 2 px focus ring, /, j/k, Esc. Hangul needs a larger floor than Latin, so meta text stays 13 (our judgement, not a cited value).
5. Profile uses a main + side column (Strava profile); settings stays list-detail (M3 list 360).

6. Gaps

• Exact Meetup, Band and Strava widths are not published; none were measured. If the owner wants measured values, a screenshot pass on logged-in accounts is the only source.
• The M3 pane pages are client-rendered; numbers come from the Android developer pages and a search summary of m3.material.io.