Keep the single column — fix every rule inside it. Single-line project rows, sub-trees split into labelled Boards / Views / Quality clusters, global tools demoted to a pinned bottom strip, and a pinned working set that keeps the default height bounded while still letting four products stay open at once. This is the direction that preserves the thing A gives up.
Identical constraints to Alternative A — the same answers, applied to a different shell.
Your "monogram" for boards and views is read here as monochrome — single-colour line glyphs. Say the word if you meant literal two-letter monograms and I'll redraw the board rows in both docs.
Nothing structural moves. One dark column, projects listed in it, boards nested underneath — exactly the mental model everyone already has. What changes is that the column finally obeys rules: one icon language per level, colour only as identity, boards and views visibly different species, and a bounded default height.
The reviewer who checks six products every morning sees six trees, in one glance, with no menu in between. Alternative A has to replace that behaviour with pinned tiles and a cross-project My Work; B just keeps it.
At 50 products a naïve list is 1,600 px before a single board. B is only viable if the default rendering is bounded — which is what the pinned working set in §03 does.
Top to bottom, and why each block sits where it does. Pins 1–8 are marked on the column; 9 describes something that gets deleted, so it has nothing to point at.
The collapse control moves out of the top bar and into the sidebar it controls. The DEV badge stops being an absolutely-positioned rotated element clipping over the logo and becomes an inline chip.
A real ⌘K entry point at the top. Today JQL search only exists inside the All Tickets page; at 50 products search stops being a convenience and becomes the primary way people navigate.
Home · My Work · All Tickets. Cross-project by definition, so they sit above the project list rather than inside it. My Work is new and carries an unread-style count.
The user's own projects, expandable, multi-expand allowed. This is the block that makes B viable at scale: it's what renders by default, and it's bounded by the user, not by the catalogue.
Colour tile · name · mono key chip. Chevron appears on hover at the left; the settings cog becomes a ⋯ menu, also hover-only. Four permanent controls become one.
Micro-labels against a guide rail. Boards get full-weight monochrome glyphs plus the colour dot; views get 60% opacity. That weight step is the entire board-vs-view distinction — no extra chrome.
Everything not pinned, behind one row that states the count. Expanding reveals a filter field and single-line rows. This is where the other fourteen live without costing a pixel until asked for.
Agent Studio, Reports, Configurations. Visited monthly, so they get the position that matches. Their nine-, six- and three-row sub-menus open as flyouts, not inline expansions — that alone removes the failure mode where one report visit buries every project.
The 44 px footer slab with avatar, name, email and logout is deleted. Preferences, Admin Management and Application Preferences move into the top-bar avatar menu.
This is the section that decides whether B is viable. A solves scale structurally by rendering one project; B has to solve it by bounding what renders by default. Three mechanisms, in order of importance.
Only pinned projects render as expandable trees. A new user's pins are seeded from their project_members rows, so the sidebar is useful on first load without any setup. Everything else is one collapsed row away.
Typing in the projects filter narrows both pinned and unpinned by name and key. At 50 products this is faster than any amount of scrolling, and it's the same interaction as A's ⌘P — just inline.
A per-user toggle: keep one project expanded at a time. Off by default — collapsing someone's tree when they open another is hostile — but available for people who pin eight products and want a short column.
B's height is bounded by how many projects a person pins, not by how many exist. That's a genuine solution to catalogue growth — 200 products cost nothing if you pin four. What it does not solve is the person who legitimately pins eight QA-enabled projects: they get a column that scrolls, and no amount of grouping fixes that.
A has no such ceiling because it never renders more than one project. If you expect several people to work across eight-plus products daily, that difference is the deciding factor between the two directions.
The project row is where most of the current sidebar's weight comes from: 48 px tall, four permanent hit targets, three of them rarely wanted. B halves it.
| Control | Today | Alternative B |
|---|---|---|
| Expand chevron | permanent 28px button | hover-only, overlays the tile |
| Project icon | bare emoji, 15px | emoji in a 22px colour tile |
| Name + key | two stacked lines, 44px | one line + mono key chip, right-aligned |
| Settings cog | permanent, admins only | inside the hover ⋯ menu |
| Row height | 48px | 32px |
This work is shared between both directions and should be built regardless of which shell wins. The breadcrumb takes over project identity and the board switcher; the per-screen page header is deleted; Create, search, notifications and the account menu land on the right.
Also shared with A, and also independently shippable — this is the piece that closes the literal ticket. Today: eight hardcoded project emoji in CreateProjectDialog.tsx, thirteen board icons in boardIconCatalog.ts. Both expand.
| Level | Symbol | Today | Proposed |
|---|---|---|---|
| Project | colour emoji in a tinted tile | 8 hardcoded | full native emoji set, searchable, with recents |
| Board | monochrome glyph + colour dot | 13, tinted | ~60, categorised, monochrome |
| View | monochrome glyph @ 60% | none | 7 assigned |
| Global | monochrome glyph | inconsistent | one set, one weight |
B's weaker half, and worth being straight about. A's rail is already the shape of a bottom tab bar, so it translates almost mechanically. B's single tree has no equivalent — on a 390 px screen a drawer containing four expanded projects is a scroll, not a navigator.
| Width | Sidebar | Top bar | Notes |
|---|---|---|---|
| ≥ 1280 | 264px, persistent, resizable | full breadcrumb + search + Create | the design above |
| 1024 – 1279 | 264px, collapsible to 56px rail | search collapses to icon | collapsed rail keeps pinned tiles |
| 768 – 1023 | 56px rail by default, flyout on hover | breadcrumb truncates | flyout carries the full sub-tree |
| < 768 | drawer, projects collapsed by default | 40px: hamburger · title · search · avatar | plus a bottom quick bar — see below |
On phones, B's drawer opens with every project collapsed — including pinned ones — because four expanded trees on a 390 px screen is a 900 px scroll. That means mobile behaves differently from desktop, which is a real inconsistency and a real thing to explain to users.
A bottom quick bar (Home · My Work · Create · Search · Menu) carries the frequent destinations so most mobile sessions never open the drawer at all. That's the mitigation, and it's the same bar A uses — but under A it's the same navigation as desktop, and under B it's an additional one.
Under B, pins aren't a convenience — they define what the sidebar renders. That raises the stakes on the client-vs-server question you flagged.
No backend, works offline. But because pins are the sidebar here, a new device shows the seeded default rather than the user's real working set — a more visible regression than under A, where pins are just a rail shortcut.
One small per-user record. Given pins carry more weight in B, and given the multi-platform plan you described, this is the safer default here even though you'd accept client-side.
Same shape as A — build against a small pins interface so the storage can move later — but under B I'd lean server-side sooner. The seeding rule (pin every project the user is a member of, on first load) blunts the worst of the client-only case, and is worth building either way.
B's headline advantage: phases 1–3 are essentially one file. App.tsx is untouched until the top-bar phase, and the routing model never changes.
Monochrome board glyphs with colour dots, emoji-in-tile projects, icons for the seven bare view rows, native emoji picker, board catalog to ~60. Identical to A's phase 1 — build it before the shell decision is even final.
BOARDS / VIEWS / QUALITY grouping, 32 px rows, ⋯ menu, Agent Studio / Reports / Configurations moved to the bottom with flyout sub-menus. Confined to AppSidebar.tsx.
PINNED group, ALL PROJECTS collapsed directory, inline filter, member-seeded defaults, accordion toggle. The phase that makes B survive the catalogue.
Shared with A. Touches App.tsx and every project page's header block.
Collapsed rail flyouts, mobile drawer defaults, bottom quick bar. The largest divergence from today's behaviour.
Reports moving from mid-column to a bottom strip is a learned position. Expect hunting for the first week. Mitigated by ⌘K search reaching them by name from day one.
Used in three places — collapsed rail, bottom workspace strip, and the ⋯ menu. Needs open/close delays, keyboard equivalents and touch fallbacks, or it becomes the most-complained-about part of the design.
If pin seeding is wrong — someone is a member of fifteen projects — the sidebar is worse on first load than it is today. The seeding rule needs a cap (say, six) and a clear empty state.
Desktop expands pinned trees, mobile collapses them. Defensible, but it is two behaviours to document and test rather than one.