[pulseaudio-discuss] Removing volume sliders from media player UIs

[Jan Braun]

Tanu Kaskinen schrob:
> I'm trying to build a convincing argument so that media player
> programmers voluntarily change their UIs.

See below.

> You didn't say why you think
> device volume in bad - I assume because you think that the natural user
> expectation is that a volume slider in an application affects only that
> application and no others.

Yes.

> And I accept that argument, and that is why
> I'm proposing getting rid of the sliders entirely instead of replacing
> the per-app controls with device volume controls.

Yes, but per-app sliders are only bad if you confuse them and the device
volume control.

> > And btw, I consider anything that involves the mouse too difficult for
> > common usage. Hence your "sound preferences" utility is not an acceptable
> > solution in my view.
> 
> In my view changing per-app volumes is not a common activity.

In my experience, it is. That's because our usage scenarios differ.
Lennart's distinction in
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-January/006334.html
|A) material you play is too faint/loud because it was digitized that way
|B) your surrounding is too silent/loud
|C) You play two things and want one thing louder then the other
is very helpful. I hope (and think; please speak up if you disagree)
we all agree that A (in an ideal setup) and C (always) call for
per-stream volume adjustment and B calls for device volume
adjustment.[1]

What we DON'T agree on is the importance of the different scenarios.
Lennart finds that "case B [..] seems to be the common case" and "Case C
you probably do very seldomly."
My experience is A:very common, C:somewhat common, B:rarely.
Joe User might (imho legitimately) have his own, diffferent view.

So now the interesting question is how do we handle (or not) these
differences?
My view is that there can't be a one-size-fits-all solution, and I
want the tools to build my personally ideal setup.[2]
Your personal/user view is "I want device volume easily accessible, and
per-stream volume may be more remote".
Your "desktop developer" view is "We need a simple, general solution
that 'just works' for the majority of desktop users". And you then
proceed to assume C is rare, and A can still be done with device volume,
so you don't _need_ per-stream volume, thus your solution is "do
everything with device volume".


[ I'm getting distracted by the thought below, and the mail is long
enough already, so I'm stopping here and give you the chance to speak up
if I was misrepresenting you: please do, I am merely trying to sum up the
discussion so far in a constructive manner. ]


I'd wager a media player developer's view would be something like "We
provide per-stream volume control easily accessible embedded in our
player, and the user probably has a keyboard knob for device volume, so
what's the problem?" And I think that view has a lot of merit.

Actually, writing this I realize we may be on the wrong track: Why do we
want to stop media player authors from embedding volume controls?
The original reason, IIRC, was that writing good volume controls is
hard and we think PA people would do a better job.
Then there was the argument it'd be better to have all volume control to
be centrally done.
Well, I don't see the point in "centrally", so unless somebody steps up
to defend that, I'll ignore it.

But wrt. writing better volume controls: I think the media player
authors will do a better job of writing the UI part of a volume control
than PA people can (after all, integrated UI tends to be better).
So why not provide a nice API for them to hook into? One that tells them
the various interesting things ("default volume", "100%", "maximum
volume", whatever you think is needed to implement the perfect control)
and lets them wonder about which key the user presses or how to display
the current volume. Pitching "look, a 0-100 scale really isn't the best
way to do volume adjustment, here's how you do it better" to media
player authors surely sounds more promising than "you're not doing
volume adjustment the way we prefer it's done, so please stop doing it
altogether and let us handle it."
And if you're really sneaky, you can add a function "the user doesn't
wish you to provide volume control at all" to that API, and if/when you
manage to convince users that the PA volume control applet is all they
want, you can remotely disable the embedded controls.
Similarly, you could allow the users to centrally choose whether they
want the embedded controls to affect the per-stream or the device volume,
if you think that's a valid choice to make.

> You still haven't convinced me to believe that you actually need to
> script your hotkeys or whatever to control per-app volumes - scripting
> them to control the device volume should work ok for you

:(
I really do need to easily control per-app volumes. I'm afraid if I
couldn't convince you so far, I'll have to give up on that front.

But can you accept that I (and by extension probably a lot of other
people not on this list) _feel_ I need this feature?
And that telling me "you don't, you should be fine with device volume"
doesn't help?
And in particular that trying to remove embedded volume controls (which
currently do provide easy access to per-app volume settings) without
providing adequate* replacement will be seen as a severe regression?

*)adequate in my view, not yours

> Anyway, the request for better scriptability has been noted.

Thanks :)

> If you think that the volume dial on a keyboard should control per-app
> volumes, that idea has been shot down. I proposed exactly that a while
> ago,

Well, I'm not a desktop person, hence I don't have a view on "in a
default linux install, x should do y." I only have a view on what x
_on_my_account_ should do. And I have tons of experience suggesting that
whatever I pick for my UI will be at least unintuitive for others and
whatever others feel comfortable using would drive me mad.
So sorry, I can't help you on that front, I'm not wired for it.

> and this is my second proposal to solve the underlying problem of
> users changing the wrong volume.

==================================================================
I think that's impossible to do within the constraints you've set.
==================================================================

> > > in addition to being mostly
> > > redundant (it's only needed when the relative volume to other apps needs
> > > to be changed, which mostly (only?) means situations where two
> > > applications are playing simultaneously).
> > 
> > If that situation is rare, there's not much point in PA, from my user's
> > POV.[1]
> 
> Then I guess there's not much point in PA. For you.

You misunderstood. That situation is extremely common for me, and that's
(mainly) why I do use and want to use PA.

> > [voip+game]
> Thank you, use cases are the best way to point out problems in
> proposals!
> 
> If the voip program is targeted solely at use while gaming (I think
> there are such programs, but I'm not a gamer myself), then a slider in
> the voip program that controls the voip volume only makes a lot of
> sense. That's because such programs are mostly run simultaneously with
> other sound sources, and in those situations it's obvious that changing
> the device volume is not the right thing to do if only one stream needs
> adjustment.

Actually, voip programs for gaming have the additional problem that
they need to present a minimally invasive UI, because the user interacts
with a -presumably fullscreen- game. Hence that slider is a special
challenge, and AFAIK no gaming voip does it, because it'd mean two more
buttons they'd have to intercept away from the game. This is another
place where I want to be able to script per-app-volume, btw.
Anyway, back to topic:

> If the voip program is targeted for general use (meaning that calls with
> nothing else playing simultaneusly are common), the volume slider
> probably causes the same problems as in media players.

There's no big diference between the two.
Mumble was explicitly created for gaming, but it's used for all kinds
of conference calls (e.g. the German Pirate Party uses it for virtual
meetings). And Skype has AFAIK no property that would suggest its use
for gaming, but people do.

> I think in a perfect world games would integrate with the audio system
> so that they would themselves offer the voip slider (and the music
> slider too, btw - I guess it's somewhat common to have a music player
> running at the same time with playing a game?), so the voip programs
> wouldn't need the slider themselves, but that seems extremely unlikely
> to become reality.

Weren't you on a quest to abolish embedded volume controls rather than
wishing for more? As I understand it, you just suggested a game should
ideally have a volume control for the music player, but the music player
should not have one for itself.

> [music while gaming]
> I don't think I have any good solutions to that problem. Arguably
> removing the stream volume slider from the music player makes the
> situation worse (but having the slider desn't completely remove the
> problem either). Would it make sense to treat the presence of streams
> with role "game" as a separate context for stream volumes? So when
> stream volumes are adjusted while playing a game, the volumes are only
> used while the game is running, and the old stream volumes are
> automatically restored when the game streams are shut down. When
> starting the game again, the stream volumes for the "game context" are
> again automatically restored.

I presented the example of system sounds, you suggested solving it by
special-casing them (ok, they are already somewhat special).
I present the example gaming, you audibly ponder special-casing games.
I'd prefer we didn't continue down this path, but since you wanted use
cases:

====> voip while listening to music <====
Damn, that's another one where I've to be prepared for the "Jan, you're
insane" counter-argument. :) But honestly, I do this. On the pro side,
it's really, undeniably, absolutely important to have per-app volume
control if you do that, otherwise you'll (deservedly) get yelled at.

> Hmm, so you are seeing the lack of scriptability as the main problem?
> Because it prevents you from scripting hotkeys to control the per-app
> volumes? If you still think that you want to control per-app volumes
> after reading this message, and after reading the discussion of my
> previous proposal, then yes, I can see why you think that lack of
> scriptability is the main problem.

I did read both, and still do want to control per-app volumes.
And scriptability is my global fix for UIs that don't agree with me.

> But personally I think this from the
> common computer user's POV, who certainly won't script anything, so I
> see things differently.

Well, try to see it this way: Once you've got good scriptability,
everyone can easily create their favourite UI, and maybe some random guy
will happen to find the perfect "common computer user" UI you're looking
for. And you didn't have to do anything but implement scripting support! ;)

As explained above, I won't be that guy. And the only way I can help
you is by telling you why your proposal X (which doesn't include
scripting support) is not adequate for me. Or by trying to dissuade you
from the notion that there actually is a solution which works for your
"common computer user".
Both may not be help of a kind you want or appreciate as such, so please
say "stop" when I should do so. :)

regards,
    Jan

[1] I'm ignoring the question whether A could be handled automatically,
because we'd still have B vs C suggesting different controls.
[2] This happens to be both my "user" and "developer" view. As a user,
there's nothing pre-canned doing what I want and I don't mind rolling my
own, and as a developer, if everyone can create their favourite
interface, well, they should do that. And the desktop people will
probably create something for the DAUs.
-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100501/88a63af1/attachment.pgp>