Portal navigation — index

Date: 2026-07-14

Context: Picking a navigation architecture for the FreshCards-inspired portal. The chip-dock version in the mockup was called out as not scaling.

Read in this order

1. This file (you're here) — high-level summary and decision points

2. PORTAL-NAV-OPTIONS.md — full option analysis, 13 options, pros/cons each

TL;DR

The user said the chip dock gets ugly as features grow. I considered 13 options. The user is right — the chip dock doesn't scale. My pick is option 12: cards ARE the nav, no chips at all, plus a small settings corner button.

What this means in one sentence

Remove the global chip dock. Each card has its own inline actions. Settings gets a corner button. New meta-surfaces get added as card actions or as small overflow menu items, not as new chips.

The 3 architectures I'd actually propose

1. Option 12 (cards ARE the nav) — my pick. Cards do everything. Settings in corner. New features = new card actions or corner menu items, not new chips. Scales forever.

2. Option 6 (hub-and-spoke with context-aware siblings) — the chip row, but the chips change based on context. Stays short because it's filtered. Requires real logic to know "what's nearby."

3. Option 2+1 (Cmd+K palette for power users, flat dock for the common case) — the GitHub/Linear model. Dock for curated 4-5, palette for the long tail.

The one I'd ship today if forced

Option 12, because:

  • It matches what the user said: "I like the way the cards look."
  • It removes what the user said is ugly: the chip dock.
  • It scales forever.
  • The cards already do most of this (Open, Preview, Docs, auth_mode).

    • The one I'd ship in 6 months if usage grew

    Option 13 (FreshCards actual answer with sidebar), because the portal might become a 4+ hours/day app. The sidebar with collapsible tree is the right long-term answer for that level of use.

    Comparison at a glance

    OptionScales toMobileDiscoverableLearning curveOperator fit
    1. Flat chip dock (current mockup)~5OKyesnonefails at 5+
    2. Cmd+K palette1000sbadno (hotkey)highbad fit
    6. Hub-and-spoke siblings~20OKyesnonegood
    7. Card-with-actions∞greatyesnonegreat
    8/9. Search + chips-when-empty30+OKyeslowOK
    12. Cards ARE the nav∞greatyesnone**best**
    13. Sidebar (FreshCards)∞OKyesnonebest for power users

    The risk with option 12

    Cross-cutting concerns that don't fit on any single card (full-text search, audit log, billing) need a home. Solution: small overflow menu. The overflow menu scales. The chip dock didn't.

    Files

  • `/workspace/.mavis-scratch/PORTAL-NAV-INDEX.md` — this file
  • `/workspace/.mavis-scratch/PORTAL-NAV-OPTIONS.md` — full analysis (10KB)
  • `https://preview.mockup.freshvibeapps.com/portal-mockup.html` — current mockup (chip dock version, for comparison)

    • What I'm NOT doing without explicit go-ahead

  • Not shipping any of this to the live portal
  • Not regenerating the mockup
  • Not touching the live portal code

    • The current mockup stays as-is so the operator can compare chip-dock (mockup) vs cards-as-nav (proposed) by reading this index doc.