Re: [Ayatana] Two suggested designs for the Sound Indicator

[Diego Moya <turingt@xxxxxxxxx>]

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?


> A fridge with a just-in-case, thermostat-override button would
> speak very poorly about its manufacturer, wouldn't it?

My fridge has a thermostat control to set the desired temperature, and
it's from the best brand in my country. 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).


> Granted, we have often seen products that failed at automating something,
> but this doesn't mean the solution is to implement override buttons all over
> the place.

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 (even if it's not expected to be used in normal
usage and is somewhat hidden), because this kind of complex
automations include a bit of "guessing" what the user intended to do.

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). But the fuzzy
rules that control when a user needs a given function [which
temperature is needed] don't belong in the same class and can't ever
be exactly calculated. There will ALWAYS be some wrongs in guessing
user intent, even with limited scope.

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

A good rule of thumb is that automatic processes with behaviors
leaking into the user mental model should have some level of manual
adjustment.


>
> Getting automation to work is a matter of proper design, implementation and
> testing. I'd rather concentrate on finding out how to do these properly in
> our community, so that we can deliver solutions that don't need to be
> overridden because they operate as expected.

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 "?
;-)


> The alternative is to pick a narrower scope and target it with your
> solution.   People with needs outside that scope will have to use other
> solutions, but such is life.

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.

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.