Bristlenose for Mac, no project selected. Seven panels comparing how a researcher turns off WelcomeHomeView. These are whole-pane options only: per-card dismissal, a sidebar Home row, a separate Welcome window and the sample project are out of scope. Panel 1 is the preferred option. Its checkboxes are live. Tick and untick them to compare the two meanings of "off".
The checkbox sits in the empty space under the spiral, at bottom-leading. Pixelmator Pro and Xcode put theirs in the same place.
For: the control sits on the surface it governs, and it is the idiom Mac users already know from Xcode and Pixelmator Pro. It is one stock Toggle with .toggleStyle(.checkbox), adds nothing to the spiral, and the spiral's fixed geometry already leaves the space below it empty. The setting persists, which answers the Photoshop complaint that "off" did not stick.
Against: a checkbox is easy to miss at the bottom of a wide window. At narrow widths the spiral is short and the box sits a long way below the drop card.
1a vs 1b. 1a (applies next time) is how Xcode behaved: the box records a preference, and nothing moves under the pointer. Re-ticking works because the box is still on screen. The cost is that unticking appears to do nothing until the next launch or deselect. 1b (applies now) gives instant feedback, but the checkbox fades out with the pane. Turning Welcome back on then needs panel 4 (Settings), panel 5 (View menu) or Help ▸ Welcome to Bristlenose. If 1b, which of those is the route back?
Two crops of the same footer, showing the same control with different labels.
2a uses the wording already in the spec (§0) and matches Xcode's "Show this window when Xcode launches". It is inaccurate, though: Welcome also appears when the selection is cleared (Help ▸ Welcome, a click on empty sidebar space, deleting the selected project) and when a new window opens with ⌥⌘N. A researcher who unticks it and then deselects a project would reasonably expect it to stay away.
2b describes every entry point. "Open" is slightly off, because a project is selected in the sidebar rather than opened. "Selected" is accurate but reads like engineering. Both wordings run about 20 % longer in German and Finnish. The footer has room for that, but the Appearance row in panel 4 does not have much.
The existing drop card, unchanged, centred in the detail area. Nothing new is added.
The drop card is already the only real action on the Welcome pane, so it stays and the teaching goes. It keeps its 14pt padding, dotted border and tray.and.arrow.down glyph. "Drop a folder" and "Drag a folder of recordings or transcripts here…" are shipped keys (desktop.welcome.dropFolderTitle/Hint).
Watch: in 3a someone who turned Welcome off on a previous install, or after removing every project, gets an empty sidebar and a single card. That is probably fine for someone who chose it. Should a first run on a clean defaults domain always show Welcome, whatever the setting? A fresh install has no setting stored, so it would show Welcome anyway unless the defaults domain survived an uninstall. Also: centring the card is new. Today it sits inside the Study tools cell. Pinning it to the top, where the spiral used to start, would be the other choice.
The row is drawn in the pane's own idiom: a Toggle with a legend and a help line, matching "Show animation while analysing", which is the nearest sibling in both meaning and phrasing. In a grouped form, macOS renders it as a switch, not a checkbox. The footer control in panel 1 and this one are two views of one @AppStorage key.
For: the HIG's "easy to find later in a settings area", and this row is the route back if panel 1b is chosen. Against: it cannot be the only control, because nobody looks for Welcome in Appearance. On its own it would recreate Photoshop's buried preference. Placement: Appearance (as spec'd in §0) or General? It changes what the window shows, so Appearance is defensible.
The item follows the dynamic Hide/Show Projects pattern (a label that names the action, not a checkmark Toggle). No shortcut, for the same reason Help ▸ Welcome has none: the action is rare and a shortcut would not be remembered.
For: it can be found by menu search, the label always says what will happen, and in panel 1b it is a route back that does not involve Settings. Against: it overlaps with Help ▸ Welcome to Bristlenose. "Show Welcome" in View and "Welcome to Bristlenose" in Help would do almost the same thing, one persistently and one once, and the difference between them cannot be read from the labels. Is View ▸ Hide/Show Welcome the persistent setting? If so, Help stays a one-off visit and the two menus divide the work cleanly. If it is only a one-off, it duplicates Help.
The X sits top-leading, where macOS puts close. That position is exactly the problem. In 6b, with the sidebar hidden, the traffic lights move into the detail area's title bar, and the pane's X ends up next to the window's red close button. Two circles a few points apart, one closing the window and one closing the pane. Moving the X to top-trailing avoids the collision, but that is the Windows and web position, not the Mac one.
Also: an X implies "this card, now", which brings back the per-card reading that has already been rejected. It does not say whether the close persists. If it does, the way back is hidden (the Photoshop problem in reverse). If it does not, the pane comes back on every deselect, which is nagging. A labelled checkbox states its rule. An X does not.
The model is Safari's "New windows open with". The on/off checkbox becomes a choice of what fills the empty state, and two of the choices (one tip; activity) are new surfaces that need designing first. Why park it rather than drop it: it is where panel 1 leads if researchers ask for something between "everything" and "nothing". Panel 1's boolean would migrate cleanly, with on = Welcome and off = Drop target. Why not this month: two of the four options do not exist, and the activity grid needs a definition of "activity" (sessions? quotes? analysis runs?) that nobody has settled.
| String | Status | Where |
|---|---|---|
| Drop a folder · Drag a folder of recordings or transcripts here to add it as a project. | shipped | desktop.welcome.dropFolderTitle / …Hint |
| Welcome to Bristlenose | shipped | desktop.chrome.welcomeTitle (Help menu) |
| Hide Projects · Show Contents · Hide All Sidebars · All Quotes · … | shipped | desktop.menu.view.* |
| Show Welcome when Bristlenose opens / …when no project is open | new (one of the two) | footer checkbox + Appearance legend |
| Appearance help line ("Study tools, scientific background and a tip…") | new, placeholder | Appearance row |
| Hide Welcome · Show Welcome | new (if panel 5) | desktop.menu.view.* |
| Picker question + four options | new, parked | panel 7 only |
Any new key goes into all 21 full locales. zh-Hant-HK is the exception and inherits from zh-Hant.
1. Checkbox wording. "…when Bristlenose opens" (spec, Xcode precedent, but inaccurate) or "…when no project is open" (accurate, but uses "open" where the app says "select")?
2. Help ▸ Welcome to Bristlenose while the setting is off. Does it show Welcome once and leave the setting off, so the next deselect shows the drop target again? Or does it turn the setting back on? Showing it once matches the HIG's "find it later" without overruling the user. Turning it on is simpler to explain, but a visit to Help then has a persistent side effect. If once: in panel 1a the footer box shows unticked while Welcome is on screen, which is honest and also makes re-ticking easy.
3. 1a or 1b: does unticking apply next time or now? This decides whether panel 4 or 5 has to exist as a route back.