Yeah, but the trick is in how we define the "control" needed. Just because it has always done through a slider doesn't mean it has to be that way, in every situation. When the user don't care about a precise volume but just a relative setting, a different interface could provide better control with less effort.
I have a design proposal for a really simple interface that would address many of the scenarios described in this thread and provide direct control with just a few clicks. I expose it here for your evaluation.
The interface idea is based around the "sound focus" concept that I explained in a previous message in this thread: applications with the focus will play louder than those without it, thus creating a two-level relative priority set.
* The basic interface is an enhanced gnome-panel volume control. I've created a mockup:
http://www.flickr.com/photos/33364508 N04/3108031818/
This replaces the old, too small volume control with an slider (always visible) that allows for direct volume control with one click - important for users without mouse wheel, using a laptop trackpad, a tablet touchscreen or an accessibility pointing device.
You'll notice that it also includes a "pin" button, which is intended to control the "sound focus".
By default, a "focus follows mouse" mode is enabled - every time an application window gets the system focus, it will also take the sound priority and play at full system volume, as set at the panel slider. Volume for all other applications is reduced, giving priority to whatever the user is doing at the moment.
* For the multimedia scenarios, where a background application must still play at full volume, the "pin" allows the user to permanently set focus to the media player:
http://www.flickr.com/photos/33364508 N04/3108031820/
In this mockup you can see that Totem has bin pinned. This way, music will play at full volume even when the user switches to work in other applications. Both Totem and the current app will play at the volume defined by the slider, all others will be diminished by a sensible amount.
The interaction needed to assign focus is as simple as "focus interface on the application window, click on the pin icon - (click again to remove focus)".
* This concept does scale in an easy way, allowing user to pin-up as many applications as they wish. All pinned applications show in a menu that appears on mouse hovering:
http://www.flickr.com/photos/33364508 N04/3107304015/Including some special categories for system sounds, the user can even create their own desired scenarios deciding whether warnings are or not important to any given situation.
On 13/12/2008, Philip Ganchev <
phil ganchev gmail com> wrote:
> Didn't we establish that warnings should always be louder than the
> application, except for full-screen mode where only critical warnings
> will be louder? If the default volumes are good, then tweaking these
> defaults is a rare use case, which would be a great thing.
Not necessarily. I'm wary of saying the word "always" when creating interaction designs for general population, because you'll probably find an exception to the rule. If you have created a fixed design for the general case the user will be helpless when the exception happen.
In my proposal, for that presentation mode in which only the selected application is allowed to play sound, a simple "mute all applications not pinned", similar to the existing "mute all sound" option, would provide the required functionality - with an important advantage:
- instead of relying on programmers introducing a presentation mode in their apps, the user can decide which applications will have that mode and when have to enter it.
- better yet, the user can override some of the programmer decisions, by pinning up some other application (such as system warnings) and thus allowing them to sound during the presentation, if that's what the user wants.
I think this interface solves the user needs to "never play something too loud", "have relative sound levels between apps" and "fine tuning of multimedia streams". All adding one simple widget to the standard interface. This is what I meant in a previous message when I talked about creating a simple interface that covers user needs.
This example is not a closed proposal, just a way to show that it IS possible to find an interface that is a direct mapping of user goals to interface controls, as long as we allow ourselves to depart from the tried-and-tested and venture into "what if..." designs, always with the goal to satisfy some clear user needs in mind.
> > We should aim to provide an interface that satisfy these user goals in an
> > easy way, so that the user has complete control over the things that really
> > matter. This way she can tweak them at her will in ways that none of us
> > could think of in advance.
> Sure. But thinking about complete control first often leads to a UI
> that is unnecessarily (or bewilderingly) complex. The controls should
> be out of the way for the vast majority of users who will not need
> compete control if the defaults are good.
The guideline is providing complete control, but only for things that really matter. This way you empower the user without adding unnecessary complexity, and without falling to the trap of thinking that a fixed "good default" will work thus further refinement controls can be hidden away.
To summarize the benefits of this proposal:
- The user has absolute control as to what sound streams are important at any given moment.
- Sound prioritization works even without user interaction, through the "focus follows selection" feature.
- Setting a different priority profile can be as simple as three clicks (1-select desired volume, 2-switch to desired application, 3-click the pin icon)
The main drawback is that it introduces a new concept to sound management. It might produce some confusion at first, but I think its workings are easily discoverable through a little :
- in the default mode, sound is diminished as soon as the window loses the mouse focus. This will introduce the user to the sound prioritization.
- the pin icon is clearly visible and always on screen. A good tooltip or label could inform the user about its function (something such as "Fix this application volume", which should be clear after experiencing the changes in priority) and teach the sound focus concept.
