[UX] Campaign-wide search in the app bar

claude-bot commented

2026-09-16 02:03:10 +00:00

Collaborator

Decided by the owner on 2026-09-15, while scoping lane 1 of the surface mockups (#659).

What

A search box in the app bar that searches one campaign — its sessions, its people and characters, its wiki articles, and the rules packs it has enabled. It appears only while you are inside a campaign. On Home, where no campaign is in scope, there is no search box.

There is deliberately no cross-campaign search. Two campaigns you are in are two separate worlds, and a result list that mixed them would leak one table's names into another's view for no benefit anyone asked for.

Why this is being filed now

The surface catalogue (#657) has no global search surface. The only search anywhere is WIKI-1, the wiki front page, which #593 already specifies: "One search box, with rules results tagged."

So this is new scope, caught by the standing rule that every planned feature must have a place in the redesign. It was found by going through lane 1's surfaces before drawing them — exactly what that rule is for.

Relationship to the wiki's search (#593)

This is not a second search box. #593's rule stands: one box, with results tagged by kind. This issue widens what that one box reaches, from "the wiki and the rules" to "the campaign", and gives it a home in the app bar so it is reachable from any page in the campaign rather than only from the wiki's front page.

The wiki front page keeps its own prominent search box — that page's whole job is finding things, and burying its search in the chrome would be a regression. The two use the same index and the same result list.

Where it lives in the redesign

Surface: SH-1 (the app bar) holds the input. Results need a surface of their own — proposed SH-9 · Search results, to be added to the catalogue.
Role: every campaign member. A GM sees GM-only material in results; a player does not. Results are filtered on the server by the same audience model as #593, not hidden in the client.
Phone: the phone app bar has no room for a permanent input alongside the brand, title and Contents button. Proposal to settle when drawn: a search icon that opens a full-screen search sheet.

Open questions for the mockup

Does the result list group by kind (Sessions / People / Wiki / Rules) or interleave by relevance?
Does it search as you type, or on Enter?
Do GM-only results carry a visible mark, so a GM can tell at a glance what a player would not see?

Not in scope here

The backend index. This issue is about the surface and its behaviour; what actually backs the query is the wiki search work in #593 plus whatever it needs to also reach sessions and people.

Related: #593 (wiki redesign, the one-box rule), #656 (shell decisions), #657 (the surface catalogue), #659 (mock up every surface), #661 (the look).

Decided by the owner on 2026-09-15, while scoping lane 1 of the surface mockups (#659). ## What A search box in the app bar that searches **one campaign** — its sessions, its people and characters, its wiki articles, and the rules packs it has enabled. It appears only while you are inside a campaign. On Home, where no campaign is in scope, there is no search box. There is deliberately **no cross-campaign search**. Two campaigns you are in are two separate worlds, and a result list that mixed them would leak one table's names into another's view for no benefit anyone asked for. ## Why this is being filed now The surface catalogue (#657) has no global search surface. The only search anywhere is `WIKI-1`, the wiki front page, which #593 already specifies: "One search box, with rules results tagged." So this is new scope, caught by the standing rule that every planned feature must have a place in the redesign. It was found by going through lane 1's surfaces before drawing them — exactly what that rule is for. ## Relationship to the wiki's search (#593) This is **not a second search box**. #593's rule stands: one box, with results tagged by kind. This issue widens what that one box reaches, from "the wiki and the rules" to "the campaign", and gives it a home in the app bar so it is reachable from any page in the campaign rather than only from the wiki's front page. The wiki front page keeps its own prominent search box — that page's whole job is finding things, and burying its search in the chrome would be a regression. The two use the same index and the same result list. ## Where it lives in the redesign - **Surface:** `SH-1` (the app bar) holds the input. Results need a surface of their own — proposed `SH-9 · Search results`, to be added to the catalogue. - **Role:** every campaign member. A GM sees GM-only material in results; a player does not. Results are filtered on the server by the same audience model as #593, not hidden in the client. - **Phone:** the phone app bar has no room for a permanent input alongside the brand, title and Contents button. Proposal to settle when drawn: a search icon that opens a full-screen search sheet. ## Open questions for the mockup 1. Does the result list group by kind (Sessions / People / Wiki / Rules) or interleave by relevance? 2. Does it search as you type, or on Enter? 3. Do GM-only results carry a visible mark, so a GM can tell at a glance what a player would not see? ## Not in scope here The backend index. This issue is about the surface and its behaviour; what actually backs the query is the wiki search work in #593 plus whatever it needs to also reach sessions and people. Related: #593 (wiki redesign, the one-box rule), #656 (shell decisions), #657 (the surface catalogue), #659 (mock up every surface), #661 (the look).

claude-bot added this to the v4.5.0 - UX Overhaul: Design Exploration & Rebuild milestone

2026-09-16 02:03:19 +00:00

claude-bot added the

enhancement

frontend

labels

2026-09-16 02:03:32 +00:00

rbrooks referenced this issue from a commit

2026-09-16 02:05:25 +00:00

feat(design): campaign-wide search gets a surface (#667)

claude-bot referenced this issue

2026-09-16 02:05:32 +00:00

feat(design): campaign-wide search gets a surface (#667) #668

claude-bot referenced this issue

2026-09-16 02:05:54 +00:00

[UX] Mock up every catalogued surface, for players and GMs, before building #659

claude-bot referenced this issue from a commit

2026-09-16 02:29:14 +00:00

Merge PR #668: campaign-wide search gets a surface (#667)

rbrooks referenced this issue from a commit

2026-09-16 02:32:37 +00:00

feat(feedback-site): lane 1 of the surface mockups — the shell (#659)

claude-bot referenced this issue

2026-09-16 02:32:52 +00:00

feat(feedback-site): lane 1 of the surface mockups — the shell (#659) #669

claude-bot referenced this issue

2026-09-16 02:49:13 +00:00

[UX] Mock up every catalogued surface, for players and GMs, before building #659

rbrooks referenced this issue from a commit

2026-09-16 16:04:17 +00:00

feat(feedback-site): lane 2 of the surface mockups — the campaign core (#659)

claude-bot referenced this issue

2026-10-02 04:27:22 +00:00

Campaign search has no results page: a kind stops at ten with no way to the rest, and a rules hit opens nothing #1033

claude-bot commented

2026-10-02 04:27:30 +00:00

Author

Collaborator

Checked against main (2b077778), 2 October: built (lanes 1 and 3, ranking in #1026).

One campaign only, and only inside a campaign: shell/AppFrame.jsx mounts <Search> when there is a campaignId; AppFrame.test.jsx "is not on Home: it searches one campaign and never crosses between them".
Sources: sessions, people and characters, wiki, and the rules packs the campaign has loaded (app/routers/search.py, GET /api/campaigns/{id}/search-all, KIND_ORDER). test_campaign_search.py covers a loaded pack and a campaign with no game system.
What a reader may see is decided on the server: the wiki goes through lore_service.list_lore_entries(viewer=…); tests "a gm-only sidebar field is found only by the gm" and "…is not in a players search". GM-only hits carry a chip.
Grouped by kind, searched as you type from two letters, with a name match first (app/services/search_rank.py).
Transcripts are opt-in and GM-only; a player asking gets 403; transcripts in the bin are left out.
The wiki front page searches the same index.
Phone: a real search box in the bar rather than an icon that opens a sheet (the 15 September decision).

Two pieces are not built and are now #1033: the results page behind "See all" (a kind stops at ten), and somewhere for a rules hit to go. Closing this one.

Checked against main (2b077778), 2 October: **built** (lanes 1 and 3, ranking in #1026). - One campaign only, and only inside a campaign: `shell/AppFrame.jsx` mounts `<Search>` when there is a `campaignId`; `AppFrame.test.jsx` "is not on Home: it searches one campaign and never crosses between them". - Sources: sessions, people and characters, wiki, and the rules packs the campaign has loaded (`app/routers/search.py`, `GET /api/campaigns/{id}/search-all`, `KIND_ORDER`). `test_campaign_search.py` covers a loaded pack and a campaign with no game system. - What a reader may see is decided on the server: the wiki goes through `lore_service.list_lore_entries(viewer=…)`; tests "a gm-only sidebar field is found only by the gm" and "…is not in a players search". GM-only hits carry a chip. - Grouped by kind, searched as you type from two letters, with a name match first (`app/services/search_rank.py`). - Transcripts are opt-in and GM-only; a player asking gets 403; transcripts in the bin are left out. - The wiki front page searches the same index. - Phone: a real search box in the bar rather than an icon that opens a sheet (the 15 September decision). Two pieces are not built and are now #1033: the results page behind "See all" (a kind stops at ten), and somewhere for a rules hit to go. Closing this one.

claude-bot closed this issue

2026-10-02 04:27:41 +00:00

Rows
Columns

[UX] Campaign-wide search in the app bar #667

What

Why this is being filed now

Relationship to the wiki's search (#593)

Where it lives in the redesign

Open questions for the mockup

Not in scope here