2010/5/13 Martín Soto:
> Or you implement the automation properly so that it reliably delivers the right result.
The "right" result as defined by who? The designer or the user?
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 my country.
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 advance
to keep the unbroken cold chain, how is the fridge supposed to
automatically know that in advance? (Hint: my freezer also has a
manual Extra-Freeze button that overrides the thermostat wheel and
keeps constant cooling for a day).
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 safety switch") for all complex functions that try
to automate user goals
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 to be overridden (they have a precise
definition, and either they're correct or there's a bug).
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 detection in my fuzzy Japanese washing
machine, I don't want to manually override. But then, there is a "my
clothes are extra-dirty" button too.]
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, everything else is impossible. If you want to
do something I didn't think of, then look for some other product "?
;-)
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 manual overrides in the features that
made the cut. Even if you could predict all possible situations in
your given scope, that won't prevent you from defining the wrong scope
in some subtle way that will only be apparent when your users are
manipulating the software.
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's best for you" (for a narrow definition of
"you"). You can still design flexible products that degrade gracefully
for users outside their predicted scope.