Mac app only. The toolbar has one capsule of actions (Export first, as today, then the lens's own buttons), then search on its own at the far right, as in NetNewsWire. The sidebar footer borrows Things and Mail. The empty-project pane answers Bettina's interview.
Decision record — 3 Oct 2026. This page is the record of the UX logic; the markdown spec (docs/design-desktop-nav-toolbar-rearrangement.md rev 3) mirrors it. Every frame is labelled today, DECIDED or REJECTED in its chrome bar; the reasons sit in the commentary under each section.
| # | Decision | Chosen | Not chosen, and why |
|---|---|---|---|
| 1 | Trailing toolbar | One actions capsule (Export first, then the lens's buttons) + Search on its own, always rightmost | Export as a third, separate group (first draft of this page): rejected, Export belongs in the capsule as today. Search inside the capsule (today): rejected, it loses its own input affordance when wide and its own identity when narrow. |
| 2 | Search field | Today's expanding control, moved into its own glass capsule with its grey fill removed | The native .searchable field: decided in the morning, rejected in the afternoon by a spike. Attached to the detail column it gave that column a hard minimum width (938 pt) and the split view overflowed, pushing the projects column off the window's left edge — the failure the fit-to-width model exists to prevent; main at the same widths was clean. The grey .quaternary fill (today): rejected, a grey pill inside the glass pill. Tight toolbar, built 3 Oct: a runtime visibilityPriority = .user on the search item makes the tools fold into » first and the open field stay (Photos' behaviour); the chevron sits trailing with search before it, where Photos/NetNewsWire put the magnifier after it — only AppKit's NSSearchToolbarItem gets that, so it is banked for an NSToolbar move, not now — the brief with every measurement is docs/design-desktop-toolbar-appkit.md. Rejected the same day: magnifier + popover below a width threshold (wrong on lenses with one action; popovers are not the idiom), and the .status zone (the centre on macOS 26; folds into » with the magnifier inoperable). |
| 3 | Lenses without search yet | The field is present and inert, placeholder stays “Search” | Today's disabled button: replaced (a disabled control is the one grey thing in the toolbar). An interim placeholder “Search isn't available in this view yet”: rejected, alpha, multi-lens search lands this week, no interim redesign. |
| 4 | Project lens | No search, unchanged | It gets one when project-wide search (⌥⌘F) ships; nothing changes today. |
| 5 | Where New Project / New Folder live | E: +⌄ in the sidebar's toolbar, a plain menu, on the sidebar column (as built 3 Oct: before the system toggle, which macOS always puts last) | A today's grey in-list row (missed in a user interview). B labelled footer, C footer + explaining menu, D footer + Settings gear: rejected, see section 2. Menu(primaryAction:): rejected, a plain menu makes New Folder discoverable. |
| 6 | The +'s name | Tooltip and VoiceOver label “Add”, one new key, Apple's own translations | Reusing “New Project…” (misleading, the menu also holds New Folder) or the panel prompt “Add” (couples two surfaces): rejected. |
| 7 | Sidebar toggle | The system's, untouched | Hiding it and placing our own: withdrawn in the plan review, a hand-placed toggle lives in the sidebar column and vanishes with it, and the fit-to-width logic drives the system one. |
| 8 | Empty project | 2b: primary “Choose Interviews…”, files and folders, through the existing Add Files panel | 2a “Add Files…” (shipped string, files only): rejected. A drop-only pane (today): a dead end for anyone who doesn't drag. |
Implementation facts the frames assume: the +⌄ replaces folder.badge.plus, on the sidebar column so it shows on both sidebar paths (as built 3 Oct 2026; the AppKit outline is the flag-on path in use); the leading group (list toggle, back/forward, title) is unchanged; nothing in this work touches the fit-to-width model (projects column vs report width).
Each lens, today and proposed. The subtitle is the shipped per-lens subtitle; the counts are illustrative.
Decided (3 Oct 2026; design doc §4.3–4.4, rev 3). Leading is unchanged: the list toggle, then the back/forward group with its current behaviour, then the title and per-lens subtitle. Trailing has two groups:
.searchable was spiked and rejected the same day, see the decision record). Wide: room for a real input field. Narrow: still its own control, and focusing it expands it in place. Multi-lens search is next, so search's prominence will only grow.Not chosen. An earlier draft of this page put Export in a third group of its own, between the lens buttons and Search: rejected, Export stays first in the capsule as it is today. A lens-aware subtitle was floated as an idea and turned out to be already shipped (the SPA sends each lens's subtitle over the bridge), so it isn't a decision here.
The field's look. Today's hand-drawn capsule has a .quaternary fill, and macOS 26 wraps it in the shared glass, giving a grey pill inside a glass pill (frames marked “today”). The aim is the clean, light glass NetNewsWire and Photos get; with the fill removed and the control in its own item, the system glass is the only chrome.
When space runs out, the whole actions capsule folds into », Export included, since it's part of the capsule, and the open search field stays (its toolbar item carries the highest visibility priority, set at runtime). The one difference from these frames as built: the chevron is drawn at the trailing edge, with search to its left — AppKit gives the after-chevron slot only to NSSearchToolbarItem. Accepted 3 Oct 2026 as the least-worst without moving to NSToolbar. The back/forward group is untouched.
Bettina, a Windows user, didn't find New. She wouldn't drag, she expected to make a project before giving it any interviews, and she didn't explore the menu bar.
| Option | Precedent | For | Against |
|---|---|---|---|
| A · replaced | — | Removed 3 Oct 2026 (ce9b68dc) | Grey reads as disabled; scrolls away with the list; Bettina missed it. The AppKit sidebar has no equivalent row. |
| B · labelled footer | Notes, Reminders, Mail's + − | Bottom-left is where Mac lists have always put Add; the label is what a Windows user scans for; keeps the toolbar for the report | The HIG's warning about controls slipping off the bottom of the screen. It's answered by ⌘N and the Welcome screen still being there. |
| C · explaining menu | Things | Explains what a project is at the moment you make one | Rejected: too verbose. Also reads as apologetic, and Bettina's problem was finding New, not telling a project from a folder. |
| D · footer + gear | Things (sliders), Mail (?) | Gives Settings, and the AI key, a visible home | Rejected: the labelled “New Project” repeats the call to action the main content area already shows when no project is selected. And ⌘, is where Settings lives on a Mac. If a gear ever ships, use the gear, not sliders: sliders mean “adjust this view”. |
E · toolbar +⌄ | NetNewsWire | The purist option; disappears with the sidebar | Unlabelled, and another glass bubble in the toolbar. |
How the decision was reached (3 Oct 2026). In order: B (a labelled footer, from Notes/Reminders/Mail's + −) → C (B plus Things' explaining menu) → D (B plus a Settings gear, from Things' sliders and Mail's ?) → the owner called the stack “too apologetic” and “non-standard” → back to B stripped bare → E, the purist NetNewsWire default, chosen; C rejected as too verbose, D rejected because its label repeats the main area's New Project prompt and ⌘, is where Settings lives. Click behaviour: a plain menu, so New Folder is discovered (decided later the same day). Spec: §3.3 rev 3.
Decided: E. The sidebar's own toolbar holds, in order:
+⌄ · toggle — accepted 3 Oct 2026 rather than drawing our own toggle.+⌄ trailing, right-aligned to the sidebar's width, opening New Project / New Folder… (both shipped menu.file.* strings). It disappears with the sidebar, as NetNewsWire's does (built: only while the sidebar is visible, c2630892); at a narrow sidebar it does whatever the system does, observed not engineered.The in-list grey row (A) goes. B, C and D stay on the page as the alternatives we considered.
Implementation (plan reviewed 3 Oct 2026, five agents + parsimony pass): the smallest change. The plan was for the +⌄ to take the slot of today's New Folder button (folder.badge.plus, frame A). As built: that slot — a .toolbar on the SwiftUI project list — is not rendered on the AppKit sidebar path in use, so the New Folder button had not been showing there; the +⌄ is attached to the sidebar column instead and shows as traffic lights · +⌄ · toggle (the system puts its own toggle last). The sidebar toggle is not touched: it is the system's, already beside the traffic lights, and the fit-to-width logic and its tests drive it through AppKit. The flag-off AppKit sidebar has no toolbar item today and gets none in rev 3. Removing the grey row is its own commit, proven against the macOS 26 empty-list trap — done 3 Oct 2026 (ce9b68dc).
Build checks: (1) hiding when narrow is whatever the system does with the slot — observed, not engineered. (2) Bettina's discoverability gap is covered by the visible +, ⌘N, and the empty project's own button (section 3). Correction: the main window with nothing selected now shows a drop-only card (399d5da1, 3 Oct 2026), so “the main area already shows New Project” — the reason given against D — no longer holds; D stays rejected on the ⌘, grounds.
Click behaviour, decided: a plain menu, as in NetNewsWire. A click opens New Project / New Folder…, so New Folder gets discovered. Build check, resolved: on the sidebar column it shows in the AppKit sidebar too.
Not drawn: no − beside the +. Deleting a project stays in the right-click menu and the menu bar, with its confirmation.
After New Project, the detail pane asks for interviews. Today it only accepts a drop.
Bettina's “make it first” model already works up to the second step: New Project creates the project and puts its name into rename mode. Then the pane says “Drag Interviews Here” with no button, which is a dead end for anyone who doesn't drag (dragInterviewsPane, ContentView.swift).
Decided (3 Oct 2026): 2b. The pane keeps its shipped title and description and gains a primary Choose Interviews… button, whose picker accepts files and folders. That's one new key. Option 2a, rejected, reused the shipped menu.file.addFiles (“Add Files…”). No new string, but today's picker (addFilesToSelectedProject) takes files only, not folders. 2b needs a picker that also accepts folders, since researchers often keep one folder per study. It reuses the Add Files panel rather than adding a second one; the two names for one act (“Choose Interviews…” on the pane, “Add Files…” in the menu) are accepted for now. Dropping still works.
Related, not in this work: with no project selected the main window now shows a drop-only “Drop a folder” card (399d5da1, 3 Oct 2026) — the same dead end for a user who doesn't drag. That card belongs to the Welcome work; noted here so the next pass sees it.