| nettime's_flashometer_IV on Wed, 1 May 2002 06:57:21 +0200 (CEST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| <nettime> ++ Re: GENERATION FLASH [Kanarinka 2x, Klima 3x, napier, askrom] |
Table of Contents:
RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
"Kanarinka" <[email protected]>
Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
John Klima <[email protected]>
RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
"Kanarinka" <[email protected]>
Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
John Klima <[email protected]>
RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
napier <[email protected]>
RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
"Christopher Fahey [askrom]" <[email protected]>
Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
John Klima <[email protected]>
------------------------------
Date: Tue, 30 Apr 2002 13:11:44 -0400
From: "Kanarinka" <[email protected]>
Subject: RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
I agree that the "which end user" issue cannot be solved unless you are
doing extensive demographic research on your artwork (yuk). Even then,
people designing software systems can never fully know the expectations
and actions of their end users. (I'm sure Microsoft has done lots of
usability testing but I still find it incredibly *&^*&ing annoying to
deal with images in Word docs)
My point earlier was that usability and interaction are different things
entirely. Usability is administrative and necessary, interaction design
is creative and necessary.
I think "form" in software/net design includes and is defined by the
structure of the interaction which is in turn defined by focusing on
why/how the user is going to approach, play, deal with, experience the
software in the first place.
Form, in any given medium, stems from the formal properties of that
medium. In 2D mediums you speak of form in terms of color, composition,
texture, etc.
The most distinguishing formal property of software from other mediums
is that it allows for interaction, that it is rule-based, that it allows
the creation of a participatory, experiential environment, however you
wanna say it.
So form in software can also apply to the composition of the visuals on
the screen and to the structure of any audio, etc., included in the
piece, but in a software-driven artwork I would argue that the primary
formal areas that one has to deal with are in the design of the rules
for interaction...
...and really that comes down to thinking about the person at the end of
the line who will be experiencing the work...
- -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of John Klima
Sent: Tuesday, April 30, 2002 12:34 PM
To: Joseph Franklyn McElroy Cor[porat]e [Per]form[ance] Art[ist]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
thinking about the end user has never been a *requirement* of art. and
once you start thinking about the end user you get into all those
difficult areas like "which end user." You start thinking about
usability and not necessarily, form. usability goes farther than "easy"
and "hard." some game interfaces are hard by design. but there is a
purpose there, to create a game.
what then is the purpose of interface within a work of art?
j
<SNIP nettime>
------------------------------
Date: Tue, 30 Apr 2002 14:48:39 -0400
From: John Klima <[email protected]>
Subject: Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
all good points but i just don't want to *have* think about the end
user, and i don't want a work to be assesed in terms of how well it
accomodates them.
j
Kanarinka wrote:
>
> I agree that the "which end user" issue cannot be solved unless you are
> doing extensive demographic research on your artwork (yuk). Even then,
> people designing software systems can never fully know the expectations
> and actions of their end users. (I'm sure Microsoft has done lots of
> usability testing but I still find it incredibly *&^*&ing annoying to
> deal with images in Word docs)
>
<SNIP nettime>
------------------------------
Date: Tue, 30 Apr 2002 14:47:32 -0400
From: "Kanarinka" <[email protected]>
Subject: RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
Why?
- -----Original Message-----
From: John Klima [mailto:[email protected]]
Sent: Tuesday, April 30, 2002 2:49 PM
To: Kanarinka
Cc: 'Joseph Franklyn McElroy Cor[porat]e [Per]form[ance] Art[ist]';
[email protected]; [email protected]; [email protected]
Subject: Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
all good points but i just don't want to *have* think about the end
user, and i don't want a work to be assesed in terms of how well it
accomodates them.
j
<SNIP>
------------------------------
Date: Tue, 30 Apr 2002 16:11:40 -0400
From: John Klima <[email protected]>
Subject: Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
well, where to begin? i'll reiterate the "which user" problem. where do
you set the bar? the blue haired lady or the avid gamer. thats one good
reason not to even try to accomodate the user.
another reason is "standards" already established and ingrained. i met
someone who was angry with me, as the developer, for using a "click and
drag" interface instead of the standard "click and something happens"
interface. they were actually pissed!
its like thinking "maybe i shouldn't make that brushstroke because some
viewers wont like it, other viewers wont see it, and other viewers wont
understand it."
no thanks, you drive yerself crazy worrying about the user.
j
Kanarinka wrote:
>
> Why?
>
<SNIP>
------------------------------
Date: Tue, 30 Apr 2002 16:54:43 -0400
From: napier <[email protected]>
Subject: RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
At 01:11 PM 4/30/2002 -0400, Kanarinka wrote:
>The most distinguishing formal property of software from other mediums
>is that it allows for interaction, that it is rule-based, that it allows
>the creation of a participatory, experiential environment, however you
>wanna say it.
>
>... in a software-driven artwork I would argue that the primary
>formal areas that one has to deal with are in the design of the rules
>for interaction...
At 01:01 PM 4/30/2002 -0400, John Klima wrote:
>so what do we
>discuss? how "well" the interface works? what the user wants to "do?" in
>peasoup and glasbead there is user goal, make a picture, make a song, so
>we presented them with "tools" to do so. they are usable. what would a
>completely abstract interface "do?"
First, I think of p-Soup as a completely abstract interface. The piece is
built on very simple geometry and synthesized notes, so it certainly isn't
representing anything. The user creates a composition and music by
interacting with the piece, but it isn't a tool because there is no end
goal. In p-Soup the end is the interaction itself. The interface is part
of that end, not a tool to create something else (you never save a song ...
when you stop clicking the piece stops playing).
So let's discuss it. From the usability perspective the p-Soup
(http://potatoland.org/p-soup) interface is about as usable as it can
get. Click on an icon at the top, click in the blue box, you see a
ripple. I've never seen a person that can't operate it, and I'm willing to
accept that there may be techno-phobes out there that won't explore the
piece. My audience is anybody with a basic knowledge of the mouse/computer
interface, and these people will be able to activate the piece easily.
Now for the interaction aspect. I agree with Kanarinka that interaction is
separate from usability. In p-Soup I don't explain the piece. If a user
clicks once they get one animated ripple on the screen. Not too
exciting. The piece is only interesting if they click multiple times, and
then the ripples combine and overlap to create secondary shapes. This
usually comes as a surprise to people using it (came as a surprise to me
when I made the piece). So then they start to click quickly, slowly, close
together, far apart. They can focus on the visuals and/or on the sounds.
None of this is about usability. The user has already figured out how to
use the interface. Now we're talking about interaction. This is the "why"
of the piece, where usability is the "how". The user has gotten in to the
piece, now why should they stay. The visual language of the artwork
provides enough material to explore for a while simply out of the fun of
seeing what the shapes do and how they react to each other. There's a
satisfaction for me in seeing a very simple vocabulary combine to create a
surprising variety of qualities (sort of like programming). The user gets
to create something within the boundaries of the artwork.
The work provides an immediate response. The user gets that they just did
something. But then the artwork does something of its own as well, that is
not predictable. There is an element of expectation, fulfillment of the
expectation, but then an element of surprise. The user can explore the
subtler qualities of the piece by refining their use of the artwork. So
there is an element of layering; the interaction has depth. There's an
element of duration: the action continues to animate for about a minute or
two. The user can stop and watch to see what they just did and let the
piece run and fade out on its own.
All of this amounts to a dialog between the user and the artwork. But
there is another element to the interactivity of the artwork, which is that
the piece is multi-user. The applet is built on top of a chat client, so
it networks multiple users together in real time. Concurrent users see
what each other are doing. I don't explain this anywhere in the piece,
which could be seen as user-unfriendly. But in terms of interactivity it
creates an interesting possibility in the work. While a user is clicking
away, playing with the artwork, they may see other shapes forming in the
piece, shapes that they did not create. Then they have to figure out for
themselves how those shapes are happening. Are they random? Are they
generated by some algorithm? Or are they created by another user online,
playing with the artwork at the same time. This moment of meeting of two
people in the space of the artwork always comes as a surprise, even to
me. Immediately people try to find a way to respond to the other user, as
if to show that they exist in the work too. When the group of concurrent
users is large enough somebody usually takes over and clicks a hundred
times in one spot, as if to dominate the space or bring order to the noise.
I don't announce the multi-user nature of the piece, and I'm still not sure
if I should. That's an aspect of interactivity. Should the user expect
this feature of the piece, or be surprised by it? I ruled out that people
can talk to each other (using a text chat interface alongside the graphical
window) because I wanted visitors to use the visual language and try to
find a way to "talk" without words.
I'm just throwing out ideas here, about what aspects of this work matter to
me. There are many questions that interaction brings up, even in an
abstract piece. How much noise should be allowed? How many options are
there in the piece? Should the visual language (of a piece like p-soup)
contain many elements or very few. Should all the features of the piece be
visible up front or should some be hidden? Is the piece about creating
something using a plainly visible interface, or about exploring a
deliberately obscured interface.
BTW I think the same way when I look at a site like http://www.turux.org,
that I think would qualify as completely abstract interfaces. The pieces
create expectations and then fulfill some of them, but contradict
others. Sometimes I'm in total control of the piece, sometimes it seems to
do something on it's own that is only partly in response to my actions. I
like that level of depth. It intrigues me and then I want to explore the
piece more, to figure it out, or simply to find what I can get it to do.
In all of these works there is an element of authority. Who is in control
of the piece? Is it the user, the artist, perhaps multiple users. Or some
combination of these three. In the static art object this is not an issue,
except in the very rare case that somebody splatters blood on a painting.
mark
[email protected]
------------------------------
Date: Tue, 30 Apr 2002 17:43:17 -0400
From: "Christopher Fahey [askrom]" <[email protected]>
Subject: RE: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
> thinking about the end user has never been a *requirement* of art. and
> once you start thinking about the end user you get into all those
> difficult areas like "which end user." You start thinking about
> usability and not necessarily, form.
I agree with this as a general principle, but with three big caveats:
(1) USING COMMERCIAL SOFTWARE LANGUAGE: Much of the
interactive/computer-based artworks I've seen use/exploit/appropriate
the language of commercial computer software quite extensively - they
ask you to use a mouse, a keyboard, a monitor, and often even menus,
icons, form fields, browsers, etc. Sometimes they even have SoftwareLike
names. A computer-based artwork with poor usability (and by "usability"
I mean standard software-industry usability: the ability to accomplish
anticipated tasks) often has the effect of appearing to me as just bad
craftsmanship. Rest assured DIY-ers out there, I don't want to give
undue value to craftsmanship, but when a work of art tries to speak the
language of commercial computer software, it is sometimes incumbant on
the artist to use the language well.
(2) SHOOTING SELF IN FOOT: Sometimes an interactive artwork might have a
degree of depth to it or a ton of cool stuff to experience, see,
interact with - but poor usability makes those 'features' inaccessible.
SFMOMA had a notorious brush with this problem last year. I challenge
you to actually find and view any artwork at the
http://010101.sfmoma.org site. The designer's commitment to making
interesting interactive elements failed to allow site visitors to see
the artworks in the site. Again this is a matter of craft, I suppose,
but even the most craftless interactive artwork has tasks and goals that
the artists desires the user to find and experience. Usability can make
the difference between someone seeing your work or missing it
completely.
(3) CHALLENGING THE USER: As Joseph pointed out, "ease of use" is often
deliberately thwarted in computer games. Interactivity as an art form
(and as a new kind of creative human experience) would be terribly
boring if everything were easy or obvious. A game that tells you how
everything works is an insult to the player's intelligence.
There's a famous usability book (quite a good one for professional
information architects like myself, actually) called "Don't Make Me
Think". The premise is that every little detail of the user interface
has the risk of making a user think too much, and that too many of these
add up to a hard-to-use site. For example, a user can understand that a
grey rectangle with bevelled edges is a "button" in under a millisecond,
but simple black bold text on a white background is likely to require a
second or two for the user to figure out, and a photo of a dog with the
word "submit" on his collar might take many seconds to figure out. It's
not insulting to the user's intelligence to craft something that doesn't
make them think while they do dumb tasks that are rather tedious anyway,
like filling out a form to order airplane tickets. While I agree with
the "Don't Make Me Think" rule of thumb in a business context, in an art
or entertainment context it's not necessarily true at all.
Josh Davis said, in one of his many famous tirades against usability
guru Jakob Nielsen, that we shouldn't treat users like idiots. That's a
good rule of thumb in any context.
- -Cf
[christopher eli fahey]
art: http://www.graphpaper.com
sci: http://www.askrom.com
biz: http://www.behaviordesign.com
------------------------------
Date: Tue, 30 Apr 2002 17:50:34 -0400
From: John Klima <[email protected]>
Subject: Re: RHIZOME_RAW: GENERATION FLASH: Usability/Interaction
sorry for the typo mark, p-Soup it is.
i have to respectfully disagree, i don't think p-Soup is an abstract
interface (i like p-Soup and don't get me wrong). i'm not saying that
it *is* a tool, but it has "icons" you click on that are "brushes" that
make "shapes" where you want them, on a "canvas". it is not that
different in design and paradigm than a paint program. of course its
purpose is very different and its sensiblities highly refined, but is it
abstract? or closer to the point, is it an interface that we are
unfamiliar with? not really. the ripple when you click works the same as
tossing a rock into a pond. this is a primal, understandable metaphor.
replace yer icons with rocks, yer sounds with water noises, and it
ain't abstract. its a pond. i'm focusing on the function of interface
here, not on how the thing looks. it looks great and i wouldn't suggest
you swap graphics to make it a pond. but if you did swap, it would be.
the function of the interface remains the same. so is the interface
abstract because it doesn't have rocks and water sounds?
perhaps i'm just splitting hairs, but when i try to think of an abstract
interface, or just try to focus on the "form of function" it seems to me
that the prize is the creation of something altogether unfamiliar. this
is of course, an incredibly difficult task. most interfaces have been
designed to mimic something in the real world, from a desktop, to a
document, to a file cabinet, to paint, brush, and canvas. an abstract
interface needs to have no reference to the real world, and have no
reference to existing interfaces modeled on the real world.
j
napier wrote:
>
> At 01:11 PM 4/30/2002 -0400, Kanarinka wrote:
> >The most distinguishing formal property of software from other mediums
> >is that it allows for interaction, that it is rule-based, that it allows
> >the creation of a participatory, experiential environment, however you
> >wanna say it.
<SNIP>
# distributed via <nettime>: no commercial use without permission
# <nettime> is a moderated mailing list for net criticism,
# collaborative text filtering and cultural politics of the nets
# more info: [email protected] and "info nettime-l" in the msg body
# archive: http://www.nettime.org contact: [email protected]