Re: [Usability] New Sound Preferences and Volume Control



First, I have another idea:
What if the per application volume control (volume control being in the
applications GUI), could expand into a drop box with volume control for
other open streams? It would certainly be a bit more intuitive, but
would probably need to be a bit less powerful than the centralized
control.

Now I'll respond to this:
> > > 6. User is away from the computer - louder notifications
> > 
> > This can be detected automatically in many cases through the screen
> > saver.
> 
> You talked (in comments I snipped) about presentation mode
> for presentations and movies, which I totally agree with.
> But what about music presentation mode?  I have speakers
> in my house outside my office.  Sometimes, I play music
> to listen to around the house, especially during parties
> and such.  The music is clearly the most important thing,
> even though my screen is locked.
> 
> > By the way, I don't see a need to control the volume of multimedia
> > applications separately. If you think of it, unless you are a multimedia
> > freak who enjoys playing five videos simultaneously to show the power of
> > his processor, you don't want to play more than one think at a time.
> > Either you have some music or you have a movie running, and that's it.
> > This means that a single slider for multimedia volume should suffice.
> 
> http://en.wikipedia.org/wiki/Dark_Side_of_Oz  ;-)
> 
> --
> Shaun

This makes me feel like no one read my last message in this topic
(except perhaps Shaun), because I mentioned this quite a while ago.

I REPEAT:
------------------------------------------
-Centralized Control
---IMO: Regardless of the benefits of direct association, a centralized
control should be implemented, and there are many reasons to do this.
-Direct Object Association (for applications with sound)
---Volume Control on Title Bars
------Neglects GNOME users that don't use Metacity
---Volume Control as GUI control
------IMO: Should be in the HIG as require for an application using
sound.
-Sound Prioritization
---User's likely would not configure beyond default prioritization
unless it impacted their continued normal use of the computer.
---Components:
------Multimedia
------Temporary Sounds
---Scenarios:
------Multimedia
---------Watching a video
---------Listening to music
---------Playing a game
---------(...)
------Temporary Sounds
---------Messages
---------Errors
---------Interface feedback
------------(Ex. minimizing a window sound effect)
---Scenarios which do not support the most common scenario-based
prioritizations.
------A user may play music in the background of a quiet video (ex. a
Silent Film)
------A user may mute a movie and play music (ex. The Wizard of Oz/Dark
Side of the Moon)
------A user may play music in the background while playing a game
(often muting the game's music if it has music, but not necessarily the
sound effects)
------A user may want to receive alerts/messages while performing any of
the tasks above

-Temp sounds may interfere with multimedia, but not vice versa.
-Multimedia may interfere with other multimedia.
-Temp sounds should not interfere with other temp sounds.
-Temp sounds and multimedia may interfere with audio input.
-A user may currently (and intentionally) prioritize a temp sound
produced by an application by not muting sounds in that application.

Problem:
-Turning off undesired sound interferences isn't easy or intuitive
---Impacts multimedia
---Primarily caused by temporary sounds of other applications
---The majority of the time, existing multimedia will interfere with
other multimedia
Opportunity:
-A centralized volume control that aggregates application-specific
volumes simplifies interference removal.

Problem:
-There is inconsistency in the use of volume control among applications
---Ex. Pidgin's volume controls are buried in preferences (though not
muting).
Opportunity:
-??
---------------------------------
I HAVE REPEATED


So yea, the most important thing I made conclusions about:
-Temp sounds may interfere with multimedia, but not vice versa.
-Multimedia may interfere with other multimedia.
-Temp sounds should not interfere with other temp sounds.
-Temp sounds and multimedia may interfere with audio input.
-A user may currently (and intentionally) prioritize different temp
sounds produced by an application by not muting the sounds of that
application. (reworded a little bit)

Of course, temp sounds concerned with immediate recoverability concerns
(ex. your laptop is about to run out of batteries and you haven't saved
file X) or system damage (ex. overheating) would be the only exception
from the rule of not forcing the user to hear sounds. 

I would be one to say that recoverability in such a scenario should be
implemented per application regardless of user attention, so if the
system is consistent in that manner, the case of alerting someone to
save before they run out of batteries can potentially be thrown out.



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