unity-design team mailing list archive

[Diego Moya <turingt@xxxxxxxxx>]

2010/5/13 Martín Soto:
> 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.

You've never pressed the wrong floor button in an elevator? That's the
kind of overriding I'm referring to, not big "emergency stop red
buttons" everywhere.


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

We're arguing in circles around the definition of the word
"automation". When I say the user must be able to override a complex
automation, I don't mean the automation stops working. These are my
assumptions in what was said above:

- An automated UI behavior is one feature that visibly changes the
user interface in ways that can perceived by the user (i.e. the
automation changes elements that are included in the user mental
model). For the sound menu, this means changing the absolute volume
for notifications.

- The automation will change between various states according to some
predefined "business rules" that are not action-reaction with respect
to user actions. You suggested changing the notification volume to be
always slightly higher than the current background stream.


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

Exactly! My point is that you can't assume that doing this will always be valid!

- As I understand, you suggest that we don't need a way to control
which states the automation will decide to change the UI. The above
business rule (notifications=higher volume) is defined as "the right
behavior".

- I suggest there should always be an obvious way for the user to
decide which of this states to put the system, and prevent the
automation to change it while the "manual override" is active. The
automation may still be active and making its minor tweaks in the
background as expected for the current state; it's just that these
tweaks can't go outside the scope of the user's desired effect. See
Mary's use case below for an example.


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

Except that your design doesn't account for the case where hearing
notifications is not the user goal. In your user story for Mary, she's
trying to enjoy listening to music and she doesn't want the frequent
sounds from the chat program, window manager or even a nearly dying
battery; these sounds quickly become annoying. She already has her
attention on her focused program, anyway - so why should those sound
alerts have a higher volume? What she needs is "ducking" the alerts
volume until she finishes with this scenario.

(Note, this is just the opposite case from Javier, who actually needs
to not miss any notification).

You'll say, "OK, then expand the design to also include this need by
providing a new specific feature for Mary". And I say, "but you missed
this use case the first time, how will you know you're not also
missing some other needed features?"



>> 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."

To which I as a user will say, "no matter how hard you try, you'll
miss some details I couldn't articulate during the research phase, or
you'll miss my cousin's needs because she was not present during the
research, or you'll miss some needs I don't know I have yet because
they'll appear one year from now. So your design won't be perfect
anyway".

I understand your position as you express it, and I think it's not
enough for a good design. See reasons below.


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

You're missing the user need to evolve and tweak the initial design
into a new usage context.



> 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,

Not at all contradictory. That's called "design for flexibility", and
it covers the "degrading gracefully" by admitting there will be some
expansions of scope that you can't predict or perfectly understand,
but still can be handled making some (overridable) educated guesses.

Flexible design is not contradictory with UCD, only with the naive
version of "I can develop a perfect understanding of the whole user
context and create an upfront design to match the 100% of these
needs". When you say "providing exactly that" is when you're adopting
what seems an arrogant posture; that "exact" bit is just not possible
for us fallible humans.

(Of course this is my own humble view of how UCD should be; I'm aware
common usability practice often uses your same arguments about
designers understanding context as the basis for design, and I think
they're mostly right. But when these arguments are pushed too far
against design flexibility is when it triggers this pet peeve of
mine).



I'm afraid this conversation is becoming too offtopic for the thread,
as we're mainly talking about general design principles. I suggest
either creating a new thread or taking it off-list except for the bits
where we actually comment on the sound panel design.