[Design] In-person tables: the constraints the v4.4.0 redesign must satisfy now, and the features that come later #542

New issue

Open

opened 2026-09-06 22:08:19 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-09-06 22:08:19 +00:00

Contributor

Raised by the owner during checkpoint A of v4.4.0 (#535): the redesign must still work for a group that plays in one room, not only an online table on Discord voice. The in-person features are a later milestone; this issue records the constraints the redesign is checked against now, so that milestone is not blocked by a design that assumed the online case.

What changes when the table is in one room

Between sessions, nothing: scheduling, votes, RSVP, recap and the wiki are identical. During a session, three things:

Capture. No Discord voice channel. A room microphone (a phone or tablet in the middle of the table, a laptop, a recorder) makes one mixed track, so attribution has to be recovered afterwards: speaker separation on one track, then a GM assigns "Speaker A" to a person. That pipeline is later work. The design must leave room now for a recording source on the Recording panel (Discord voice · this device's microphone · an uploaded file) and for a transcript review that shows unnamed speakers with a GM control to name them (#422's per-session character pin is the seed).
The shared screen. The players' live view is one screen everybody looks at, a TV or a propped-up tablet, not each player's phone. Readable from two or three metres; no controls of its own, driven by the GM's device (Reveal pushes to it); paired simply (a short code on the screen, typed on the GM's device). Players with a phone keep the phone Table view.
Players without a device. Some players have nothing open. No step of play may require every player to hold a device: a reveal must also exist where they can find it afterwards, a vote or safety tool needs a spoken fallback, and the session page must make sense to someone who opens it the next morning.

The GM is at the table with a laptop or tablet, often standing, in dim light, one hand busy.

Constraint written into the v4.4.0 brief (#361)

The redesign must work when the table is in one room: the live surfaces must have a shared-screen face readable at distance and driven from the GM's device; the recording surface must not assume Discord voice as its only source; and no step of play may require every player to hold a device.

Every checkpoint A concept now states where its shared screen lives, and the players' review page draws that face for each concept.

Later-milestone features this must not preclude (not designed now)

Room-microphone recording from the GM's device or a phone on the table, with speaker separation and a GM naming step (backend pipeline work; #352's forced alignment and the diarisation question belong here).
Shared-screen pairing: a code on the TV, entered on the GM's device; the screen is display-only.
An initiative or turn tracker on the shared screen.
Printable handouts from a reveal.
The v4.5.0 table and safety tools with a shared-screen face and a spoken fallback.

Acceptance for v4.4.0 (the design side only)

The chosen direction's mockups (#363) include the shared-screen face of the live session and a Recording panel with a source selector, even if the selector offers only Discord voice at first.
The player journey at the table is walked through twice: with a phone, and without one.
The in-person features are filed against their own milestone once the direction is chosen.

Raised by the owner during checkpoint A of v4.4.0 (#535): the redesign must still work for a group that plays **in one room**, not only an online table on Discord voice. The in-person *features* are a later milestone; this issue records the constraints the redesign is checked against now, so that milestone is not blocked by a design that assumed the online case. ## What changes when the table is in one room Between sessions, nothing: scheduling, votes, RSVP, recap and the wiki are identical. During a session, three things: 1. **Capture.** No Discord voice channel. A room microphone (a phone or tablet in the middle of the table, a laptop, a recorder) makes one mixed track, so attribution has to be recovered afterwards: speaker separation on one track, then a GM assigns "Speaker A" to a person. That pipeline is later work. The design must leave room now for a **recording source** on the Recording panel (Discord voice · this device's microphone · an uploaded file) and for a transcript review that shows unnamed speakers with a GM control to name them (#422's per-session character pin is the seed). 2. **The shared screen.** The players' live view is one screen everybody looks at, a TV or a propped-up tablet, not each player's phone. Readable from two or three metres; **no controls of its own**, driven by the GM's device (Reveal pushes to it); paired simply (a short code on the screen, typed on the GM's device). Players with a phone keep the phone Table view. 3. **Players without a device.** Some players have nothing open. No step of play may require every player to hold a device: a reveal must also exist where they can find it afterwards, a vote or safety tool needs a spoken fallback, and the session page must make sense to someone who opens it the next morning. The GM is at the table with a laptop or tablet, often standing, in dim light, one hand busy. ## Constraint written into the v4.4.0 brief (#361) > The redesign must work when the table is in one room: the live surfaces must have a shared-screen face readable at distance and driven from the GM's device; the recording surface must not assume Discord voice as its only source; and no step of play may require every player to hold a device. Every checkpoint A concept now states where its shared screen lives, and the players' review page draws that face for each concept. ## Later-milestone features this must not preclude (not designed now) - [ ] Room-microphone recording from the GM's device or a phone on the table, with speaker separation and a GM naming step (backend pipeline work; #352's forced alignment and the diarisation question belong here). - [ ] Shared-screen pairing: a code on the TV, entered on the GM's device; the screen is display-only. - [ ] An initiative or turn tracker on the shared screen. - [ ] Printable handouts from a reveal. - [ ] The v4.5.0 table and safety tools with a shared-screen face and a spoken fallback. ## Acceptance for v4.4.0 (the design side only) - [ ] The chosen direction's mockups (#363) include the shared-screen face of the live session and a Recording panel with a source selector, even if the selector offers only Discord voice at first. - [ ] The player journey at the table is walked through twice: with a phone, and without one. - [ ] The in-person features are filed against their own milestone once the direction is chosen.

claude-bot referenced this issue

2026-09-06 22:22:40 +00:00

[UX] Wireframe exploration — 5-10 concepts across every surface #362

claude-bot referenced this issue

2026-09-06 22:22:42 +00:00

[UX] Inventory every surface and define the redesign brief #361

claude-bot referenced this issue

2026-09-06 22:22:48 +00:00

v4.4.0 build order: UX Overhaul in six phases, with two review checkpoints #535