Re: [Usability] New Sound Preferences and Volume Control

[Jacob Beauregard <deadowlsurvivor gmail com>]

> On 13/12/2008, Jacob Beauregard <deadowlsurvivor gmail com> wrote:
> 
> > Volume has too many personal and environmental influences to create an
> > interface simpler than letting the user directly control the volume. I
> > believe I've already listed off quite a few of them.
> 
> 
> 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.
> 
It looks functional but confusing.
Most confusing part is that the slider contrasts very little with the
background.
There are multiple icons in addition to the control 
--They all describe different states of the same thing (adding to confusion)
The pin doesn't fit the situational context

The entire focus concept
-only generalizes in the context of multitasking with multimedia, if that
--(e.g. browsing youtube while playing music)
--generally would not follow the mouse, but perhaps the introduction of audio streams
-is lowering sound level better than pausing a stream?
-should focus start/stop when streams from other applications output little to no sound?

Sounds interesting, but would need to be far better defined before its feasibility can be determined.

Congratulations: only creative idea that I interpret to have potential
(I consider my ideas obvious, rather than creative)

> * 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: </archives/usability/attachments/20081214/1e92fb76/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
> 
> 
> End of Usability Digest, Vol 56, Issue 20
> *****************************************