Skip to content

Queue navigation UX: what should clicking a future card do — and is a play-from-here control needed? #6

Description

@noisy

Context

The prefetch pipeline made the queue visible: while clip 5 plays, clips 6–8 already sit READY with rendered audio. That surfaces a design question we have not answered yet: what does clicking a not-yet-played card mean? Today it means nothing — the replay affordance only exists on settled cards (played/unheard).

Krzysztof's raw thoughts (2026-07-15, spoken)

  • The queue can be managed several ways; unclear what play should fundamentally do — only the current message, or more.
  • Scenario: all messages already played, and I want to re-listen to the last five. Clicking replay five times is tiresome — so maybe a second icon meaning "play this one and everything after it".
  • That could be consistent… but I'm not sure. Don't want to change behaviour without knowing what the right model is.

Claude's recommendation so far (skip-to model, podcast/DVR)

Clicking a future (queued/ready) card = skip forward to it:

  1. The playing clip is cut (stays played — existing stop semantics).
  2. Skipped-over cards park as UNHEARD — honest (never heard), still visible, and free to catch up on later (their audio is already cached).
  3. The clicked card plays immediately; the queue continues normally after it.

Consistent with the existing rule "the user's click owns the speaker now" (backward click = replay with barge-in, forward click = skip). Also neatly covers the stuck-card edge case: clicking past a wedged clip skips it.

Distinct affordance suggested: / (play now) on future cards vs (replay) on settled ones.

Open questions

  • Is single-message play (current behaviour of ) the right default, with "play this and the rest" as a second control? Two icons per card may be clutter — maybe a modifier (long-press / shift-click) or a card-menu instead.
  • What does "play this and following" do to cards between now-playing and the clicked one when clicking backward? (Probably nothing — they were already played.)
  • Does play-from-here re-queue only played cards, or also unheard ones in range?

No decision yet — do not implement until the model feels right.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions