← Back to team overview

unity-design team mailing list archive

Re: Two suggested designs for the Sound Indicator

 

2010/5/4 Martín Soto:
> 2010/5/3 Diego Moya:
> IMO, we should start by getting rid of the system-wide volume. It adds lots
> of complexity without providing any significant advantages.

It has one killer feature that can't be obtained with individual
application controls: dimming all sound from the computer quickly with
one single gesture. Also we shouldn't get rid of the global mute
control, which is absolutely indispensable.


>
> Setting the volume in this case should be absolutely straightforward but
> it's not in current Ubuntu. You have to deal with two sliders, one usually
> inside the player (e.g., the button/slider in Rhythmbox's top-right corner)
> and one in the volume indicator that interact with each other in a funny,
> unintuitive way. Sliding any of them down, for example, will mute sound, but
> if you want to reach the maximal volume, you'll have to slide them *both*
> all the way up. Of course, if you understand that the sliders correspond to
> two separate volume filters that are connected serially, you'll be able to
> deal with this system just fine. But most people won't grasp this--or at
> least, it will be a long time until they do--and they'll be confused and
> frustrated.

I agree with you in this - separate cumulative sliders are a
nonsensical way to manage global sound. I preferred the old approach
where sliders inside music players set the global volume instead of a
per-app setting.

The last time this subject appeared in the gnome-usability list I
proposed a sound-follows-focus approach, where the current focused
application gets volume priority and other applications are dimmed
when they produce interference.



> Consider, for instance, someone who is listening to a single sound source,
> such as a music or video player. I'd say this is, by far, the most common
> use case we have. Unless you're a sound engineer or some such, this is what
> you're likely to be doing 99% of the time your sound card is active.

> You speak about "all applications". How many applications do you expect to
> have running and producing sound at a given time? I'd expect a maximum of
> two, and that only for the relatively unusual cases where people talk on the
> Internet phone and listen to music or watch videos at the same time.

The user may very well be actively using just one or two applications,
but the system has ideas of their own. This is your common scenario in
reality:

- playing a background music
- using a primary application that generates sounds (a Flash
videogame, an editor with audio feedback for commands, a phone call)
- while the IM is connected and sending audio feedback for peers
messages and status change
- and the operating system generating sound for alerts, window
management and button clicking.

As you see, the common case has at least four different sound sources,
and it doesn't require talking to the phone - any major sound-enabled
application fits the scenario.



> My guess is that this relative control would be unintuitive for most people.
> All sound sources they deal with in the real world (TV, stereo, phone, etc.)
> have absolute volume controls, not relative ones. If you want to talk on the
> phone and listen to music at the same time (which is rather unusual because
> most people will turn off the radio, anyway) you just fiddle a bit with both
> the phone and the radio until it's OK for you.

Physical volume controls are a lot easier to set up than virtual ones,
that require surgical precision point-and-clicking and incremental
revealing just to reach the slider, and then dragging a hand-sized
widget across the table.

Also we have the power of a general CPU at hand, we should be
automating tasks as much as possible instead of forcing the user to
handle all sound sources one by one. My idea above for focused sound
is but one possibility for this automation. Individual application
controls should be available so that user doesn't lose fine control,
but only when the default system behavior is wrong and must be
overridden. User-centered design tell us to maximize user control
while minimizing required work.



References