Volume control and Pause/Play toggles are inconsistent, why?

Question

I'm facing a UX struggle that I've never noticed before, and even though the behaviour is what everyone expects, feels right, and is fine, in the end, it's just not consistent. Let me explain.

You have a music control, say, in any playlist app.

You have the Play/pause button, usually a volume bar (that is irrelevant here), and a Mute/Unmute button.

All those controls are "toggles", they stay in their state until you press them again. Again, I'm keeping it simple and ignoring the fact that the volume bar at 0% might switch the mute button to visually show there is no sound, but that's not the point here.

Let me get to it.

If I look at the pause button, it's displaying the state I can go to ; I'm currently playing, and I can switch to pause. It's displaying my future state.

While the mute button is displaying my current state. It's a little speaker icon with waves on the side, and this is my current state. Pressing it will show a speaker with a strike on it (please edit to correct my english here). It's displaying my current state.

Both these buttons switch my current state to the opposite state, they're both toggles, but both have opposite behaviours in terms of UI. Yet, this is what everyone expects and even I agree with it.

Still, it seems inconsistent, I wouldn't do it like that with any other control than that specific music situation.

Does anyone know why? How? Is it historical? Is there a reason I'm overlooking? This is really itching me.

Answer 1

The ambiguity of toggle buttons

As for the pause button, this is part of the inherit state/action ambiguity that is inherent with toggle buttons. See this answer and this thread for more.

Command vs Query

From a cognitive perspective, the question a designer needs to ask is whether the user will be in query or command mode.

In query mode, the user wishes to obtain information from the interface (ie, input/perception), so the toggle button should show state.

In command mode, the user wants to perform an action (ie, output), so the button should show action.

Since you can assume that there is already an auditory feedback that the audio is playing, a second visual indicator is somewhat redundant. The likelihood is that users will wish to pause/start the audio, so the button shows action.

Volume slider/icon coupling

More than a few audio control designs (say that on the MAC) have the volume slider and the speaker icon linked, where moving the slider will change the icon (more or less circles, and cross if muted).

So the icon is really a visual indicator. The fact that clicking on it mutes/un-mutes the audio is a form of a shortcut, saving users the more physical sliding action.

Although it is not exactly a convention, you may get similar behaviour even when the slider and icon are not linked.