Re: [Usability] New Sound Preferences and Volume Control
- From: Jacob Beauregard <deadowlsurvivor gmail com>
- To: usability gnome org
- Subject: Re: [Usability] New Sound Preferences and Volume Control
- Date: Wed, 19 Nov 2008 19:53:44 -0500
On Wed, 2008-11-19 at 12:00 +0000, usability-request gnome org wrote:
> Send Usability mailing list submissions to
> usability gnome org
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> usability-request gnome org
> You can reach the person managing the list at
> usability-owner gnome org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Usability digest..."
> Today's Topics:
> 1. New Sound Preferences and Volume Control (Frederic Peters)
> Message: 1
> Date: Wed, 19 Nov 2008 12:23:19 +0100
> From: Frederic Peters <fpeters 0d be>
> Subject: [Usability] New Sound Preferences and Volume Control
> To: William Jon McCann <jmccann redhat com>, usability gnome org
> Cc: Callum McKenzie <callum spooky-possum org>
> Message-ID: <20081119112318 GA11682 entrouvert com>
> Content-Type: text/plain; charset=us-ascii
> Hello William, hello the usability team,
> We are still early in the 2.25 release cycle and I think this is the
> right time to discuss the future of the Sound Preferences and Volume
> Control, in a PulseAudio world.
> I had a quick look through usability-list archives and didn't find
> the subject discussed, please correct me if I missed a discussion;
> and please do note my comments are based on a snapshot I built
> Anyway, I'll dive into the matter and point everyone to the currently
> developed gnome-volume-control (hosted in gnome-media/ repository).
> Here is how it looks like:
> My major concern is the merging of prefs and volume control in the
> same window; especially as "Sound Effects" is the first pane, and the
> treeview doesn't fit a window of that dimension; compare with the 2.24
> Sound Preferences:
What I notice more: Multiple volume bars are visible at once (as output
volume is always visible), and context could be confused.
I'm thinking that the "Output Volume:" label could possibly be replaced
with a drop-box containing input volume, output volume, alert volume,
and active application volumes would be more presentable and less
confusing, as well as give additional real estate to the tree view.
Also, in that sense, the input and output panes could possibly be merged
(Which is a bit odd because then it would be like a prettier version of
the old sound preferences).
Perhaps further, the applications pane could list active application
volumes and inactive application volumes. I say active applications in
the sense that some applications aren't always providing you with active
streams when they're open, and some streams are particularly short-lived
(ex. pidgin), and all-in-all it's good to have fast access to it's
volume if it's open. Inactive streams in the sense that volume would be
a saved preference. That's more functionality rather than presentation.
> My other concern is that in normal use, of all four panes, I will just
> be interested in a few widgets, output volume and input volume, plus
> whatever is playing at the moment; and all that would fit very well in
> a small window; as I was looking for discussions on live.gnome.org I
> stumbled upon this one: http://static.flickr.com/20/70003494_668cfdc0dd.jpg
> Finally I am also concerned about the rewrite of the mixer applet as a
> notification area icon (just like I am concerned with every other
> abuse of the notification area), especially as it would be a
> regression in this case. Could required enhancements to the applet be
> discussed in the open? (I added Callum in CC).
Sorry, this is a bit random: Severe weather notifications would be
In any case, I agree with your concern about the the notification area.
Probably the easiest way to correct its misuse would be to find a better
means of generalizing it. It's functionality seems most comparable to
the brightness applet, though I don't think that would be the best
generalization due to how extremely limited it is.
> Thanks for reading,
> Usability mailing list
> Usability gnome org
> End of Usability Digest, Vol 55, Issue 15
] [Thread Prev