Janus puts every destination it has into one dark scrolling column — global tools, admin config, a nine-entry agent menu, a six-entry report menu, and every project with every board and every view underneath it — while a 44 px top bar holds two controls. This document audits why that reads as noise, sets the rules a fix has to obey, and carries two alternatives forward. Alternative C (top-led, full-bleed content) has been retired — the current content width is fine, which was C's entire reason to exist.
Answers to the open questions this document originally posed. Everything downstream — both alternatives, both detailed designs — is now built on these as fixed constraints.
You hop between products only now and then, but people who sit across several products have to check in on all of them. Both A and B stay in play precisely because of this split — A optimises for the resident, B for the reviewer.
Projects are products in a product company. New ones arrive; old ones stay on the board. Design target is 50+. This is the single most consequential answer — it's what makes A's constant-height property valuable and forces B to bound its default rendering.
Projects keep expressive colour emoji — with a much larger palette. Boards and views go monochrome. Today's palettes are far too small: 8 hardcoded project emoji and 13 board icons.
No demand for full-bleed reports. This retired Alternative C, whose main advantage was handing the timesheet and capitalization tables the whole viewport.
The per-screen project header goes; the top bar absorbs identity, board switch and Create. Roughly 73 px returned on every project screen, and the duplicated identity ends.
Client-side is fine, server-side welcome. Noted tension: users will be on web, mobile web and a planned Electron app, and localStorage doesn't cross devices. Both detailed docs recommend building against a small pins interface so storage can move without UI churn.
Mobile-web users must not find this hard to use. That is now a first-class constraint on both alternatives, not a follow-up. It also changes the scoring: A's rail translates almost mechanically into a bottom tab bar, whereas B's single tree has no natural phone equivalent and has to diverge from its own desktop behaviour. Each detailed doc carries a full breakpoint table and phone mockups.
Below is a faithful reproduction of today's sidebar, built from AppSidebar.tsx — real row heights, real icon sets, real ordering, populated with a realistic four-project workspace. The amber pins mark problems 1–11; two more are structural and have nothing in the column to point at. The dashed line is where a 900 px-tall browser window cuts it off.
Global rows use monochrome lucide line icons. Projects use free-text emoji at a different optical weight and baseline. Boards use lucide again — but tinted with an arbitrary per-board hex. Read top-to-bottom you cross three visual registers in about 400 px. Nothing tells you those registers mean anything, because they don't.
board.color is painted straight onto the icon glyph. Eight saturated hues appear inside a navy column with no shared semantic — blue isn't "in progress", rose isn't "at risk". They're just eight competing attention magnets. Meanwhile the one thing that is semantic — which board is a sprint board vs. a kanban board — has no visual expression at all.
Inside an expanded project, "Core Platform" (a board) and "Backlog" (a saved view over the whole project) sit at the same indent, same row height, same font. The only difference is that the board has a coloured icon and the view has nothing at all. So the weaker distinction gets a colour and the stronger one gets a blank.
Future Sprint Board, Backlog, All Tickets, Roadmap, Test Cases, Test Cycles, QA Dashboard — all bare text. Once a QA-enabled project is expanded that's a seven-item wall of unscannable labels. The eye has no anchor to jump to; you read every line.
AGENT_SIDEBAR_ENTRIES currently yields seven agents; plus "All Agents" and "PRD Generator" that's nine sub-rows. Expanded Reports adds six more. Expanded Configurations adds three. All three auto-open on route match and never auto-close — so visiting one report can permanently push every project below the fold for the rest of the session.
A single FileText in an otherwise text-only sub-list. Small on its own, but it's the tell: there is no rule, so exceptions accumulate.
Chevron button · emoji · two-line name+key stack · settings cog — roughly 48 px tall, four hit targets, three of which are only occasionally wanted. Twenty projects is 960 px of chrome before a single board is visible. There is no search, no filter, no favourites, no recents.
Workflow Templates, Admin Management, Application Preferences and Preferences occupy prime vertical space directly above Projects. These are visited monthly. Boards are visited hourly. The layout ranks them equally.
"Apps" wraps a single Specsmith link in ~90 px of chrome — label, row, two separators. Heavy framing for one item, and it sits above Projects.
The shell header has a sidebar toggle and a bell. Then ProjectBoard renders its own sticky header underneath with the project emoji, name, description, view tabs and Create. Two stacked bars ≈ 117 px of chrome, and the project identity is stated twice — once in the sidebar, once in the page. Nothing tells you which board you're on.
At 4rem the projects become bare emoji and every board, backlog and roadmap link disappears. Collapsing doesn't give you a compact navigator; it gives you a dead rail you have to un-collapse to use.
CreateProjectDialog.tsx offers eight hardcoded project emoji — 📋 🚀 🦞 🧪 ⚡ 🎯 🔧 💎 — and boardIconCatalog.ts offers thirteen board icons. At twenty products every third one already collides; at fifty, the icon stops carrying any identity at all and becomes decoration. Not pinnable to a row because it's a property of the pickers, not the column.
useIsMobile() flips at 768 px and swaps the sidebar for an 18 rem Sheet drawer — containing exactly the same overloaded tree, complete with the nine-row Agent Studio and the six-row Reports menu. That isn't a mobile design; it's the desktop one, scrolled. With mobile web now a stated requirement this is a first-class defect rather than a nice-to-have.
Every mockup in this document is populated with the same fixture — chosen to exercise the awkward cases rather than the easy one.
These are independent of which alternative wins. If a proposal breaks one of these, it's the proposal that's wrong.
A level is either all-emoji, all-monochrome-line, or all-nothing. Never two. Mixed registers inside one list is the single biggest source of the current noise.
A project or board colour may tint a container — a tile, a dot, a 2 px rail. It must not tint a glyph. Glyphs stay monochrome so the eye reads shape, not hue.
A board is a place work lives. A view is a lens over work. They need visibly different treatment — grouping, weight, or indent — not the same row with a different icon.
"Where am I and what can I do here" is the top bar's job — breadcrumb, view switch, Create, search. "Where can I go" is the sidebar's. Today both are half-doing both, twice.
The layout must be judged at 20 projects × 3 boards, not at 2 × 1. Anything that scales linearly in vertical space fails. Favourites, search, or one-project-at-a-time are the only real answers.
Narrow mode is for people who want screen back, not people who've stopped navigating. Boards must remain reachable at every width — via flyout, via search, or by staying visible.
Mobile web is a stated requirement, so 390 px is a design target rather than a degradation. The information architecture may stay the same; the containers must not. Today's drawer fails this by carrying the desktop tree verbatim.
A fixed list of eight emoji cannot identify fifty products. Any palette that a person has to curate by hand will be too small within a year — so either it's genuinely large, or it's the platform's own set.
This is the part that fixes the complaint in the ticket, and it is adoptable on its own — it works under both remaining alternatives and needs no backend change. project.icon keeps storing an emoji; board.color keeps storing a hex. Only the rendering rule changes, plus the two pickers get much larger sets. Picker designs are drawn in Alternative A §06.
| Level | Symbol | Size | Colour rule | Why |
|---|---|---|---|---|
| Global destination | lucide line icon | 16px | inherits sidebar foreground, 70% when idle | These are app-level nouns; they must recede behind project content. |
| Project | colour emoji inside a rounded tile — palette expands from 8 to the full native set | 22px tile / 12px glyph | tile fill = project.color @ 16%, 1px border @ 30% | Containing the emoji gives it a consistent optical box and turns the colour into an identity swatch instead of a floating glyph. Rule 08 forces the palette open. |
| Board | lucide line icon — catalog expands from 13 to ~60 | 14px | monochrome + a 5px dot in board.color | Rule 02. The hue still identifies the board, but it stops fighting the glyph for attention. |
| View | lucide line icon, newly assigned | 14px | foreground @ 55% — one step quieter than boards | Views become scannable, and the quieter weight encodes Rule 03 without extra chrome. |
| Section label | none | 11px caps | foreground @ 45% | Labels are structure, not destinations. |
Split the sidebar in two. A narrow 52 px rail holds everything global and permanent. A 236 px context panel shows exactly one project — the one you're in — with its boards and views, reached through a project switcher at the top. The giant accordion disappears entirely: you never scroll past twelve projects to reach the thirteenth, because only one is ever rendered.
App.tsx, a switcher component, and "what project am I in" has to be resolved on every route — including /browse/<KEY>, which today already does this lookup, so the hard part exists.Keep the single column. Fix the rules inside it. Projects become single-line rows with a colour tile and a mono key chip. The sub-tree splits into labelled Boards / Views / Quality clusters against a guide rail. Search moves to the top of the sidebar. Reports · Agents · Configurations drop to a compact pinned cluster at the bottom so projects own the scroll. Admin and preferences move into the top-bar avatar menu.
App.tsx — it is essentially a rewrite of one file.Scored against the six rules plus the practical questions. Green = solved, amber = mitigated, red = unaddressed or made worse.
| A · Rail + Context | B · One Sidebar, Disciplined | |
|---|---|---|
| Icon coherence (R1–R2) | solved | solved |
| Board ≠ view (R3) | solved — grouped | solved — grouped |
| Context vs. destination (R4) | breadcrumb + board switch | same top bar — shared work |
| Survives 50 products (R5) | constant height — renders one project | bounded by pins, not by catalogue |
| Collapsed still navigates (R6) | rail + breadcrumb switcher | rail + hover flyouts |
| Mobile web (R7) | rail → bottom tabs, 1:1 translation | drawer must diverge from desktop |
| Palette outlasts catalogue (R8) | native emoji + ~60 icons | identical |
| Several products open at once | no — replaced by My Work + pins | yes — this is B's reason to exist |
| Reviewer persona | served by new affordances | served natively |
| Resident persona | served natively | fine, with more on screen |
| Worst realistic column | one project, never scrolls | 8 pinned QA projects still scrolls |
| Files touched | AppSidebar, App.tsx shell, +2 new components | AppSidebar; App.tsx only for the top bar |
| Rough effort | medium–high | low–medium |
| Pins storage | works client-side; server better | load-bearing — server recommended |
| Risk of regression | medium — new shell | low — one file at a time |
| Detailed design | Alternative A → | Alternative B → |
Everything above the midpoint is a tie — both directions fix the icon and hierarchy complaints equally well, and the top-bar work is literally shared. The real choice is between “several products open at once”, which only B gives you, and “mobile web + fifty products”, which only A handles without compromise. Your Q1 answer says both personas are real, so this is a genuine trade rather than a right answer.
Both directions are now fully designed. What's left is one choice, one clarification, and one product question that's bigger than this ticket.
My recommendation is unchanged and now better supported: ship the icon grammar first as its own PR — it closes the literal ticket, it's identical under both alternatives, and it needs no shell decision. Then pick the shell. Two of your answers moved the needle toward A: fifty growing products, and mobile web as a hard requirement. The answer that argues for B is that reviewers who genuinely live across six products lose something real, and B is roughly half the build.
Monochrome board glyphs with colour dots, emoji-in-tile for projects, icons for the seven bare view rows, single-line project rows, native emoji picker, board catalog 13 → ~60. One PR. Identical under A and B.
Breadcrumb with board switcher, global search, Create, account menu; delete the per-screen project headers. Byte-for-byte the same under A and B, and worth ~73 px on every project screen.
Read the two detailed docs and pick. Everything in steps 1 and 2 survives either way, so this decision can be made after that work is already in flight rather than blocking it.
You said monogram for boards and views. I've read it as monochrome — single-colour line glyphs, no per-board hue on the glyph — since that's what the question was asking about, and a literal CP for "Core Platform" would scan worse than a shape. Both detailed docs are drawn that way. If you meant literal letter monograms, it's a contained change but it touches every board row in both directions.
Native is my recommendation — zero curation forever, users already know it, stored value stays a single emoji string so nothing migrates. Curated is more visually consistent and immune to an emoji that renders flat on one OS, but it's a list someone owns forever and it will still be too small for somebody.
You said old products stay on the board. At fifty that's fine if there's a way to mark one dormant, otherwise the switcher's tail and every search grows forever. The cheap version is a per-user hide from my sidebar toggle, which needs no schema change and no policy debate. A real project.status field is better but is bigger than SDLC-372. I'd ship the per-user hide and raise archiving separately.
Both docs recommend building against a small pins interface backed by localStorage, so storage can move later without UI churn. Worth knowing how close the Electron app is: if it's near, going straight to server-side saves a migration and matches the cross-device story you described.