The floating player bar on mobile: listening that does not stop when you scroll
On a long article read on a phone, the audio player disappears off the top of the page as soon as you scroll, and the listener has to scroll back up to pause. The floating bar fixes that. Here is its real behaviour on mobile, described from what is actually implemented, limits included.
An audio player sits at the top of an article. The listener presses play, then scrolls to read along. Two paragraphs in, the player has left the screen off the top. If they want to pause, skip back, or just see where they are, they have to scroll the whole way back up. On mobile, where articles are long and the thumb scrolls fast, that little round trip is enough to make people give up. The floating bar exists for that, and one thing only: keeping the player within reach as you move down the text.
What it does, from the visitor's side
The principle is easy to describe. As long as the player is visible at the top of the article, nothing moves: it is an ordinary bar, in the flow of the page. The moment its slot leaves the screen off the top, it detaches and settles at the bottom of the window, shrunk to a pill: smaller, rounder, with a stronger drop shadow so it stands apart from the article instead of blending into it. The article label disappears, because by then you already know what you are listening to. When you scroll back up and the original slot returns into view, the pill drops back into place and becomes the bar again.
So the listener keeps the play button and the progress in sight at all times, without ever leaving the paragraph they are reading. That is exactly how the news sites the request comes from behave.
The technical point, said without hiding it
There is a truth worth stating plainly, because it explains part of the behaviour. The player is served inside an iframe, and a fixed position inside an iframe anchors to the iframe, not to the phone's window. The player therefore cannot detach on its own. The host page does it, on request: our embed script watches the scroll, and when the player's slot passes the top of the screen, it is the script that fixes the bar at the bottom of the window, centred, twelve pixels from the sides and fourteen from the bottom. The player, for its part, only carries the appearance of the two states, docked and detached.
The honest consequence: with no cooperating host page, there is no floating. On a site where only the player is embedded but not the script that handles scrolling, the floating bar stays a bar. It breaks nothing, it simply does not float. It is the same fallback principle as for the other models, which we lay out in which audio player template for your blog: a player that cannot do better does the bar, never anything broken.
The details that matter on a phone
Several choices only show on mobile, and each answers a fault seen on a real phone.
Detachment does not arm on page load, but on the first scroll. The reason is concrete: at load, the iframe is not always placed, its rectangle reads zero, and a bar could then think it had already left the screen and stick to the bottom before anyone had scrolled, leaving a large gap where the article should be. Waiting for the first scroll gesture removes that false start.
When the bar detaches, an invisible spacer takes its height in the flow of the article. Without it, the text would jump at the moment of detachment, the page would shrink, and the player would drop back at once because its slot had returned into view. The spacer keeps the layout stable.
The floating bar carries a close cross: a listener who does not want it dismisses it with one tap, for the current article. Nothing is remembered, so closing the bar on one article does not deprive the listener on the next. And scrolling back up over the player re-arms it. Finally, below 460 pixels wide, the label hides so it does not push the duration onto the speed button, and the detachment motion is removed for anyone who has asked for reduced animation in their system settings.
When to choose it, and how
The floating bar is made for long articles, the ones you read while listening across several screens of scrolling. On a three-paragraph brief it adds nothing: the player never leaves the screen. On an eight-minute feature read on a phone, it changes the experience.
The setting lives in your dashboard, and it also works as an option on the other templates, under the name always-visible player. To try it on an article without saving anything, an address parameter is enough to force the behaviour for the length of a test. The audio player page shows the models in context, and our WordPress page describes how the embed script sits on a site, since it is the script that makes floating possible. That is the one real prerequisite: the player alone is not enough, you need the host page with it.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo