On Thu, Dec 11, 2008 at 8:16 AM, Diego Moya <turi...@gmail.com> wrote: > Now that we have some more or less clear scenarios, the first design step > should be defining a list user needs, before we think of any possible > controls to cover them. These are the ones I've identified:
I think what you have listed are again use cases (scenarios) which add to the ones I listed earlier. I don't see how they are different than use cases. > * Current application is too loud -> only emergency case, there should be a > quick access to a function that mutes all sound (and a way to limit volume > before deactivating the mute!). > > * Refine volume in a multimedia stream. Only case that really needs fine > control, IMHO. I might be missing something. For both of these, why not just adjust the master volume (or the speaker knob)? > * Make sure that any possible sound is not louder than X decibels (think > "late at night"). Only case where a global setting is really needed. A > slider doesn't guarantee this, by the way - this should work as a global cap > on sound. This is interesting (though a rare use case). It can be a setting in the master volume control. The user should hear her loudest volume setting as she sets it. She won't know how many decibels she needs. But how will the volume be corrected if an app outputs volume that is too loud? Will the system just output the max volume at the same frequency? Or will it scale the app's volume to avoid distorted volume ratios? Or scale the volume based on a moving window (thus distorting the volume ratios somewhat)? > * Make a system sound (warnings, interface feedback) louder or softer than > another kind of sound. Best fit should be a priority based control - but not > necessarily a list of all applications, more like a temporary "muffle this > sound source". Didn't we establish that warnings should always be louder than the application, except for full-screen mode where only critical warnings will be louder? If the default volumes are good, then tweaking these defaults is a rare use case, which would be a great thing. Tweaking should be possible, but since it will be rarely done, the interface should be out of the way. On the other hand, interface feedback (such as when you minimize a window) is never useful, rarely bling, and almost always irritating. > All scenarios described in previous posts (presentation mode, mixing several > streams…) are particular instances or combinations of these needs. Presentation mode was a solution to the use case. Mixing is done by a sound mixing application, no? > We should aim to provide an interface that satisfy these user goals in an > easy way, so that the user has complete control over the things that really > matter. This way she can tweak them at her will in ways that none of us > could think of in advance. Sure. But thinking about complete control first often leads to a UI that is unnecessarily (or bewilderingly) complex. The controls should be out of the way for the vast majority of users who will not need compete control if the defaults are good. Thinking of complete control can also lead to designs that require user interaction: seting preferences, experimenting to find the right preferences, etc. We should think about how to minimize interaction for as many cases as possible; and only for rare cases when we can't, try to give easy complete control. _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
