Re: [Usability] New Sound Preferences and Volume Control

On Fri, Nov 28, 2008 at 10:07 AM, Florian Ludwig <dino phidev org> wrote:
> On Thu, 2008-11-20 at 23:24 +1100, Andy Owen wrote:
>> This is mostly related, but kind of not related. I think that instead of
>> (or at least as well as) having a list of all applications with audio
>> happening, so you can modify their volume, there should be a volume
>> slider as part of the window decoration.
> Hello,
> One use-case i image of the list of all "sound emitting" applications:
> To check that pidgin and ekiga are louder than rhythmbox to make sure I
> hear the phone ring. That wouldn't be that easy with one short look as
> it is with the list so IMHO this can not replace the list view.
> (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.)
> 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.
> Do you think it should be accessible through the right click menu of the
> window list?

I think it's OK to use the title bar and window menu as places for
standard controls that large classes of apps have and that are used a
lot on those apps. Users would discover it and habituate to the ease
of use.

I think that volume control is not changed separately per-app often
enough, though I may be convinced otherwise. The use case with a phone
and a music player should be handled automatically: the system should
make sure that the phone is audible above the music. Of course, that
can be tweaked by the user, but it would not be tweaked often, just
once.  I am not familiar with the app mentioned at so I don't know if it
represents a common use case.

But other controls may fit the description. For example, MS Office has
an app menu in apparently in the title bar. If the app does not
support a particular kind of control, no additional control should
appear in the title bar or window menu. For example, xterm should not
have a volume control anywhere, not even one that is grayed out. An
additional control placed in the title bar or window menu should still
be available in the app in its traditional place.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]