> On 13/12/2008, Jacob Beauregard <deadowlsurvi...@gmail.com> wrote: > > > Volume has too many personal and environmental influences to create an > > interface simpler than letting the user directly control the volume. I > > believe I've already listed off quite a few of them. > > > Yeah, but the trick is in how we define the "control" needed. Just because > it has always done through a slider doesn't mean it has to be that way, in > every situation. When the user don't care about a precise volume but just a > relative setting, a different interface could provide better control with > less effort. > > > I have a design proposal for a really simple interface that would address > many of the scenarios described in this thread and provide direct control > with just a few clicks. I expose it here for your evaluation. > > The interface idea is based around the "sound focus" concept that I > explained in a previous message in this thread: applications with the focus > will play louder than those without it, thus creating a two-level relative > priority set. > > * The basic interface is an enhanced gnome-panel volume control. I've > created a mockup: > http://www.flickr.com/photos/33364...@n04/3108031818/ > > This replaces the old, too small volume control with an slider (always > visible) that allows for direct volume control with one click - important > for users without mouse wheel, using a laptop trackpad, a tablet touchscreen > or an accessibility pointing device. > > You'll notice that it also includes a "pin" button, which is intended to > control the "sound focus". > By default, a "focus follows mouse" mode is enabled - every time an > application window gets the system focus, it will also take the sound > priority and play at full system volume, as set at the panel slider. Volume > for all other applications is reduced, giving priority to whatever the user > is doing at the moment. > It looks functional but confusing. Most confusing part is that the slider contrasts very little with the background. There are multiple icons in addition to the control --They all describe different states of the same thing (adding to confusion) The pin doesn't fit the situational context
The entire focus concept -only generalizes in the context of multitasking with multimedia, if that --(e.g. browsing youtube while playing music) --generally would not follow the mouse, but perhaps the introduction of audio streams -is lowering sound level better than pausing a stream? -should focus start/stop when streams from other applications output little to no sound? Sounds interesting, but would need to be far better defined before its feasibility can be determined. Congratulations: only creative idea that I interpret to have potential (I consider my ideas obvious, rather than creative) > * For the multimedia scenarios, where a background application must still > play at full volume, the "pin" allows the user to permanently set focus to > the media player: > > http://www.flickr.com/photos/33364...@n04/3108031820/ > > In this mockup you can see that Totem has bin pinned. This way, music will > play at full volume even when the user switches to work in other > applications. Both Totem and the current app will play at the volume defined > by the slider, all others will be diminished by a sensible amount. > > The interaction needed to assign focus is as simple as "focus interface on > the application window, click on the pin icon - (click again to remove > focus)". > > > * This concept does scale in an easy way, allowing user to pin-up as many > applications as they wish. All pinned applications show in a menu that > appears on mouse hovering: > > http://www.flickr.com/photos/33364...@n04/3107304015/ > > Including some special categories for system sounds, the user can even > create their own desired scenarios deciding whether warnings are or not > important to any given situation. > > > On 13/12/2008, Philip Ganchev <phil.ganc...@gmail.com> wrote: > > 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. > > Not necessarily. I'm wary of saying the word "always" when creating > interaction designs for general population, because you'll probably find an > exception to the rule. If you have created a fixed design for the general > case the user will be helpless when the exception happen. > > In my proposal, for that presentation mode in which only the selected > application is allowed to play sound, a simple "mute all applications not > pinned", similar to the existing "mute all sound" option, would provide the > required functionality - with an important advantage: > - instead of relying on programmers introducing a presentation mode in their > apps, the user can decide which applications will have that mode and when > have to enter it. > - better yet, the user can override some of the programmer decisions, by > pinning up some other application (such as system warnings) and thus > allowing them to sound during the presentation, if that's what the user > wants. > > I think this interface solves the user needs to "never play something too > loud", "have relative sound levels between apps" and "fine tuning of > multimedia streams". All adding one simple widget to the standard interface. > This is what I meant in a previous message when I talked about creating a > simple interface that covers user needs. > > This example is not a closed proposal, just a way to show that it IS > possible to find an interface that is a direct mapping of user goals to > interface controls, as long as we allow ourselves to depart from the > tried-and-tested and venture into "what if..." designs, always with the goal > to satisfy some clear user needs in mind. > > > > 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. > > The guideline is providing complete control, but only for things that really > matter. This way you empower the user without adding unnecessary complexity, > and without falling to the trap of thinking that a fixed "good default" will > work thus further refinement controls can be hidden away. > > > To summarize the benefits of this proposal: > - The user has absolute control as to what sound streams are important at > any given moment. > - Sound prioritization works even without user interaction, through the > "focus follows selection" feature. > - Setting a different priority profile can be as simple as three clicks > (1-select desired volume, 2-switch to desired application, 3-click the pin > icon) > > The main drawback is that it introduces a new concept to sound management. > It might produce some confusion at first, but I think its workings are > easily discoverable through a little : > - in the default mode, sound is diminished as soon as the window loses the > mouse focus. This will introduce the user to the sound prioritization. > - the pin icon is clearly visible and always on screen. A good tooltip or > label could inform the user about its function (something such as "Fix this > application volume", which should be clear after experiencing the changes in > priority) and teach the sound focus concept. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: </archives/usability/attachments/20081214/1e92fb76/attachment.html> > > ------------------------------ > > _______________________________________________ > Usability mailing list > Usability@gnome.org > http://mail.gnome.org/mailman/listinfo/usability > > > End of Usability Digest, Vol 56, Issue 20 > ***************************************** _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
