2010/5/13 Diego Moya
<turingt@xxxxxxxxx>
- An automated UI behavior is one feature that visibly changes the
user interface in ways that can perceived by the user (i.e. the
automation changes elements that are included in the user mental
model). For the sound menu, this means changing the absolute volume
for notifications.
- The automation will change between various states according to some
predefined "business rules" that are not action-reaction with respect
to user actions. You suggested changing the notification volume to be
always slightly higher than the current background stream.
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.
> Sound loudness can also be measured and calculations can be made to set the
> volume of a sound in such a way that it can be heard on top of another one.
> This is the point here.
Exactly! My point is that you can't assume that doing this will always be valid!
- As I understand, you suggest that we don't need a way to control
which states the automation will decide to change the UI.
I'm not sure I understand this sentence. In any case, I'm not suggesting an UI that changes the contents of visual controls automatically. Actually, so far I haven't proposed any visual UI at all.
Except that your design doesn't account for the case where hearing
notifications is not the user goal.
In your user story for Mary, she's
trying to enjoy listening to music and she doesn't want the frequent
sounds from the chat program, window manager or even a nearly dying
battery; these sounds quickly become annoying. She already has her
attention on her focused program, anyway - so why should those sound
alerts have a higher volume? What she needs is "ducking" the alerts
volume until she finishes with this scenario.
(Note, this is just the opposite case from Javier, who actually needs
to not miss any notification).
You'll say, "OK, then expand the design to also include this need by
providing a new specific feature for Mary". And I say, "but you missed
this use case the first time, how will you know you're not also
missing some other needed features?"
I never claimed that automatically picking up the volume for
notifications is a complete design for any purpose. 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.
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.
But let's go back to the point before this derails the whole discussion. I agree that there's a need for temporarily suspending notifications. Cases for that include presentations, watching movies and "dedicated" music listening. This is however a problem that should be handled by the whole notification system. When watching movies or making presentations, for instance, you not only need the sounds out, but the visual notifications as well.
I'm afraid this conversation is becoming too offtopic for the thread,
as we're mainly talking about general design principles. I suggest
either creating a new thread or taking it off-list except for the bits
where we actually comment on the sound panel design.