unity-design team mailing list archive

[Diego Moya <turingt@xxxxxxxxx>]

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?