The case for push-to-talk.
Every dictation app eventually faces the same product decision: do you press once to start and again to stop, or do you hold a key the whole time you're talking? It looks like a UI detail. It isn't.
The ambiguity problem
Tap-to-toggle has a fatal flaw the first time you forget you turned it on. You walk away from your laptop. You return to find three pages of your kid asking what's for dinner pasted into a Slack thread. The app did exactly what you told it to. You just told it the wrong thing.
Hold-to-talk closes that loophole the way a walkie-talkie does. The microphone is on for as long as your finger says it is, and not one second longer. There's no internal state to misremember.
Latency is honest
When you hold a key, you can feel the start. There's no “is it listening?” moment, no listening indicator to glance at. You press, you speak, you release, the words appear. Three actions, no inference.
Tap-to-toggle, by contrast, asks you to trust an invisible mode. The good apps cover this with audio cues and lock-screen badges. The great ones make those cues so loud that they cost more attention than the press itself.
But what about accessibility?
This is the strongest argument against hold-to-talk, and we take it seriously. Some users can't comfortably hold a modifier for the length of a dictated paragraph. So we ship a toggle mode too. The default is hold; the option is one settings page away.
What we won't do is make tap-to-toggle the default. Defaults shape behaviour, and the default behaviour we want is: you are always in control of when the mic is on.
The deeper bet
Voice input wants to be ambient. It wants to be ready, listening, waiting for a wake word. That's a great pattern for a kitchen speaker. It's a terrible pattern for the device you're actively typing on.
Hold-to-talk says: voice is a tool you pick up when you need it, then put down. Like a pencil. We think that's the right relationship between you and your keyboard.
Quantifying the cost of a forgotten toggle
Three of the five most-reported issues we see in dictation forums come back to the same root cause: a user forgot the mic was on. A medical professional dictating to one window forgot to stop and the next 20 minutes of phone conversation landed in a patient note. A founder left toggle mode active during a meeting and watched what their team really thought about the launch appear in a Slack draft window. The cost of one of these moments, measured in minutes spent cleaning up plus the social/legal exposure, typically exceeds a year of saved keystrokes.
Push-to-talk doesn't eliminate every variant of this failure (some users still inadvertently hold a modifier key for too long), but it converts the failure mode from a state-management bug into a physical one. Physical bugs are harder to commit and easier to notice.
Push-to-talk is faster than it looks
The intuitive critique of hold-to-talk is that it's slower than tap-to-toggle for long dictations. In our own measurements across 50,000+ dictation sessions, the median session length is 8.2 seconds and the 90th-percentile session is 31 seconds. The vast majority of real dictation is short, far inside the range where a finger comfortably rests on a modifier. The long-dictation worry turns out to be a minority case.
We also ship a double-tap-to-lock affordance: tap your hotkey twice quickly and the mic stays on hands-free until you tap once to stop. Best of both worlds for the genuinely long sessions, without making locked mode the default.
When toggle is the right pick
We aren't doctrinaire about this. Three honest cases where tap-to-toggle is a better default:
- Long-form dictation work, writers and dictating-for-transcription users who hold the mic for 5+ minute stretches and find the modifier-key fatigue real.
- Accessibility requirements where holding any key is genuinely uncomfortable. Speechcap's toggle mode is one settings page away and works identically except for the start/stop semantics.
- Foot-pedal users, if you're driving the mic with a foot pedal, the press-and-hold ergonomics that work for a finger don't translate; many foot pedals are designed as tap interfaces.
In all three cases the answer is a user-flippable setting, not a different default.
“I tried four dictation apps before settling on Speechcap. The thing I didn't expect to care about was the hotkey model. Now it's the thing I miss the most when I'm using anything else.”
Sources & further reading
- Nielsen Norman Group, Voice Interaction UX ↗Background on the trade-offs between modal voice activation (push-to-talk) and open-mic models.
- Indeed, Walkie-talkie etiquette and use cases ↗The cultural template push-to-talk dictation borrows, explicit, mode-free voice activation.
Frequently asked questions
What's the difference between push-to-talk and tap-to-toggle in a dictation app?
Push-to-talk means hold a key while you speak, the microphone is on for exactly as long as your finger says it is. Tap-to-toggle means press once to start, press again to stop, the microphone stays on until you remember to turn it off. Push-to-talk is the model walkie-talkies and voice chat in games use; tap-to-toggle is the model most voice assistants and meeting recorders use.
Why does Speechcap default to push-to-talk instead of tap-to-toggle?
Tap-to-toggle has a failure mode push-to-talk doesn't: forgetting to turn it off. We've seen real-world cases where users left toggle mode on through meetings, phone calls, and unrelated work, recording everything that followed. Push-to-talk closes that loophole structurally. The mic can only be on while a finger is on the key, so it's impossible to forget about an active recording.
Can I switch Speechcap to tap-to-toggle mode?
Yes. Settings → Activation → Toggle mode. We also support a hybrid: double-tap your push-to-talk key to enter hands-free locked recording, then single-tap to stop. This is the right setup for occasional long-form sessions without making toggle the default for short ones.
Doesn't push-to-talk get tiring for long dictation sessions?
Our measurements show that 90% of dictation sessions are under 31 seconds long, short enough that modifier-key fatigue isn't a factor. For genuinely long sessions, double-tap-to-lock gives you a hands-free mode that behaves like toggle but requires explicit opt-in per session rather than persistently across the app's lifetime.
What hotkey should I use for push-to-talk on Mac?
Right Option is the default in Speechcap because it's a key very few users press by accident (right-handed users almost never reach it). Other good choices: fn (the function key, easy to hold), right Command, or Caps Lock (rebound, macOS lets you remap it). Avoid keys you use frequently for normal typing, that's where accidental triggers come from.