2010/5/14 Martín Soto: > You're mixing in your own design/implementation assumptions. I'm suggesting > to play notification sounds at a volume that is higher than whatever is > currently playing. However, I never suggested to achieve this by directly > affecting the slider used to control the volume for user notifications or > any other UI element, for that matter.
Never did I. Playing the notification at a higher volume is the new state changed by automation. The high sound volume of volume can be perceived by the user as an automatic state change (even if the sliders are unchanged), IF you have and individual volume control for each application as the original design suggested. > I never claimed that automatically picking up the volume for notifications > is a complete design for any purpose. But you claimed that a full design can be made to support all purposes for a given class of users. Moreover, you suggested that if a user doesn't have all her purposes covered by the design, she shouldn't use it. In my view, those both claims turn the effective size for the set of target users to 0 if followed to their logic consequences. There is no way you can "understand what people really require in order to perform a particular task" to a perfect degree, not even by restricting the number of users studied. This is why I argue for keeping safeguards, to create a design that can support errors in the design. > Indeed, you don't have to come this far to show that I can miss an important > aspect of a design: I concede that directly. This is the reason why I'm > trying to discuss these issues openly here, so that any weaknesses in my and > other people's ideas can be identified and fixed through discussion and > constructive criticism before they are turned into a piece of software that > doesn't work. That's what I'm trying to do, by suggesting a way by which missing aspects can be addressed other than by an upfront design by committee. You seem confident that *any* weakness can be discovered during the design process. The idea here is that *even this open discussion could miss important aspects of the design*, so we should design against this possible (may I say likely) failure. > In particular, I didn't claim it to be > a complete solution for the whole set of use cases I compiled. It should be > no surprise that this idea alone is not sufficient to handle them all, and I > think it's not fair from you to put it out of context just for the sake of > making your point. Sorry if I sounded harsh or unintentionally took your words out of context. I was using the notification volume as an example to illustrate my abstract reasoning, my argument didn't depend on it nor assumed that this case was your full proposed design. The crux of it is, I still think your assumption that a *perfect* design can be created just by careful user observation and testing is flawed. > Agreed. How about looking at the concrete problems we have, and trying to see > which design approach seems > better for them? With respect to the sound panel: I submitted a mockup to the list based on my "override the wrong automations" idea (the same one posted as Solution #6 in http://brainstorm.ubuntu.com/idea/24627/ ). This design is compatible with your suggestion to give a louder sound to notifications. In the case where "louder notifications" is not the desired state, the user can override that with a single selection. Same with any other states that you'd want automate (muted applications, different relative volumes), the user will always be able to open this menu and change what the automation decided on a per-sound-source level. This design doesn't depend on creating special goal-oriented modes for presentations, movies, games or music. It works in the same way for these cases, and as far as I can see, for mostly all the user stories you submitted. Why do you opposed so strongly this "lightweight override" idea, and does your objection hold for my mockup? Is there some fundamental flaw in this design that I can't see? How would you solve the same needs in a different way? _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
