← Back to team overview

unity-design team mailing list archive

Re: Two suggested designs for the Sound Indicator

 

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.
>

Agreed. How about looking at the concrete problems we have, and trying to
see which design approach seems better for them?

Martín

Follow ups