Welcome in its own window (Model 2)

Bristlenose for Mac. The Welcome spiral, as shipped, moves out of the main window into one app-wide window of its own. The window opens at the spiral's natural size and can be resized like any other window. The drop card stays behind: the main window's empty states become the drop card alone, centred. Six panels plus the Appearance row (3c). The model is chosen; the decisions taken so far are recorded in the commentary. At its natural size the spiral is unchanged, apart from losing the drop card. Panel 4 proposes how it reflows when the window is made narrow. The Model 1 alternative, where Welcome stays in the main window and was not chosen, is in welcome-dismiss-options.html.

Artefact: pixels that would ship. No labels inside the frame. Commentary: tradeoffs and reasoning. Not the product. frame bar: state · NEW COPY = owner-written, not a shipped key

1First open: Welcome centred over the main window, key

1 · very first launch, no projectsNEW COPY: footer checkbox (see 3)

Decided. On the very first open, Welcome is centred over the main window and is key. It is naturally smaller than the main window, so the main window's title bar and sidebar show around it, and the researcher can see there is a window underneath. From there it is normal window mechanics. On a small screen they will close it, minimise it, or slide it mostly off screen. On a big screen they have more room to arrange the two, and some will drag it to another Space. A click on the main window brings that window forward and Welcome falls behind it. That is fine: the researcher wanted to try the app more than read Welcome, and they now know Welcome exists.

Every later open restores the frame the researcher left it in, including size and position. It is a normal macOS window and the screen is theirs. The natural size and the centred position apply only the first time.

The AI-consent sheet is modal and attached to the main window. It is the first thing the researcher meets once Welcome is closed or moved aside, and the app cannot be used until it is dismissed. Welcome does not wait for it, and it does not compete for anything: it is a separate window, while the sheet belongs to the main window.

The Welcome window is no longer tied to the main window's 700 pt minimum, which exists so a report can be shown. It handles narrow widths on its own terms, by reflowing (panel 4) rather than scaling content down.

2After a click on the main window: Welcome behind it, or moved beside it

2 · main window key, Welcome dragged beside it (a large screen)normal window mechanics, nothing designed

No placement code is needed for this state. It is drawn to show what happens on a wide display when the researcher arranges the two windows: the drop card is live and the Welcome window, no longer key, sits to one side and can be ignored. On a laptop the same click leaves Welcome behind the main window, out of sight. The frame they leave it in is the frame it opens in next time.

3The Welcome window, close up

3a · key, box ticked (default)NEW COPY: "Show Welcome when Bristlenose opens"
3b · not key, box untickedclick either box: it is live

The checkbox sits at bottom-leading, where Xcode and Pixelmator Pro put theirs. Wording decided: "Show Welcome when Bristlenose opens", the §0 spec wording. Here it is also accurate, because deselecting a project no longer summons Welcome. It closes like any other window: the red traffic light or ⌘W. There is no X inside the content and no Close button. It is an ordinary titled window. It can be resized, minimised and zoomed, because no part of it needs a fixed frame. Xcode's welcome window is fixed-size and has no title bar. That works because Xcode's window is a launcher, and this one is not.

Without the drop card, Study tools gains about 90 pt of height, which goes to the illustration. That is the only change to the spiral. Title is the shipped desktop.chrome.welcomeTitle ("Welcome to Bristlenose"), the same string as the Help menu item, so the menu item and the window it opens have the same name.

Opening size, derived rather than measured: 800 pt content width gives a 760 × 470 pt spiral. The Scientific background cell is then about 284 × 285 pt, enough for the 208 × 152 pt cover fan to draw at scale 1 with its caption and link. That is the reasoning from BookShelfView.coverFan's comments. Nobody has measured it yet. The Degradation Lab would confirm or move the number, and the spiral's φ geometry fixes everything else from that one width. Watch: the spiral's φ geometry means a wider window makes it taller as well. Above the natural size it needs a cap or it outgrows the screen, so the natural size works as a maximum as well as the opening size.

Rotators. The visit count is invisible to the researcher in v1. It is an implementation detail, not a design question, and nothing in the window shows it.

Checkbox behaviour, decided. Ticking or unticking never closes the window. The researcher keeps it open or closes it, with the box set either way, and the box governs only whether it opens at the next launch.

3c · Settings ▸ Appearance, the same setting mirrored (existing sections abridged)NEW COPY: legend + help (dashed row) · help line approved
Appearance
General
Appearance
LLM Provider
Transcription
MCP Agents
Accounts
Application appearanceUse system appearance
Colour paletteRecolours the whole app. Edo uses warm washi paper and Prussian-blue ink.Default
Show Welcome when Bristlenose opensOpens a window of study tools, scientific background and a tip.
Show animation while analysingPlay a flocking-words animation in the main window while a project is analysing. Turn this off to see the plain progress instead.

Decided: the row exists. It is the same setting as the footer checkbox, drawn in the pane's own idiom as a grouped-form Toggle, which renders as a switch, next to its nearest sibling "Show animation while analysing". Help line, decided: "Opens a window of study tools, scientific background and a tip." It replaces the Model 1 line, which described Welcome as appearing in the main window.

4Resized to its minimum width: Study tools moves on top

4a · natural size (opening frame)as 3a
4b · minimum width (≈327 pt)top
4c · same, scrolled to the endrest of spiral unchanged

Decided: one reflow step, no more. The window's minimum width is the Scientific background cell's natural width plus the 20 pt margins, about 327 pt (derived, not measured). Below the natural size only the outermost golden split turns from side by side to stacked: Study tools moves on top at the same width, and the rest of the spiral sits underneath at its natural geometry. The window cannot get narrow enough for anything inside that block to move, so AI never wraps under Tip. The column scrolls and the footer checkbox stays pinned. Fonts stay at their semantic sizes and nothing scales down, which is the spec's "never squish the architecture" rule, kept by moving one cell rather than shrinking any.

Baton order, decided: comic-strip reading order, left to right and then top to bottom. Stacked, that is Study tools first and then the rest of the spiral in its usual order. At the natural size it is unchanged.

For: a normal resizable Mac window with a real minimum, one extra layout state rather than a family of them, and a narrow strip that a laptop user can keep beside the main window. Cost: this changes spec §2's "does not reflow" rule, but only below the natural size, and only by flipping one split.

5Main window empty states, Welcome window closed

5a · no projects yetshipped keys only
5b · projects exist, none selectedshipped keys only

Decided: both states show the existing drop card, unchanged and centred, with no buttons added. The lens group stays dimmed because there is no project to apply it to. This is the one point where Model 2 and Model 1's "Welcome off" state (panel 3 of the sibling mockup) produce identical pixels. Model 2 makes this the only no-selection state, so the main window never shows teaching. ⌥⌘N windows open into this state as well, and none of them brings its own copy of Welcome.

For: every no-selection moment, whether it comes from deselecting, deleting the selected project or opening a new window, is now calm and shows one action. The main window's empty state no longer depends on window width.

Against: in 5a the main window alone is very bare: an empty sidebar and one card. If the researcher closed Welcome a moment ago, it is no longer there to say what the app is for. Title, decided: with no project selected the window is titled "Bristlenose". It used to be "Welcome" (desktop.welcome.windowTitle, ContentView.swift:427), which no longer fits once the Welcome content has left this window. See panel 6b.

6Reopening it: Help ▸ Welcome to Bristlenose

6a · Help menu, as shippedshipped keys only · behaviour changes
6b · Window menu, AppKit standard (no new item)window list only

Decided: Help is the only way back. Welcome is help more than anything else, so it lives in the Help menu. There is no extra Window-menu item. 6a is the item as it ships, with no shortcut. What changes is what it does. Today it clears the selection to show the Welcome pane. In Model 2 it opens or focuses the Welcome window and leaves the main window's selection alone, so it no longer moves the researcher away from what they were looking at.

6b is drawn only for its window list, which AppKit fills in by itself. Once open, Welcome appears there like any other window. Decided: with no project selected, the main window is titled "Bristlenose". That is the simplest fix, and the convention library apps already follow (Music, Notes, Photos). It ends the collision the shipped title "Welcome" caused, where two near-identical rows were listed and the one called "Welcome" was the window without Welcome in it. Empty main windows are not numbered (ContentView.windowGroup is nil without a project), so two of them both read "Bristlenose", as two "Welcome" rows did before. The app name is not translated.

Full screen: decided, not drawn. No special treatment. Welcome is an ordinary Mac window: if it ends up behind the main window, it stays behind. If the researcher takes the main window full screen, they get the normal behaviour, and they can make Welcome a full-screen tile beside it because macOS already offers that (Window ▸ Full Screen Tile). No collection behaviour is set and no placement code is written for this case.

—String plan

StringStatusWhere
Welcome to Bristlenoseshippeddesktop.chrome.welcomeTitle: Help item, now also the window title
Drop a folder · Drag a folder of recordings or transcripts here to add it as a project.shippeddesktop.welcome.dropFolderTitle / …Hint
Bristlenose (main window title, no selection)app name, not a keyreplaces desktop.welcome.windowTitle at ContentView.swift:427, which then has no caller and can be removed from all locales
Projectsshippeddesktop.chrome.projects
Show Welcome when Bristlenose opensnewWelcome window footer + Appearance legend
Opens a window of study tools, scientific background and a tip.new, approvedAppearance help line
Minimize · Zoom · Fill · Center · Bring All to Front …AppKit'sstandard Window menu, system-localised

Two new keys, which go into all 21 full locales. zh-Hant-HK inherits from zh-Hant. Spiral copy is unchanged.

GMac-native review (Gruber and friends): recommendations, not decisions

A read-only what-would-gruber-say pass over 5b0d53f4. Where you have since ruled, your ruling stands, and it is marked below. Items settled before the review are left out.

Window type. A regular titled window: resizable, minimisable, closed with ⌘W, not an NSPanel. Title "Welcome to Bristlenose". Implementation trap: SwiftUI's Window("…", id:) adds its own "open" item to the Window menu, which breaks the help-only route back. Fix with .commandsRemoved(). Keep the window-list entry, Mission Control and ⌘` membership, because it is a real window.

Main window title. Retire "Welcome" for the main window's no-selection title (ContentView.swift:427) and use "Bristlenose" or the shipped "No Project Selected", so the collision in panel 6b goes away. Ruled: "Bristlenose".

Launch and restoration. "Opens" means a cold launch only. A Dock reopen with no windows makes a main window, not Welcome. State restoration must not override the checkbox: .restorationBehavior(.disabled) plus .defaultLaunchBehavior(.presented), gated on the setting (both on macOS 15). Matches the ruling: launch only.

Placement and key. Make Welcome key: VoiceOver announces it, and one ⌘W gets the researcher back to the task. Drag and drop works on a window that isn't key, so there is no reason to open it without focus. Place it beside the main window when there is room, otherwise offset to the trailing side so the centred drop card stays visible. Never centre it over the main window. Autosave the frame, so the natural size applies only on first open. Defer it until any first-run sheet has been dismissed. Overruled: the first open is centred over the main window (panel 1), and the consent sheet does not hold Welcome back. Agreed: key, and the frame is remembered after the first open.

Checkbox semantics. Help ▸ Welcome while the box is unticked shows the window once and leaves the setting off. Unticking takes effect at the next launch and never closes the window. ⌘W closes the window and never changes the setting. This follows Xcode and Pixelmator Pro. The ruling matches on unticking and ⌘W. Ruled: Help opens it without touching the setting, which matches Gruber's "once".

Rotators. One advance per window open, no timer. Ruling: it is an invisible implementation detail in v1.

Dropping a folder on Welcome. Make the whole Welcome window a drop target. A drop creates the project in the frontmost main window, or a new one, selects it and brings that window forward. Welcome stays open. Gruber also says a second drop card inside Welcome would be acceptable (Photos Import precedent), which runs against your decision to remove the card from Welcome. The whole-window drop is the half that does not reopen that decision. Overruled: Welcome has no drop target of any kind. Dropping belongs to the main window's empty state only, so there is no confusion about where a folder goes.

Accessibility, a finding in shipped code rather than in this mockup. SlotRotator is .focusable() with .focusEffectDisabled() (WelcomeHomeView.swift:603–604): a focusable control with no focus ring, which fails Full Keyboard Access in either model. Also give the cells an .accessibilitySortPriority so VoiceOver reads them in curriculum order, with the checkbox last.

Main window with only the drop card is enough. File ▸ New Project is the labelled alternative (Photos and Music precedent). This agrees with the decision in panel 5. Stage Manager groups both windows. In full screen, AppKit leaves Welcome on the desktop Space, which matches the full-screen decision.

✓Decided

Model 2: Welcome is its own window, the spiral as shipped minus the drop card. Checkbox: "Show Welcome when Bristlenose opens". Opens only at launch, never on deselect. First open: centred over the main window, key (panel 1). Later opens: the frame the researcher left it in. Resizable down to a minimum width equal to the Scientific background cell plus margins. Below the natural size only the outermost split flips, so Study tools moves on top and the rest of the spiral is unchanged (panels 4b and 4c). The baton follows comic-strip reading order. Ticking or unticking never closes the window and governs the next launch only. The AI-consent sheet stays modal on the main window and is met once Welcome is moved aside. Rotator visits are invisible in v1. No drop target in Welcome: dropping lives in the main window's empty states, which show the existing drop card, unchanged and centred, with nothing added. Main window title with no project selected: "Bristlenose". One setting, two views: the footer checkbox and the Settings ▸ Appearance switch (panel 3c) are the same setting. Help ▸ Welcome opens the window without changing the setting, and the box shows its current state. Ticking it in either place turns it back on. Reopen via Help ▸ Welcome to Bristlenose only. Full screen gets no special treatment.

?Still open

Nothing. Every question this mockup raised has been ruled on.