This discussion is interesting, and it made me think of a question I
don't know the answer to: Do users actually want to adjust volume for each application? I already find it annoying having to adjust volume system-wide now. Do I really want to have to adjust per window? Put another way, isn't there some way we can just intelligently guess which apps should be louder? For example, the application I'm currently working in versus background. Application notification vs application output (like music players). The use cases for volume aren't all that complex, but this discussion feels like it is becoming complex. Are we overthinking things here? I've seen a few mockups, could we put these in front of real users and ask if application-specific volume changes are even a task they'd want to perform? It just feels a little overly complicated. Kirk Andy Owen wrote: (mostly related: IMHO a more important issue is that the volume control through the list is not the same as for example Totem's volume control. Having to check two places where one application is silenced sounds like a bad idea to me.)Yes, it is bad, but if there was a standard volume control thing for each window, then an application like totem doesn't need to implement its own volume slider (so it would probably want an API that could tell it if it needs to provide a volume slider or not).A unified sound management would be nice but *I* would not search sound control in the title bar as it - from my point of view - reflects the "window management" (meaning the visual appearance (size..) of the window, something "meta" to the actual application). I would expect controlling actual "content" of an application is done within the window and right now i count sound to this "content". Also one simple aspect of having the volume control icon in the title bar that makes it less discoverable is that the icon smaller in most cases - as it is in the mockup. Of course, once used to it, it is probably easier to find in an app new to the user and so worse it.I think we have different mental models of a window then. I think of sounds as something coming from windows (even though I can think of obvious ways to do things so this isn't the case). And as a result of this, I see the size of a window as the same type of meta-information as the volume of the sound that is being produced by that window.Do you think it should be accessible through the right click menu of the window list? Mockup: http://static.ludwigf.org/stuff/gnome-use/volume-bar.pngThat looks good. I do seem to remember there was some effort to try to reduce the number of items in that menu though, and given that there is a whole lot of space on the title bar that is generally unused I put it there (and it made doing my mockup easier). Your point about the icon being small is valid, but I also think that everyone manages to find the 'close' button in the window decoration.Is sound that important? How many applications do you use that does any kind of sound? Asking myself that question I realized: all of them I use right now. (assuming it would work for epiphany and all content it can embedded) But how often do you change the volume of a single application? I'm not sure but it looks to be a non-regular task to me.The reason I don't modify the volume of a single application is because it is a pain at the moment: Pulse-audio case: 0) I need to install the pulse audio volume control 1) I need to launch the special volume control 2) I need to pick the right tab in this application, then find the application I want from a list and adjust the volume Application-specific case: (rhythmbox in Ubuntu 8.10 is my example) 1) Using the scroll wheel over the icon doesn't give visual feedback, which is even more important because of 2 2) Latency is really bad. As a result, I tend to just use the system wide volume setting. If I could modify the volume for an application by moving my mouse over the volume icon on the title bar and scrolling the wheel on my mouse, then I would be very happy.A side note: If it would be in the right-click menu should it be disabled or hidden if the sound doesn't emit any sounds? As hiding changes the length of the list I thought its a bad idea but later on noticed the "Move to Workspace Right/Left" actually acts like this. But... I never noticed until today.I was thinking that it would only appear for applications that make sounds. Again, I suspect we would need to have some sort of API to say "I'm an application that will play sound, but I'm not doing so now". So by default, an application only gets these items if it would appear in the pulse-audio application list (and if it disappears from that list, then it loses its volume controls). Once the developers for the specific application update it, then the application will request volume controls at startup, and they will persist. This would also be where the application could do whatever the sane thing to do is when it has multiple pulse-audio streams, and also find out if it needs to display its own volume sliders (in case pulse audio isn't running).Florian PSS I found a posting about this on brainstorm.ubuntu.com http://brainstorm.ubuntu.com/item/15988/_______________________________________________ Usability mailing list Usability gnome org http://mail.gnome.org/mailman/listinfo/usability |