Behaviour undone -- The fatal inversion in IxDs definition (was RE: PID: Personal Interface Definitions)

12 Sep 2004 - 11:39pm
10 years ago
6 replies
720 reads
Nick Ragouzis
2004

Okay, I've snipped stuff, but you've really got to have
these two paras together to relish the dish:

Dave Heller wrote:
> Jef Raskin wrote:
> > Monotony can arise in two ways: if there is one gesture
> > for a given action, the system is monotonous for that
> > action. If there are multiple ways of performing an action,
> > but each is used in a different context by a user, then
> > the system has been monotonized by the user. The important
> > thing is that given a particular stimulus (which can be a
> > complex of various elements) if the user has a particular
> > response that he or she always uses in response, then the
> > system is monotonous, and habituation is a consequence.
> > This is the case where what is seen as the same action by
> > the system designer is not seen as such by the user.
> > You do not have monotony when, given the same circumstance,
> > the user sometimes chooses one method, and sometimes another.
>
> I must admit I found the above a bit confusing. For the most
> part I think I am in agreement with you. I'm not sure how
> specific you mean by "same circumstances"? Circumstances are
> never identitical at any given moment, so I'm not sure that
> is every achievable. Let's go back to my example w/ the
> "back" command in a web browser. I do this 4 different ways;
> the button, the <alt>+<arrow>, the button on my mouse, and
> the context menu. I do not think that the circumstances are
> the same in each instance of use, but at what level of
> predictable variability is it ok to have each of these methods
> available. I'm asking a particular question. When should a
> designer say, "Oh! This makes sense to be redundant" vs.
> "This is redundant and a waste"?

Rarely does one receive a gift in one wrapping such as
these two paragraphs, if, that is, you're into delicious
irony. (See also [3], below.)

On one hand we have an individual describing behavior
as a human attribute.[1] Barring one weakness, it's a
pretty precise instance of its kind.

And on the other hand, we have a description of behavior
as an attribute of a system.[2] Barring one concession
to confusion, it too is representative of its kind.

In this forum, and in the IxD mission (even the précis),
we have a harvest of confusion in consequence of
advancing the latter framing. It is backwards, and
inside-out.

Which fittingly leads to the delicious irony that one
thinking from that latter (IxD) perspective cannot "see
through the mirror" to the perspective of the other side.

Further, to lard the bacon, it's the former framing that's
potent for contributing unique value from a profession
called interaction design, and for delivering usable value
to users and our sponsors.

The latter (IxD) framing sets up confusion in both the work
and the structure of the discipline ... witness in the most
recent incarnation of the "What's an IxDer" thread the
scurrying for other folk's business in which to meddle
(general business consulting, to name one).

As a key, if you're wondering:

[1] From this perspective it's the identity in the
human perception that makes all presented variations
within a particular "complex" the same.

To extend: If the result is monotony then one -might-
say the designer sought that result; if the result is
not monotony then one -says- the designer failed to
achieve that result, whether or not the designer was
aware of or attempted to design the system's functions
for monotony.

This, btw, is one/THE reason why designers pursuing
monotony (as opposed to, say, marketeers) have a
dedicated and focused fascination with unexpected
uses of their products where monotony 'broke down'.

[2] From this (IxD) perspective it's the variety in the
system's presentations that makes all variations
presented within the "complex" different.

. . . . .

[3] Oh, it's not the first appearance of this ironic
juxtaposition in a thread, though. Just never so neatly
bound in one email in two paras.

Here's a set that together offer another instance relative
to the definition of the interaction design field.
* Gerard Torenvliet's of Tue 07/20/2004 10:19 AM
(but especially b/c it offers advancing evidence from
both forward and reverse perspectives, and at least
two of each)
* Todd Warfield's of Tue 07/20/2004 06:33 PM
* Whitney Quesenbery's of Wed 07/21/2004 06:28 AM

A close reading of these *should* give you that queasy
through-the-looking-glass feeling of flatworlders
defending their view reinterpreting the abundant
evidence all around to the contrary. Here concerning
that fettish we might call "widget animism".

To get past the roots of confusion like we have at the
outset, and to find the core of IxD's opportunity ... the
problems, their elaboration ... and then to offer a unique
bit to the world, will require "unthinking" interaction
design as we've let it, unproductively, go into
hypertrophic mutation.

We'll have to let go of some of our past, some of the
self-aggrandizing envisioned future, even some parts of
the domain we (unproductively) clutch so closely to
ourselves. To avoid becoming yet another general,
integrating, design discipline without sensible and
clear grounding it may even require an innovation to how
we pursue that objective.

One unique bit, plus a bouquet of questions are much more
powerful at this point.

And once we have that unique bit, that *others* recognize
as valuable and interesting, then the road forward (and
an appropriate defining manifesto) will be appropriately
clearer.

I offer this as one good place to start:

"Behaviors are for people, not widgets*."

Not interfaces, not computers, not software ... people.
Now recast the entire IxD (and interaction design)
enterprise.

Best,
--Nick

Comments

13 Sep 2004 - 1:05am
Andrei Herasimchuk
2004

On Sep 12, 2004, at 9:39 PM, Nick Ragouzis wrote:

> And once we have that unique bit, that *others* recognize
> as valuable and interesting, then the road forward (and
> an appropriate defining manifesto) will be appropriately
> clearer.

Not to sound snide or sarcastic... but... Mind restating that email in
language that mere mortals can understand? Obviously, I lack the proper
smarts. I have no freaking clue what you just said.

Andrei

13 Sep 2004 - 11:39am
Jef Raskin
2004

To understand this fully, I recommend reading Sokal and Bricmont,
"Fashionable Nonsense". Meanwhile, it's back to writing code.

On Sep 12, 2004, at 9:39 PM, Nick Ragouzis wrote:

> We'll have to let go of some of our past, some of the
> self-aggrandizing envisioned future, even some parts of
> the domain we (unproductively) clutch so closely to
> ourselves. To avoid becoming yet another general,
> integrating, design discipline without sensible and
> clear grounding it may even require an innovation to how
> we pursue that objective

13 Sep 2004 - 12:02pm
Dave Malouf
2005

> Nick is saying (I think) that system behaviors and models
> should reflect human behaviors and mental models, rather than
> vice versa, a sentiment I agree with entirely (as I imagine
> many people on the list do).

"reflect" is an interesting word choice. It implies a "mirror" which implies
that if a human behavior is to do X, then the system/product behavior should
be X.

I would maybe edit that (maybe this is a bit of word smithing) and switch
the world "reflect" for the word "compliment" ... Both the system and the
humans have behaviors and an ideal system is one where the system behaviors
compliment human ones.

I think where Robert would also agree is that this compliment can only come
from understanding the context of use around motivations, goals and task
flows.

The other great reason that I like "compliment" is b/c it gives room for
innovation in a way where "reflect" doesn't. As current human behavior may
change in the presence of good innovative complimentary system behaviors. So
our user research needs to be deeper than understanding current mental
models and behaviors, and more to the point of understanding the motivations
and goals of the behaviors at a higher level so that we can adjust current
behaviors through innovations where possible. Of course there is a balance
here b/c behaviors won't change easily and we also need to reflect the
roadblocks to change so we can compliment where innovation is not allowed
(at least not in such large jumps).

Later on, Robert sugests that these should be "humane". Also true ... But
what does "humane" mean. The word itself implies that there are a set of
rights, as the word "humane" implies the opposite is true if it is not,
which is "inhumane" or oppressive. It would be interesting to put together a
"bill of rights" of IxD.

-- dave

13 Sep 2004 - 1:29pm
Dave Collins
2004

< :-) >
Although, if software did "compliment" humans, that would *also* qualify
as considerate!
</ :-) >

> > I think where Robert would also agree is that this compliment
[complement] can only come from
>> understanding the context of use around motivations, goals and task
flows.

> Another word for "humane" is "considerate". Chapter 14 of _About Face
2.0_

13 Sep 2004 - 3:44pm
Jef Raskin
2004

The two words are different, though with a lot in common.

On Sep 13, 2004, at 11:29 AM, Dave Collins wrote:

>> Another word for "humane" is "considerate". Chapter 14 of _About Face
> 2.0_

15 Sep 2004 - 11:12am
Nick Ragouzis
2004

[ Apologies to the list. I'm mostly unavailable
until mid-week next week. Normally I wouldn't have
put this out there with such prospects. But facing
that perfect conjunction I couldn't resist.]

My first thoughts in response, though, are this:

The magnitude of the error in invoking the
"behavior" metaphor, on both sides of this
system is so large, and so fundamental, that
it is merely round-off difference to say that
chocolate cake has behavior. (And I choose
that metaphor carefully.)

Using behavior as analogy (as suggested), going
beyond metaphor to the implication that an
identity on some level grants latitude in
assuming meaningful similarity at another ...
well this is for interaction design, and IxD,
an even more blinding error.

It's a compelling one ... granted ... but not
knowing the difference has cast interaction design
as a kind of industrial-design-with-personality-
cum-organizational-design.

It's also wrong, IMO, to think of the
anthropomorphizing phenomenon as a -direct-
design index and license to/in the concrete systems
domain. This phenomenon (it is only that) moves
us in the other direction, to its root on the
human size of the interface.

To echo Jef's comment about modelessness, once
you've focused on behavior as an attribute
uniquely on the human side of the interface,
only then can you integrate the result and draw
conclusions about the license for the subject
systems.

(IMO the use of "complementary" here, in place
of "subject" is probably not helpful. It is
easy to fall into, and one can observe the
resulting human-systems paring as such, but at
design time this probably contributes as much
to incorrect concretizing as does the behavior
metaphor itself. These systems are not aligned
in the way it suggests ... because in properly
designed systems there are vast non-complementary
aspects when considering any one type of
human-systems paring. One can go further in
locating this distinction, even to specific
transactions. Sure, there's an exchange, but
it's amazing how non-complementary is the
mapping, and how potent is the chasm.)

The surprising thing, in my experience, is that
at that point, to address the interaction design
issues, you need *much less* breadth in the
solution domain (more properly, much more depth
in dramatically fewer domains). And that this
produces much more stable and leveragable solutions.
In fact, I rather think it a signal of a potential
problem when a solution to something presented as
an interaction design issue can 'only' be solved
by dramatic scope expansion.

Well here I'm starting to get off into the weeds
when I should be addressing Gerard, Andrei, and
Robert's comments. I'll do that later, with your
patience.

Best,
--Nick

Syndicate content Get the feed