← A Voice Reader for Simply Broken
v3 · the listen dockA capsule that grows into a panel
The inline player in v1 works, but you have to find it. A reader should be startable from anywhere in the article and reachable once it is running. This is that control — and it is live on this page, bottom-left. Press it and it opens.
“We should add a clear floating place to start voice, maybe a play button bottom left corner which turns into a full control panel once the voice starts and shrinks back if you stop hearing the article.”
01 · Prior artEveryone who has solved this built a bar
Spotify, SoundCloud, YouTube Music, Substack, Audible and NPR all use the same shape: a bar fixed to the bottom edge, visible for as long as there is something to play, which opens into a taller view when tapped. The corner capsule is the rarer choice. Medium's Listen feature and the Speechify extension use it — and both still become bar-shaped the moment they expand, which tells you the capsule is really just the closed state of a bar.
So the honest reading of the research is that a capsule is a legitimate closed state, not a different pattern. That is what is built here.
02 · The cornerWhere the general advice is wrong for this site
Thumb-reach research — Hoober's grip studies and the reach maps built on them — puts the easiest one-handed target at the bottom centre, then bottom right for the right-handed majority. Far corners are the hardest to reach. On that basis bottom-left is the worst of the three, and the research came back recommending against it.
This site already floats a control. feedback.js pins its Edit-text and
Notes bar to right:14px; bottom:14px, and floats its confirmation toast
at left:50%; bottom:74px. Bottom-right is occupied and bottom-centre is
occupied.
The left corner is the only free one, so it wins on the constraint that actually applies here rather than the one that applies in general. A dock that is easy to reach and sits on top of the Notes button is not easy to reach.
Two details that follow from being in that corner. The dock is anchored with
env(safe-area-inset-bottom), because iOS Safari puts its own toolbar and
the home-indicator gesture strip in exactly that band. And on a phone the open panel
lifts clear of the feedback bar rather than fighting it for the same 60 pixels.
03 · The two statesWhat each one earns
One play button and nothing else. A control that has not been used yet has not earned any more space than that.
Play, skip fifteen either way, speed, close — plus the title, a scrubber and the times underneath.
What is deliberately absent matters as much. No volume, because the phone has hardware buttons for it. No artwork, because this is one article and not a queue. No narrator picker, because there is one voice. Every control has to pay for its footprint, and on a bar this size the rent is high.
04 · The one behaviour I changedIt does not shrink when you pause
The brief said it should shrink back when you stop hearing the article, and it does — when the article ends, or when you close it. But it deliberately stays open through a pause, and that is worth defending.
Someone who pauses is usually about to use the controls: jump back fifteen seconds, slow it down, re-read the line they missed. Collapsing on pause takes the controls away at the exact moment they are wanted, and then makes them tap twice to get them back. Spotify, Substack and Audible all keep the bar through a pause for this reason.
So: open on play, stay open through pause, shrink on end or on close. If that reads wrong in use, it is one line to change.
05 · One sound, two viewsThe bug this avoids
A page with an inline player and a floating dock has an obvious failure mode: two
<audio> elements, both playing, drifting apart. The dock never
creates its own. It looks for [data-sb-audio] and adopts the element the
page already has, falling back to making one only when there is none.
Both surfaces then read state from the same element's events and write it by calling the same element's methods. Neither keeps its own idea of whether sound is playing, which is the only arrangement that cannot drift.
| Decision | Value | Reason |
|---|---|---|
| Corner | bottom-left | The only one not already occupied on this site |
| Open trigger | tap play | Never automatic; nothing moves until asked |
| Close trigger | track ends, or the close button | Not on pause |
| Motion | 280ms cubic-bezier(.2,0,0,1) | Confident, not bouncy. A spring would read as a toy |
| Reduced motion | no transition at all | State change without the morph |
| Bottom anchor | env(safe-area-inset-bottom) | Clears Safari's toolbar and the home indicator |
| Lock screen | seek handlers, not track handlers | iOS shows one pair of icons or the other |
The article also gains bottom padding while the dock exists, so the last paragraph can always scroll clear of it. A floating bar that permanently hides the final lines of a piece of writing is a poor trade on a site that is mostly writing.
06 · Try itBottom-left, on this page
The dock on this page is loaded with the same three-minute sample from v1, so it is a real control and not a drawing. Press it, background the tab, lock the phone, use the AirPods. Then tell me whether the corner is right, and whether staying open through a pause reads as helpful or as clutter.
Still open from earlier versions: the voice, the scope, whether images get described, and whether the AirPods buttons skip or switch tracks. None of them depend on this.