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. _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
