In the My Words voice tab the mic is open for the whole session. There is no
mute, and no way for the writer to think out loud without the partner treating
what they said as material to act on. This is the content-vs-command problem in
its cheapest form, and it's probably the largest single lever on whether the
writer feels like the conductor rather than the subject of the conversation.
Note the interaction with turn-taking: the partner's one-edit-per-turn budget
resets when the writer starts speaking, so any speech currently grants the
partner another move. A "just listening" mode has to decide whether it also
withholds that grant.
Candidates, in rising cost
- Dictate / converse switch — a two-state toggle. In dictate, speech feeds
the transcript and the word bank but the partner stays silent and makes no
moves; in converse, current behavior. Cheapest, and the state is visible,
which matters for trust.
- Push-to-talk for commands — open mic for content, a held key or button to
address the partner. Precise, but a held key is awkward while typing and the
Word taskpane complicates key capture.
- Spoken address marker — "computer, …" / a wake phrase. No hands, but
detection errors land in the worst place, and it needs the partner to not
act on everything else, which is the same problem again.
My leaning is (1): the state is explicit and visible, it needs no new detection,
and it's reversible if testing says writers want something lighter.
Why it's unbuilt
Deliberately. This wants a session with a real writer talking through a real
draft — the failure mode we'd be designing against (feeling interrupted mid-
thought) isn't something we can specify from the outside.
Background
Grep the docs for:
Deliberately deferred — the section listing this gap alongside three others.Content vs. command — the original open design axis, with the "content by
default, light marker for commands" hypothesis.Control invariants — the turn-taking rules already enforced in code,
including the edit budget that a listening mode interacts with.Privacy / always-listening — the open question about open mic vs
push-to-talk and its study-logging implications, which this decision settles.
In the My Words voice tab the mic is open for the whole session. There is no
mute, and no way for the writer to think out loud without the partner treating
what they said as material to act on. This is the content-vs-command problem in
its cheapest form, and it's probably the largest single lever on whether the
writer feels like the conductor rather than the subject of the conversation.
Note the interaction with turn-taking: the partner's one-edit-per-turn budget
resets when the writer starts speaking, so any speech currently grants the
partner another move. A "just listening" mode has to decide whether it also
withholds that grant.
Candidates, in rising cost
the transcript and the word bank but the partner stays silent and makes no
moves; in converse, current behavior. Cheapest, and the state is visible,
which matters for trust.
address the partner. Precise, but a held key is awkward while typing and the
Word taskpane complicates key capture.
detection errors land in the worst place, and it needs the partner to not
act on everything else, which is the same problem again.
My leaning is (1): the state is explicit and visible, it needs no new detection,
and it's reversible if testing says writers want something lighter.
Why it's unbuilt
Deliberately. This wants a session with a real writer talking through a real
draft — the failure mode we'd be designing against (feeling interrupted mid-
thought) isn't something we can specify from the outside.
Background
Grep the docs for:
Deliberately deferred— the section listing this gap alongside three others.Content vs. command— the original open design axis, with the "content bydefault, light marker for commands" hypothesis.
Control invariants— the turn-taking rules already enforced in code,including the edit budget that a listening mode interacts with.
Privacy / always-listening— the open question about open mic vspush-to-talk and its study-logging implications, which this decision settles.