unity-design team mailing list archive

[Walter Wittel <wittelw@xxxxxxxxx>]

Wouldn't reducing the volume of the other streams in x db below the
notification be much easier to implement and achieve the goal of hearinf the
notification? X could be different based on the urgency of the notification.

On May 13, 2010 7:00 AM, "Martín Soto" <donsoto@xxxxxxxxx> wrote:

2010/5/13 Diego Moya <turingt@xxxxxxxxx>

> > 2010/5/13 Martín Soto: > > Or you implement the automation properly so
that it reliably delivers...

By the designer, of course. It is his task to determine how the product
should behave.

> My fridge has a thermostat control to set the desired temperature and it's
from the best brand in ...

This is obviously not what I'm talking about. A temperature setting knob is
sensible. A button that overrides the thermostat and lets you start and stop
the freezing compressor by hand, isn't.


> > If I'm going to buy a lot of > food this afternoon and I need the fridge
to be extra-cool in ad...

It overrides the temperature *wheel* by temporarily setting the desired
temperature to the minimum available. It's doesn't deactivate the thermostat
letting you turn the compressor on and off at will. Automation is still
working, even when you press that wonderbutton.


> > I agree with the "all over the place" part, but IMO you MUST have an >
override (a "manual safe...

The keyword here is "user goal". To go back to the actual topic of this
(sub)thread, we are speaking about automating the volume setting for the
notification sounds, nothing else, nothing more. I contend that setting this
volume is not a user goal. On the other hand, being able to hear the
notifications appears to be much closer to whatever the user goal is. This
way, automating the actual volume setting so that the notifications can
always be heard seems like a proper design goal.


> > Of course calculations for physical processes [a thermostat to keep a >
temperature] don't need...

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.


> > [OK, there are some automations that don't need to be exposed >
directly. The water dirtiness d...

The number of hidden automations in our daily lives boggles the mind! If
they all had an override mechanism, our world would be full with red buttons
behind Plexiglas covers. I'm glad this isn't the case, by the way.

> So you're suggesting the proper design is, "I've thought of everything >
you can do in advance, e...

Now we´re starting to understand each other! Although you're expressing it
in a weaselly sort of way, this is indeed the main idea. I'd rather put it
like: "I'll do my best to identify your needs in a particular, narrow area,
and come up with a product that addresses them properly. Afterwards, you're
free to decide if you want to use it or not." This is not about imposing
anything on anyone, it's about designers taking responsibility for their
products. As counterintuitive as it may be, understanding and addressing
user's needs is the designer's task, not the user's task.

> Picking a narrower scope makes your design more manageable, but it >
doesn't address the need for ...

In this case, you look at people using your software (or a prototype of it)
identify the problem, and fix the design accordingly. And if they really
have special needs, they should use special software. No need for override
buttons here.


> > So no, even though I'm a big fan of user-centered design I don't buy >
the "I know exactly what...

Interestingly enough, user-centered design is a lot about "I know exactly
what's best for you", although not in the arrogant way you're trying to make
it sound. It's about working hard to understand what people really require
in order to perform a particular task (this is often not what they think
they require!) and about providing exactly that to them.

In this sense, the idea of a product that "degrades gracefully for users
outside the predicted scope" is sort of contradictory. In order for the
product to behave gracefully, you must understand how it's going to be used,
but if the use lies outside your intended scope, how are you supposed to
understand it? Thus, "degrading gracefully" actually means expanding your
scope to cover a larger set of use cases, which can easily take you to the
point where you're not able to address any of those cases properly with a
single, manageable design.

Martín

_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp