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