Date: 2026-07-14
Context: The user (operator) said the chip dock in the FreshCards-inspired mockup would "get very ugly very quickly" as the system grows. They asked me to think about alternatives without building yet. This doc captures the options I considered and a clear comparison so the operator can read it cold and form a view.
Mockup reference: https://preview.mockup.freshvibeapps.com/portal-mockup.html — the chip-dock version that triggered this conversation.
The chip dock has 4 chips today (deployments, previews, inventory, settings). User said it gets ugly as features grow. Concrete numbers:
We need an architecture that scales to 20+ meta-surfaces (deployments, previews, inventory, audit log, billing, support, teams, databases, secrets, webhooks, regions, themes, plugins, marketplace, etc.) without the UI getting worse as we add things.
What it is: The current mockup. A horizontal row of chips at the top. Click to expand.
Why it fails: Doesn't scale past 5-6 chips. The user already said this.
What it is: A command palette (Linear/Raycast model). Hit a hotkey, type to search, click a result.
Pros: Scales to 1000s of items. Keyboard-driven.
Cons:
Why it fails: Wrong for an operator who uses the panel in short bursts and doesn't want a learning curve. Fine for power users; not for this.
What it is: iOS/Android pattern. 3-5 tabs across the bottom. Always visible. Tap to switch.
Pros: Mobile-native. Fast. Discoverable. Capped at 5 things.
Cons: On a desktop monitor, the bottom is dead space and it looks wrong. The operator is on desktop 80% of the time.
Why it fails: Right for mobile, wrong for desktop. Doesn't compose with both.
What it is: VSCode/Photoshop model. Vertical strip of icon-only chips, with hover-to-expand.
Pros: Discoverable. Scales to ~30 items. Standard pattern.
Cons:
Why it fails: Wrong for the operator's mobile usage.
What it is: Click a level to go up. Suits deep content (file trees, settings categories) not parallel surfaces.
Why it fails: Deployments + Previews + Inventory + Settings are SIBLINGS, not parent/child. Breadcrumbs are for hierarchies.
What it is: ONE main surface visible at a time. Below it, a thin row of "nearby surfaces" — siblings, recent, suggested. The siblings change based on context: if you're looking at a deployment, the siblings are {previews for this project, deploys for this client, history}. If you're at home, the siblings are {deployments, previews, inventory, settings}.
Pros: Scales — the siblings list is always short because it's context-filtered. The operator sees what matters now, not everything.
Cons: Requires the system to know "what's nearby" for any given context. That's a real piece of logic. When the system gets it wrong, the user is stuck.
Verdict: Strong option. The "smartness" is the cost. Easy to get wrong.
What it is: Each card has its own actions inline (Open, Preview, Docs, auth_mode, history). The chips at the top are SECONDARY nav for cross-cutting concerns (settings, inventory, all projects). The cards ARE the navigation.
Pros:
Cons:
Verdict: Strong option. Most scalable. The cards-as-nav model is the most "FreshCards way."
What it is: Not a Cmd+K palette — a VISIBLE bar at the top. Type "deploy" → shows the deployments surface AS YOU TYPE, with the existing filters below it auto-applied. Type "pre" → shows previews. Type "set" → shows settings. Empty bar shows the curated 4-6 chips.
Pros:
Cons:
Verdict: OK option. Lighter than Cmd+K but still search-heavy.
What it is: The search bar is always there. As you type, the suggestions ARE chips. The chip row only appears when the search bar is empty.
Verdict: Same as 8. Solves the "what if there are 30 chips" case but the operator doesn't type to navigate.
What it is: Each "view" is a URL. /deployments, /previews, /inventory, /settings. Browser back works.
Why it fails: Loading cost per switch. The operator uses mobile; back button is sometimes hard to hit. Loses the "one screen, switch between surfaces" feel.
Same as 10 but with a tab bar at the top. Each tab is a full page. Loading cost on switch.
What it is:** Remove the global chips entirely. Each card has inline links to {previews for this project, deploys for this client, history of this project, settings}. Settings gets a corner button. Inventory is hidden behind a "View all" link on the cards. **The cards are the universe.
Pros:
Cons:
Verdict: Most scalable. Most risky to demo without real data.
What it is: FreshCards doesn't have a global nav at all. It has:
Pros:
Cons:
Verdict: Right for a long-term app the operator uses 4+ hours/day. The portal isn't that. The portal is a "check it 2x a day for 5 minutes" thing.
For the operator, who uses the portal in short bursts on mobile and desktop:
Option 12 (cards ARE the nav) PLUS a small "settings" corner button.
The chip dock disappears. Each card has its own inline actions. The filter chips stay (they're attached to the deployment list, which is the main content). Settings gets a corner button on the user chip. Inventory gets a "View all deployments" link on the cards. New meta-surfaces are added to the corner area or to a small overflow menu.
Why this wins:
The risks:
Backup plan if the user doesn't like option 12: option 6 (hub-and-spoke with context-aware siblings) is the second-best. The siblings list stays short because it's context-filtered. But it requires the system to know "what's nearby" which is real logic.
Backup plan if the user doesn't like 6 or 12: option 2 (Cmd+K palette) as a power-user feature, plus option 1 (flat dock) for the curated 4-5. The palette for the long tail, the dock for the common case. This is the GitHub/Linear model in practice.