Re: [Usability] New Sound Preferences and Volume Control

["Philip Ganchev" <phil ganchev gmail com>]

On Thu, Dec 11, 2008 at 8:16 AM, Diego Moya <turingt gmail com> wrote:
> Now that we have some more or less clear scenarios, the first design step
> should be defining a list user needs, before we think of any possible
> controls to cover them. These are the ones I've identified:

I think what you have listed are again use cases (scenarios) which add
to the ones I listed earlier. I don't see how they are different than
use cases.

> * Current application is too loud -> only emergency case,  there should be a
> quick access to a function that mutes all sound (and a way to limit volume
> before deactivating the mute!).
>
> * Refine volume in a multimedia stream. Only case that really needs fine
> control, IMHO.

I might be missing something. For both of these, why not just adjust
the master volume (or the speaker knob)?

> * Make sure that any possible sound is not louder than X decibels (think
> "late at night"). Only case where a global setting is really needed. A
> slider doesn't guarantee this, by the way - this should work as a global cap
> on sound.

This is interesting (though a rare use case). It can be a setting in
the master volume control. The user should hear her loudest volume
setting as she sets it. She won't know how many decibels she needs.
But how will the volume be corrected if an app outputs volume that is
too loud? Will the system just output the max volume at the same
frequency? Or will it scale the app's volume to avoid distorted volume
ratios? Or scale the volume based on a moving window (thus distorting
the volume ratios somewhat)?

> * Make a system sound (warnings, interface feedback) louder or softer than
> another kind of sound. Best fit should be a priority based control - but not
> necessarily a list of all applications, more like a temporary "muffle this
> sound source".

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. Tweaking
should be possible, but since it will be rarely done, the interface
should be out of the way.

On the other hand, interface feedback (such as when you minimize a
window) is never useful, rarely bling, and almost always irritating.

> All scenarios described in previous posts (presentation mode, mixing several
> streams…) are particular instances or combinations of these needs.

Presentation mode was a solution to the use case. Mixing is done by a
sound mixing application, no?

> 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.  Thinking of complete
control can also lead to designs that require user interaction: seting
preferences, experimenting to find the right preferences, etc. We
should think about how to minimize interaction for as many cases as
possible; and only for rare cases when we can't, try to give easy
complete control.