On 06/12/2008, Kirk Bridger <[EMAIL PROTECTED]> wrote: > > I think we have a basic question here that nobody is really asking: are > users going to want to adjust volume per app? Yes, I know some of us may, > but would users really use it? > I'd say no, most of the time. It only makes sense in specific situations. And then, it does matter in a relative sense - that is, I want the phone ring to be louder than the music player, and system sounds to be softer. I don't want multimedia sounds at 75% and system sounds to 30% volume.
This is further complicated with its relation to the system volume, which controls all applications at once. I don't believe a slider in each application makes this relations any easier - unless you completely remove the system volume, which I hope you'll agree is a bad idea. > 2008/12/7 Andy Owen <[EMAIL PROTECTED]> > The > problem is that until recently, no mainstream OS has had the sound > system powerful enough to manage the volume for individual applications. > As a result, people have been trained to think that volume settings must > be done the way they are done now. People use a main volume not just because of habituation, it's because a single control point is what makes most sense. One set of speakers, one desktop-wide volume dial. The redundancy between the physical dial in the speakers and the virtual one in the panel already introduces too much confusion. Why would we want to multiply that confusion with a per-app setting? The problems with per-application volume are: - it requires a lot of work to configure each application separately. - is a model that conflicts with the system volume. If I have the desktop panel volume to three quarters, and Totem to one half, which one should I turn up to increase the movie volume, and how much? On 06/12/2008, Kirk Bridger <[EMAIL PROTECTED]> wrote: > I think right now pulse audio lets me do it, and I like the idea, but > man is it a lot of work to make adjustments to all those volume > sliders. it's much easier to just stick with what is set right now > and adjust the dial on my speakers, seriously. You are spot on. As it's the easiest path the volume control in the Gnome panel is what will be used 99.5% of the time. Because it's there, because it's easy and because it gets the work done. Everything we discuss here should take that into account. 2008/12/7 Andy Owen <[EMAIL PROTECTED]> >I used to use the dial on my speakers, so I know exactly where you are >coming from. My current method of working is to only adjust the master >volume, by putting my mouse over its icon and using the wheel. This is >really convenient and responsive. You do realize this interaction is only available to power users, right? Using the wheel on a button is not discoverable. For this to work for the common user there should be a visual hint. I've always defended in this list that the volume control in the Gnome panel should have a slider always visible, not hidden behind a click. That way everybody could benefit of that "putting the mouse over the control" instant adjusts, even if nobody has told them the wheel trick - or when they don't have a wheel mouse (think tablet PCs, touchscreens, accesibility devices...) > > > The other thing is that many of our applications already have a volume > slider, but I haven't seen anyone proposing, or even considering > removing them. No, but that doesn't mean that it should control only that application. Having a slider in the movie player makes sense because of convenience: its a bigger target than the small volume control in Gnome panel, and its slider is always onscreen but the panel slider is hidden. My preference in other OSs always has been for the movie player slider to also control the system volume; Windows does it, and it's something that it gets right. > Doing things the way I've described would mean that those > applications with their own volume slider could be made consistent with > each other (since they would all have the exact same volume controls). Being consistent does not make it a good interface in this case. It's just exposing the API so that the users have to directly control the PulseAudio features, by hand, without any possibility to automate them. I'm against having a raw per-application slider. At least my proposal to control at once all applications in the same category would reduce the work required, and it allows the occasional fine control of a single application (creating a new category for it). I prefer a sound scheme where one just specifies the relative importance of different sound sources, instead of having to set each one of them with an exact value. Not forcing the user to use any of those extended sound controls, everything should be controlled through the single volume control in the panel, but still taking advantage of the new PulseAudio possibilities through the default priority settings. > If I have music playing and I'm > watching something on youtube, I will pause the music player - most of > the time this is not what I actually wanted to do, as I typically want > to turn down the volume of either the video or the music. The best thing > for my case would be to have an icon in the title bar of the application > that I could just mouse-wheel over to adjust things. This scenario would be covered both with my suggestion for "sound focus follows active application", or the priority lists. It would work automatically to prioritize the youtube video when changing windows, without forcing you to pause or adjust volume. > I'm all for usability tests (though I suck at designing them). But if > someone can design a test that doesn't suffer from the problems I talked > about before, then that would be very interesting. I'm just nervous that > we'll end up doing a test in such a way that we never get anything new, > because people don't even realise that things are possible. > You don't do tests to discover new behaviours, you do tests to find if your proposed new behaviours can be used by people other than you. To invent new possibilities you have to watch real people using the system and find out which goals they satisfy with it, and wheter there is something that gets in their way. In this case, putting a slider in each application is not the simples interface possible to solve the scenarios presented above - it introduces more complexity than it removes.
_______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
