Context Breeder Mid-Project Report

Posted by John Klima | Sun Jun 16th 2002 1 a.m.

heya all,

The Rhizome alt.interface mid-project report is online at
http://www.rhizome.org/Context_Breeder with a link to the app as it
exists. The report is also included below for your convenience.

the original project proposal and description is at
http://www.cityarts.com/rhizome if yer not familiar with it.

the current application url is:
http://www.rhizome.org/Context_Breeder/userface.htm

Give it a try, see if you can figure out the interface, pound on it and
create new genes. You create a gene by selecting four artbase objects.
users will eventual have the ability to accept an existing default gene
with no muss or fuss, and be able to find genes they previously created.
The creation interface is the most complex, so I managed it first. slide
the blue dot for big change, red dot for small, click around on things,
lemme know. will eventually add pop-up help, and loading status bars,
give it a few moments to load.

off to mexico with my honey for a few days, cya later in the week.

best,
j

Context Breeder
Mid-Project Report
15 June 2002

The Context Breeder project is well along in its development cycle. By
using server-side php scripts to accept and return data with a Java 1
front end, the data backbone for Context Breeder is fully established.
Work on the front end continues, with significant milestones
accomplished including cross platform browser-based 3d rendering, and a
gene creation interface that populates the rendering with new genes
(give it a try http://www.rhizome.org/Context_Breeder/userface.htm).

The 3d gene pool rendering displays sequences of four gif images,
representing four Artbase objects. Context Breeder has two such 3d
renderings that will be finalized as a single interface. The first
displays the sequences as a transparent stack, the second displays them
in orbits. By combining the stacks and orbits, the sequences will be
arranged by their similarity with each other.

The 3d rendering is populated by a java interface that allows the user
to create a sequence of four genes. Complete information about the
artbase objects in the scene will be visible below the 700 x 200 pixel
3d rendering area. This is by no means the finished 3d rendering,
however it fully demonstrates the instant dynamic adding of gene
sequences to the pool, constituting the major functional hurdle for the
project.

Summary:
breakdown of code modules written thus far:
1. php scripts retrieve and add genes to the artbase.
2. a java interface accesses the database through the php scripts.
3. a cross platform 3d rendering displays genes as .gifs in stacks.
4. a cross platform 3d rendering displays genes as .gifs in orbits.
breakdown of tasks ahead:
1. integrate the two 3d renderings based on gene similarity
2. enable travel through the rendering.
3. enable gene crossover and lifespan.
4. beta feedback and debug.
  • Scott Paterson | Mon Jun 17th 2002 1 a.m.
    John,
    This is a really interesting project and I have lots of questions. You seem
    to be taking on the challenge of creating a better visualization scheme for
    associative data by finding alternative metaphors for their organization,
    display and interconnectedness. Much of my criticism and commentary below
    are informed by my experience dealing with Thinkmap and more recently
    teaching interface design.

    I found the whole experience to be not very intuitive. This is not
    necessarily a problem. I know we have had discussions in the past about your
    interest in providing challenging gaming mechanisms and interaction designs.
    While I tend to agree with you on those, I find it important to provide a
    layered experience. Another reason I bring this up, is because the project
    is wavering between being a tool and an interface - it is two screens, the
    first, a user interface(tool) and second window is interface of
    artbase(visualization). I say this because in your explanation of the piece,
    it is clear to me that user participation is important to the project's
    success. Therefore legibility of the interface as a usable tool is important
    while legibility of the interface as visualization can rely on additional
    parameters - like those found in genetics(?).

    Below I will try to identify key aspects of the interface and interaction
    design that I found confusing.

    There seem to be 3 main modes of activity for the gene pool selection
    interface.
    - Scrolling : physical metaphors and measure
    There are two different methods to scroll a list provided to the user - a
    blue dot and a red dot. The fact that they are even scroll bars is
    obfuscated by the lack of typical scroll bar conventions, up/down arrows or
    the physical metaphors of a button in a slot, track or delimited slide zone.
    You provide a box in which the dots reside, but it is unclear how they
    relate to that box in part because the box looks more to be a framing
    element, creating modules, common to the entire interface. Once users catch
    on that the dots are scroll bars, the interface responds well, the feedback
    is as expected. However, it is difficult to understand what proportion the
    red dot scrolls compared to the blue. For example, the blue allows users to
    jump every 20 names vs. the red scrolls within those 20. This is a nice
    feature but I think unusual and therefore needing more visual clarification
    of measurement.

    - Selecting - multiple clicking/highlighting options to designate choice
    It is very subtly implied(reading left to right) that the sequence of
    browsing is blue dot, red dot, click box to position, hit button. I found
    this sequence so subtle as to be invisible due to various other competing
    interactions. The red dot is both scrolling and indicating selection. There
    is a visual connection between the red dot and the placement box rather than
    a connection between the artbase item and the placement box. Having many
    items hot(clickable) makes it easy to get out of sequence. Non-linear
    selection is great, I am all for serendipity but it becomes very important
    for users to be able to track their current state. Therefore, I would
    disconnect the red dot from highlighting a selection and let the user click
    on the item to select it OR keep the connection and have the placement box,
    constantly updating as users scroll and then provide an obvious way to
    select the next placement box.

    - Producing - one big interface
    So, I have tried to make a distinction between what I think are currently
    confusing interface issues and their possible outcomes, one being the more
    typical usability-oriented and the other more serendipitous. My last comment
    about the interface is a general layout one. What if you placed the
    scrolling window at the top and the placement boxes and go button at the
    bottom? I would eliminate the extra readout list currently in the upper
    right corner as that information could easily be incorporated into the
    placement boxes. This adjustment would actually allow you to place the
    second window, "addgene.php" to the bottom of the interface, thereby making
    it one fluid experience. Right now, taking me to a second blank window, I
    forget my choices, and am left to drift through un-annotated field of
    thumbnails. Which ones are the ones I selected? How are the others being
    generated? Why in a circle? Can the user interface foreshadow some of there
    structures?

    All that said, what I find exciting is the possibility for the 3d
    environment to be readily updateable because it is part of the same
    interface. This, for me, would be a great and fluid context breeder. By
    placing the thumbnail visualization back into a selection environment could
    allow you to highlight the existing structures at play in the curation and
    categorization of art works. It would also allow you to address Patrick's
    fine comment about wanting to search by numerous criteria beyond
    alpha-numeric listing. On the other hand, I have been considering the 3d
    environment as the 2nd experience. It is really the primary experience and
    therefore one could consider the user interface as a kind of heads-up
    display therefore making it all one fluid piece. Which makes me wrap-up by
    asking how does all this relate, if at all, to current methods of genetic
    visualization and sequencing? What does an additional dimension(2d to 3d)
    afford you? Ok, I'll stop...I apologize for being so long winded, but I am
    excited to see where you're going to take the project.

    Best regards,
    [sgp]

    ps: I had no technical problems on my PC(w2000) / IE 5

    ----- Original Message -----
    From: "John Klima" <klima@echonyc.com>
    To: <mark@rhizome.org>; <alex@rhizome.org>; <mary@rhizome.org>
    Cc: <list@rhizome.org>; "thing ist" <thingist@BBS.THING.NET>
    Sent: Sunday, June 16, 2002 1:46 AM
    Subject: RHIZOME_RAW: Context Breeder Mid-Project Report

    >
    > heya all,
    >
    > The Rhizome alt.interface mid-project report is online at
    > http://www.rhizome.org/Context_Breeder with a link to the app as it
    > exists. The report is also included below for your convenience.
    >
    > the original project proposal and description is at
    > http://www.cityarts.com/rhizome if yer not familiar with it.
    >
    > the current application url is:
    > http://www.rhizome.org/Context_Breeder/userface.htm
    >
    > Give it a try, see if you can figure out the interface, pound on it and
    > create new genes. You create a gene by selecting four artbase objects.
    > users will eventual have the ability to accept an existing default gene
    > with no muss or fuss, and be able to find genes they previously created.
    > The creation interface is the most complex, so I managed it first. slide
    > the blue dot for big change, red dot for small, click around on things,
    > lemme know. will eventually add pop-up help, and loading status bars,
    > give it a few moments to load.
    >
    > off to mexico with my honey for a few days, cya later in the week.
    >
    > best,
    > j
    >
    > Context Breeder
    > Mid-Project Report
    > 15 June 2002
    >
    > The Context Breeder project is well along in its development cycle. By
    > using server-side php scripts to accept and return data with a Java 1
    > front end, the data backbone for Context Breeder is fully established.
    > Work on the front end continues, with significant milestones
    > accomplished including cross platform browser-based 3d rendering, and a
    > gene creation interface that populates the rendering with new genes
    > (give it a try http://www.rhizome.org/Context_Breeder/userface.htm).
    >
    > The 3d gene pool rendering displays sequences of four gif images,
    > representing four Artbase objects. Context Breeder has two such 3d
    > renderings that will be finalized as a single interface. The first
    > displays the sequences as a transparent stack, the second displays them
    > in orbits. By combining the stacks and orbits, the sequences will be
    > arranged by their similarity with each other.
    >
    > The 3d rendering is populated by a java interface that allows the user
    > to create a sequence of four genes. Complete information about the
    > artbase objects in the scene will be visible below the 700 x 200 pixel
    > 3d rendering area. This is by no means the finished 3d rendering,
    > however it fully demonstrates the instant dynamic adding of gene
    > sequences to the pool, constituting the major functional hurdle for the
    > project.
    >
    > Summary:
    > breakdown of code modules written thus far:
    > 1. php scripts retrieve and add genes to the artbase.
    > 2. a java interface accesses the database through the php scripts.
    > 3. a cross platform 3d rendering displays genes as .gifs in stacks.
    > 4. a cross platform 3d rendering displays genes as .gifs in orbits.
    > breakdown of tasks ahead:
    > 1. integrate the two 3d renderings based on gene similarity
    > 2. enable travel through the rendering.
    > 3. enable gene crossover and lifespan.
    > 4. beta feedback and debug.
    > + dirty.bomb$THpleted.uranium
    > -> Rhizome.org
    > -> post: list@rhizome.org
    > -> questions: info@rhizome.org
    > -> subscribe/unsubscribe: http://rhizome.org/subscribe.rhiz
    > -> give: http://rhizome.org/support
    > +
    > Subscribers to Rhizome are subject to the terms set out in the
    > Membership Agreement available online at http://rhizome.org/info/29.php3
    >
  • John Klima | Wed Jun 19th 2002 1 a.m.
    hi scott & all,

    thanks a ton for your detailed assessment. the first time you look at
    anything of mine its not very intuitive, but in this case it *is* very
    simple. i think a few bits of pop up instruction will go a long way
    (which i fully plan to implement). regarding your more specific points,
    i don't think the first time i looked at any scroll bar, i intuitively
    knew what it did. but once i tried it it became quite obvious. i'd like
    to suggest we are at the point of computing sophistication where ugly
    little up and down arrows can be dispensed with, and seeing a list with
    a gizmo next to it is all it takes to say "scroll"

    the discussions we've had about this topic in general have always lead
    me to believe that no interface is intuitive, only similar to past
    interfaces, or in the worst cases, simply habitual. i also think that a
    good interface does not need to be intuitive, it needs to be easy to
    master, and effective in its operation. that is not necessarily the
    definition of intuitive. i also believe the only way to create new
    interfaces that do more than the existing paradigms, is to simply not
    worry about whether grandma and little billy can use it. i guess thats
    why i'll never be a web designer. but seriously, the only way to make
    more effective interfaces is to demand a bit more of the user. and i
    think this really comes down to habit. we are used to seeing a scroll
    bar that has arrows, thumb boxes, heavy raised boarders, all this crap
    that takes up space and perhaps makes it more confusing for grandma and
    little billy. if it is assumed that everything in an interface has a
    purpose, two dots in a rectangle next to a list seems obvious enough. a
    quick investigation and their purpose is revealed. which is of course
    part of the fun, and this is of course, not an online realtime stock
    trading application.

    to address your comments on selection, i'm still playing with things.
    however, i quite like the sequence of events for selecting the four
    objects. the red line connects to the red dot, which also highlights
    it's neighboring text entry in the list. to add that object, clicking on
    the text entry OR clicking on one of the four boxes adds that entry.
    clicking on a different entry adjusts the list to it, and it appears in
    the selection box. so it becomes quite quick to set all four image boxes
    to the same object, which one might actually want to do, or two of one
    and two of another. i think the mechanism, though perhaps not
    "intuitive" is highly effective for making the selection. a few little
    tweaks and drill-downs and it will super effective. btw the problem with
    *automatically* selecting the highlighted list entry into the image box
    is the network lag it takes to load it, and also the fact that my
    unfiltered database list has lots of entries where there are no images.
    however your points are well taken and i'll likely incorporate some of
    their concerns into the interface. keep in mind though that prolly 90%
    of first time users will opt for a default gene and never use the
    creation interface, so my primary concern will be to make it fast and
    effective to use once you know the (few) oddball mechanisms.

    as far as the 3d rendering is concerned, there is no room for the
    selection mechanism on this page because there will be a whole other
    interface that the rendering is only a part of. if it had consisted of
    only these two interfaces, they would have been on the same page. so in
    the final version, there will be an interface of simmilar look and feel
    to the selection interface, wraped around the 3d rendering. also the 3d
    rendering is in no way the final appearance of the sequences, it right
    now functions only as a proof of function - it can accept user selection
    of artbase objects into a 3d rendering of their thumbnails. also the
    selection screen is not really part of the interface per se. the real
    interface will be inside and around the rendering where connections are
    made between genes, and will be fully annotated. btw, the gene you
    created is the first one that appears in the rendering, and all the
    others spiral out from there. in the final interface, your gene will
    act something like a crosshair in the center of the screen, and the
    other genes will be stacked and orbited in the scene according to their
    similarity with your gene.

    thanks again for your detailed evaluation, it will really help when i'm
    faced with decisions where i'd prefer to say "oh, fuck the user." i
    look forward to your comments in the future.

    best,
    j

    sgp wrote:
    >
    > John,
    > This is a really interesting project and I have lots of questions. You seem
    > to be taking on the challenge of creating a better visualization scheme for
    > associative data by finding alternative metaphors for their organization,
    > display and interconnectedness. Much of my criticism and commentary below
    > are informed by my experience dealing with Thinkmap and more recently
    > teaching interface design.
    >
    > I found the whole experience to be not very intuitive. This is not
    > necessarily a problem. I know we have had discussions in the past about your
    > interest in providing challenging gaming mechanisms and interaction designs.
    > While I tend to agree with you on those, I find it important to provide a
    > layered experience. Another reason I bring this up, is because the project
    > is wavering between being a tool and an interface - it is two screens, the
    > first, a user interface(tool) and second window is interface of
    > artbase(visualization). I say this because in your explanation of the piece,
    > it is clear to me that user participation is important to the project's
    > success. Therefore legibility of the interface as a usable tool is important
    > while legibility of the interface as visualization can rely on additional
    > parameters - like those found in genetics(?).
    >
    > Below I will try to identify key aspects of the interface and interaction
    > design that I found confusing.
    >
    > There seem to be 3 main modes of activity for the gene pool selection
    > interface.
    > - Scrolling : physical metaphors and measure
    > There are two different methods to scroll a list provided to the user - a
    > blue dot and a red dot. The fact that they are even scroll bars is
    > obfuscated by the lack of typical scroll bar conventions, up/down arrows or
    > the physical metaphors of a button in a slot, track or delimited slide zone.
    > You provide a box in which the dots reside, but it is unclear how they
    > relate to that box in part because the box looks more to be a framing
    > element, creating modules, common to the entire interface. Once users catch
    > on that the dots are scroll bars, the interface responds well, the feedback
    > is as expected. However, it is difficult to understand what proportion the
    > red dot scrolls compared to the blue. For example, the blue allows users to
    > jump every 20 names vs. the red scrolls within those 20. This is a nice
    > feature but I think unusual and therefore needing more visual clarification
    > of measurement.
    >
    > - Selecting - multiple clicking/highlighting options to designate choice
    > It is very subtly implied(reading left to right) that the sequence of
    > browsing is blue dot, red dot, click box to position, hit button. I found
    > this sequence so subtle as to be invisible due to various other competing
    > interactions. The red dot is both scrolling and indicating selection. There
    > is a visual connection between the red dot and the placement box rather than
    > a connection between the artbase item and the placement box. Having many
    > items hot(clickable) makes it easy to get out of sequence. Non-linear
    > selection is great, I am all for serendipity but it becomes very important
    > for users to be able to track their current state. Therefore, I would
    > disconnect the red dot from highlighting a selection and let the user click
    > on the item to select it OR keep the connection and have the placement box,
    > constantly updating as users scroll and then provide an obvious way to
    > select the next placement box.
    >
    > - Producing - one big interface
    > So, I have tried to make a distinction between what I think are currently
    > confusing interface issues and their possible outcomes, one being the more
    > typical usability-oriented and the other more serendipitous. My last comment
    > about the interface is a general layout one. What if you placed the
    > scrolling window at the top and the placement boxes and go button at the
    > bottom? I would eliminate the extra readout list currently in the upper
    > right corner as that information could easily be incorporated into the
    > placement boxes. This adjustment would actually allow you to place the
    > second window, "addgene.php" to the bottom of the interface, thereby making
    > it one fluid experience. Right now, taking me to a second blank window, I
    > forget my choices, and am left to drift through un-annotated field of
    > thumbnails. Which ones are the ones I selected? How are the others being
    > generated? Why in a circle? Can the user interface foreshadow some of there
    > structures?
    >
    > All that said, what I find exciting is the possibility for the 3d
    > environment to be readily updateable because it is part of the same
    > interface. This, for me, would be a great and fluid context breeder. By
    > placing the thumbnail visualization back into a selection environment could
    > allow you to highlight the existing structures at play in the curation and
    > categorization of art works. It would also allow you to address Patrick's
    > fine comment about wanting to search by numerous criteria beyond
    > alpha-numeric listing. On the other hand, I have been considering the 3d
    > environment as the 2nd experience. It is really the primary experience and
    > therefore one could consider the user interface as a kind of heads-up
    > display therefore making it all one fluid piece. Which makes me wrap-up by
    > asking how does all this relate, if at all, to current methods of genetic
    > visualization and sequencing? What does an additional dimension(2d to 3d)
    > afford you? Ok, I'll stop...I apologize for being so long winded, but I am
    > excited to see where you're going to take the project.
    >
    > Best regards,
    > [sgp]
    >
    > ps: I had no technical problems on my PC(w2000) / IE 5
    >
    > ----- Original Message -----
    > From: "John Klima" <klima@echonyc.com>
    > To: <mark@rhizome.org>; <alex@rhizome.org>; <mary@rhizome.org>
    > Cc: <list@rhizome.org>; "thing ist" <thingist@BBS.THING.NET>
    > Sent: Sunday, June 16, 2002 1:46 AM
    > Subject: RHIZOME_RAW: Context Breeder Mid-Project Report
    >
    > >
    > > heya all,
    > >
    > > The Rhizome alt.interface mid-project report is online at
    > > http://www.rhizome.org/Context_Breeder with a link to the app as it
    > > exists. The report is also included below for your convenience.
    > >
    > > the original project proposal and description is at
    > > http://www.cityarts.com/rhizome if yer not familiar with it.
    > >
    > > the current application url is:
    > > http://www.rhizome.org/Context_Breeder/userface.htm
    > >
    > > Give it a try, see if you can figure out the interface, pound on it and
    > > create new genes. You create a gene by selecting four artbase objects.
    > > users will eventual have the ability to accept an existing default gene
    > > with no muss or fuss, and be able to find genes they previously created.
    > > The creation interface is the most complex, so I managed it first. slide
    > > the blue dot for big change, red dot for small, click around on things,
    > > lemme know. will eventually add pop-up help, and loading status bars,
    > > give it a few moments to load.
    > >
    > > off to mexico with my honey for a few days, cya later in the week.
    > >
    > > best,
    > > j
    > >
    > > Context Breeder
    > > Mid-Project Report
    > > 15 June 2002
    > >
    > > The Context Breeder project is well along in its development cycle. By
    > > using server-side php scripts to accept and return data with a Java 1
    > > front end, the data backbone for Context Breeder is fully established.
    > > Work on the front end continues, with significant milestones
    > > accomplished including cross platform browser-based 3d rendering, and a
    > > gene creation interface that populates the rendering with new genes
    > > (give it a try http://www.rhizome.org/Context_Breeder/userface.htm).
    > >
    > > The 3d gene pool rendering displays sequences of four gif images,
    > > representing four Artbase objects. Context Breeder has two such 3d
    > > renderings that will be finalized as a single interface. The first
    > > displays the sequences as a transparent stack, the second displays them
    > > in orbits. By combining the stacks and orbits, the sequences will be
    > > arranged by their similarity with each other.
    > >
    > > The 3d rendering is populated by a java interface that allows the user
    > > to create a sequence of four genes. Complete information about the
    > > artbase objects in the scene will be visible below the 700 x 200 pixel
    > > 3d rendering area. This is by no means the finished 3d rendering,
    > > however it fully demonstrates the instant dynamic adding of gene
    > > sequences to the pool, constituting the major functional hurdle for the
    > > project.
    > >
    > > Summary:
    > > breakdown of code modules written thus far:
    > > 1. php scripts retrieve and add genes to the artbase.
    > > 2. a java interface accesses the database through the php scripts.
    > > 3. a cross platform 3d rendering displays genes as .gifs in stacks.
    > > 4. a cross platform 3d rendering displays genes as .gifs in orbits.
    > > breakdown of tasks ahead:
    > > 1. integrate the two 3d renderings based on gene similarity
    > > 2. enable travel through the rendering.
    > > 3. enable gene crossover and lifespan.
    > > 4. beta feedback and debug.
    > > + dirty.bomb$THpleted.uranium
    > > -> Rhizome.org
    > > -> post: list@rhizome.org
    > > -> questions: info@rhizome.org
    > > -> subscribe/unsubscribe: http://rhizome.org/subscribe.rhiz
    > > -> give: http://rhizome.org/support
    > > +
    > > Subscribers to Rhizome are subject to the terms set out in the
    > > Membership Agreement available online at http://rhizome.org/info/29.php3
    > >
  • Scott Paterson | Wed Jun 19th 2002 1 a.m.
    John,
    I'm gonna harp a bit. I think you're argument for sophistication is off
    base. I think it is also, an all too easy excuse to say you don't care about
    your audience ability to understand how to use your piece and consequently
    you are not rigorous about it's own language. I feel this is fair to say for
    this project, at its current state of development. I am not trying to make
    some blanket statement about your work in general. I base my case on two
    interface elements you use in the user selection interface.

    The first one is the scroll bar the second is the input button. You are
    creating an inconsistent interface language by inconsistently employing
    known or normative interface elements. The scroll bar, which you seem to
    want to re-invent or at least abstract, is of an unfamiliar design. This is
    fine. No, its a great challenge. This is to be expected as you have said
    before that we must continue to push forward. But, it breaks down
    immediately when I see the conventional use of the "create gene" button. Is
    this just a stand-in dumby button until you create a new one? As an advanced
    user, I am confronted by a seemingly typical interface: rounded corner
    boxes, lists, an input button, etc. These elements all belong to the current
    state of interface design, imho. But the scroll bar doesn't. Therefore, its
    design needs that much more consideration. I don't think it is ok to say,
    "well let them figure it out, they get it eventually" because maybe they
    will and maybe they won't. (Potential parenthetical coming...) Why do I find
    myself often asking this question about interface art projects? Granted the
    mission is different, why do you not have the same mission critical
    standards of a financial trading app? I am not arguing for a dumbing-down
    either. Good design is good communication. It is just my opinion. But I
    think the scroll bar design as it exists right now doesn't distinguish
    itself enough as an 'actionable' element versus a framing element or content
    element. And I think the only reason I am saying this is because of the
    input button. It is the only other obvious 'actionable' element on the
    screen and it has beveled edges just like every other basic html button.
    Beating a dead horse yet? Great. As you said, it's simple. But I also feel
    because it is so simple, it's ability to quickly become opaque increases.

    Best,
    [sgp]

    From: "John Klima" <klima@ECHONYC.COM>
    > habit, habit. i keep hoping we are at a level of sophistication in our
    > ability to compute, that it is assumed that every element in an
    > interface has a purpose, and that through the brief investigation of an
    > element, its purpose is revealed. or does a scroll bar have to have up
    > and down arrows, fat raised borders, a thumb slide, only one scale, and
    > take up 1/4 of the screen?
  • John Klima | Wed Jun 19th 2002 1 a.m.
    hi scott & all,

    harp away

    sgp wrote:
    >
    > John,
    > I'm gonna harp a bit. I think you're argument for sophistication is off
    > base.

    again, i think pop up instructions are all it needs for comprehension.
    in this case i do care that it is understandable, and the pop-ups will
    solve the problem for folks who don't get it right away. some folks did
    and some folks didn't, about 50/50.

    regarding computational sophistication i'm sure lichty knows i was being
    sarcastic.

    > I think it is also, an all too easy excuse to say you don't care about
    > your audience ability to understand how to use your piece and consequently
    > you are not rigorous about it's own language.

    its also all to easy to rely on a conventional approach as an excuse for
    not creating a new one, though the conventional approach is not the most
    effective, and simply because it asks the least of the user.

    > I feel this is fair to say for
    > this project, at its current state of development. I am not trying to make
    > some blanket statement about your work in general. I base my case on two
    > interface elements you use in the user selection interface.
    >
    > The first one is the scroll bar the second is the input button. You are
    > creating an inconsistent interface language by inconsistently employing
    > known or normative interface elements.

    the "create gene" button is indeed a stand in for the final creation
    process that will include the user naming the gene, among other things.
    i frequently use the normal button convention to directly indicate that
    its a "stand in" in a work in progress, but there's no way you would
    have known that, except, have you ever seen a completed interface of
    mine that had a standard button? raises an interesting issue though -
    every new type of widget has its debut mixed with the other known
    widgets, so i'm not sure that argument fully applies - though sadly new
    widgets usually inherit most of their design from the existing ones (and
    i now see blackhawk chimed in on this point as well, prior to me
    sending).

    > The scroll bar, which you seem to
    > want to re-invent or at least abstract, is of an unfamiliar design. This is
    > fine. No, its a great challenge.

    no, it was a necessity cause the java AWT list widget completely falls
    apart at, i'd guess, 255 entries (where i tested mine to 10k+ elements).
    the artbase has 3k+ entries as it stands right now. with a list that
    large it makes sense to create a course/fine scroll bar, and isolate
    those functions. my original intent was to use the standard gizmos cause
    the creation interface isn't the piece per se, but as soon as i
    discovered the horrid limitations of the standard gizmos, it now is, i
    suppose, very much a part of the piece. therefore, it is no longer
    design, 'cause i aint a designer.

    > Granted the
    > mission is different, why do you not have the same mission critical
    > standards of a financial trading app? I am not arguing for a dumbing-down
    > either. Good design is good communication.

    because firstly, it is not a financial trading app, and secondly, the
    conventions of "good design" are to be challenged when ever the
    opportunity arises, and thirdly. because the project itself is not a
    design project, its an art project. and that is not an excuse, its a
    license.

    > It is just my opinion. But I
    > think the scroll bar design as it exists right now doesn't distinguish
    > itself enough as an 'actionable' element versus a framing element or content
    > element.

    because it diverges from the standardized conventions that we are used
    to. what, the two dots and a line are just decoration? granted the
    button confuses, but it aint the final mechanism.

    best,
    j

    > And I think the only reason I am saying this is because of the
    > input button. It is the only other obvious 'actionable' element on the
    > screen and it has beveled edges just like every other basic html button.
    > Beating a dead horse yet? Great. As you said, it's simple. But I also feel
    > because it is so simple, it's ability to quickly become opaque increases.
    >
    > Best,
    > [sgp]
    >
    > From: "John Klima" <klima@ECHONYC.COM>
    > > habit, habit. i keep hoping we are at a level of sophistication in our
    > > ability to compute, that it is assumed that every element in an
    > > interface has a purpose, and that through the brief investigation of an
    > > element, its purpose is revealed. or does a scroll bar have to have up
    > > and down arrows, fat raised borders, a thumb slide, only one scale, and
    > > take up 1/4 of the screen?
  • Christopher Fahey | Wed Jun 19th 2002 1 a.m.
    While I advocate usability professionally, and while I think that poor
    usability often unwittingly ruins a lot of ambitious net.art work
    (http://010101.sfmoma.org/), I also think that John's project has a
    formal goal beyond the conceptual algorithm which recombines the Artbase
    "DNA": He is also experimenting with user interface paradigms, and as
    such we should not expect the interface to stick to normal interface
    standards.

    A really great book on web site usability is titled "Don't make me
    think", and in my day job as an information architect and interaction
    designer I think this is a great rule of thumb. But in an art context, I
    think the opposite can be quite true: "Make me think!" is the name of
    the game. Josh Davis once said that we shouldn't make interfaces that
    assume the user is stupid. I agree.

    That said, I think most net.artists, including John, need to keep in
    mind the usability of their work. Just because it's art doesn't
    necessarily mean that the artists has carte blanche with the GUI. If
    subverting the interface is the point, then go ahead and rock it Jodi
    style and make every button and widget a total mystery. If building
    compelling, elegant, and innovative interactive experiences is your goal
    (this well describes John Klima's whole artistic practice, IMHO), then
    usability should be a factor in your equation.

    I reserve judgement on the usability of John's interface, but it seems
    to me at this in-progress stage that it is not so challenging that his
    audience wont figure it out after a little bit of thinking. Also, it
    shows promise as something that might actually be an interesting
    interactive experience when it's done.

    -Cf

    [christopher eli fahey]
    art: http://www.graphpaper.com
    sci: http://www.askrom.com
    biz: http://www.behaviordesign.com
  • John Klima | Wed Jun 19th 2002 1 a.m.
    chris,

    thanks for your input. the usability of the creation interface is an
    issue in as far as it's effectivness to create a sequence. however the
    interface's measure of usability is not dependant on how intuitive, or
    similar to other interfaces, it happens to be.

    and i have to insist that an artist does indeed have carte blanche with
    the gui, it is the only arena that allows for this. its is the payback
    for not having any practical thing to market, at least you can do what
    ever you want. but thats another heavily worked topic.

    while full bore chaos that one often experiences in a jodi piece is
    great, it does not have to be an all or nothing affair. an interface
    does not have to be completely enigmatic or completely comprehensible,
    and in a sense something that is neither is the most interesting, 'cause
    you swear it makes sense but you just don't know why. thats a fun kind
    of mental friction.

    best,
    j

    "Christopher Fahey [askrom]" wrote:
    >
    > While I advocate usability professionally, and while I think that poor
    > usability often unwittingly ruins a lot of ambitious net.art work
    > (http://010101.sfmoma.org/), I also think that John's project has a
    > formal goal beyond the conceptual algorithm which recombines the Artbase
    > "DNA": He is also experimenting with user interface paradigms, and as
    > such we should not expect the interface to stick to normal interface
    > standards.
    >
    > A really great book on web site usability is titled "Don't make me
    > think", and in my day job as an information architect and interaction
    > designer I think this is a great rule of thumb. But in an art context, I
    > think the opposite can be quite true: "Make me think!" is the name of
    > the game. Josh Davis once said that we shouldn't make interfaces that
    > assume the user is stupid. I agree.
    >
    > That said, I think most net.artists, including John, need to keep in
    > mind the usability of their work. Just because it's art doesn't
    > necessarily mean that the artists has carte blanche with the GUI. If
    > subverting the interface is the point, then go ahead and rock it Jodi
    > style and make every button and widget a total mystery. If building
    > compelling, elegant, and innovative interactive experiences is your goal
    > (this well describes John Klima's whole artistic practice, IMHO), then
    > usability should be a factor in your equation.
    >
    > I reserve judgement on the usability of John's interface, but it seems
    > to me at this in-progress stage that it is not so challenging that his
    > audience wont figure it out after a little bit of thinking. Also, it
    > shows promise as something that might actually be an interesting
    > interactive experience when it's done.
    >
    > -Cf
    >
    > [christopher eli fahey]
    > art: http://www.graphpaper.com
    > sci: http://www.askrom.com
    > biz: http://www.behaviordesign.com
  • Max Herman | Wed Jun 19th 2002 1 a.m.
    In a message dated 6/19/2002 9:20:12 PM Central Daylight Time,
    klima@echonyc.com writes:

    > it's

    I think it's i-t-s in this case, but isn't "breeder" a pejorative? I qualify
    all my breeding initiatives with an orgy of pups, like at
    http://www.geocities.com/genius-2000/animalbreeder/index.html.

    Also for G2K fans, the counter at www.geocities.com/genius-2000 is up to
    1964; it's fun to go there and see the numbers. For Mexico I recommend the
    Hotel Azores in M. City, it's $7 per nite and near the artaction and plaza
    and all.

    Jameson P. Richards
    genius2000.net

    ++
  • Scott Paterson | Wed Jun 19th 2002 1 a.m.
    P et al,
    I'm sorry but so far I can't help but think like an architect. I'm working
    on it tho. I have often lectured on the differences, which btw are
    fundamentally different as to the creators relation to the work. Architects
    are conduits for others voices. This is an unpopular p.o.v. amongst
    architects. They may inflect that voice, but its origins are rarely theirs.
    Frank Gehry does not write grants to build museums, although he has
    inflected to such a degree and for such a duration that now people hire him
    just to hear,witness, live in his voice. Architects provide clever solutions
    to other's problems or questions. Artists create clever solutions to their
    own problems or questions. Overly simplistic, but it sticks. I don't quite
    follow your distinction between work and function except that you mean work
    to be implemental and function to be instrumental. Is this right?

    Lastly, let's put the scroll thing to rest, please remember that I did
    indeed say that once one figured it out, the interface responded in a way
    that allowed me to ponder it, to play, to think. The double scroll made me
    realize what a long list it was and that this interface allowed me to whip
    it into shape and easily pick 4 pieces. I am excited to see how it develops.

    [sgp]

    ps: Yes, I tried to ride it. Correction, I rode it. Magda witnessed the
    whole embarrassing event. That thing really bucks!!

    From: "Peter von Brandenburg" <blackhawk@thing.net>
    > I u/stood your point & have no issues w/ it per se. However in a larger
    context
    > it seems you're thinking like an architect whereas Cap is thinking like an
    > artist. I clearly see that when the vector is 'ware or any sort of d/app
    there
    > is going to be convergence & even confusion & I don't mean to suggest that
    such
    > work does not have innate architectonic concerns or that an a priori
    > architectural critique is nec inappropriate. Be that as it may, art &
    > architecture are very different in that (if you'll allow me to put it in a
    > dogshit practical way) architecture must *work* -- in vivo -- (tho not nec
    when
    > viewed as part of a larger self-referential corpus), whereas art's
    requirement
    > is rather that it function -- in vitro.
    >
    > You actually tried to ride Cap's Rauschenberg? You're a little big for
    that
    > aren't you? ^_~
  • Christopher Fahey | Thu Jun 20th 2002 1 a.m.
    > while full bore chaos that one often experiences in a jodi piece is
    > great, it does not have to be an all or nothing affair. an interface
    > does not have to be completely enigmatic or completely comprehensible,
    > and in a sense something that is neither is the most
    > interesting, 'cause
    > you swear it makes sense but you just don't know why. thats a fun kind
    > of mental friction.

    I agree completely!

    This is what I meant by implying that it is part of the artist's domain
    to create new forms of interaction. I guess I sorta wanted to make clear
    that even though art with an unpredictable or absurdist interface is
    totally cool, art with sensible interfaces that mimic the banal
    user-friendly interfaces of commercial software is also cool, and that
    oftentimes the latter can be a way to move the focus away from one area
    of artistry to another. In your case, your work is about the user's
    touch, the feel of the interaction, so it is perfectly appropriate that
    you might eschew standard GUI elements.

    -Cf

    [christopher eli fahey]
    art: http://www.graphpaper.com
    sci: http://www.askrom.com
    biz: http://www.behaviordesign.com
  • MTAA | Thu Jun 20th 2002 1 a.m.
    At 18:20 -0400 6/19/02, John Klima wrote:
    >hi scott & all,
    >
    >harp away
    >
    >sgp wrote:
    >>
    >> John,
    >> I'm gonna harp a bit. I think you're argument for sophistication is off
    >> base.
    >
    >again, i think pop up instructions are all it needs for comprehension.
    >in this case i do care that it is understandable, and the pop-ups will
    >solve the problem for folks who don't get it right away. some folks did
    >and some folks didn't, about 50/50.

    just for the record, i got it within 30 secs

    --
    <twhid>
    http://www.mteww.com
    </twhid>
  • John Klima | Thu Jun 20th 2002 1 a.m.
    sgp wrote:
    >
    > P et al,
    > I'm sorry but so far I can't help but think like an architect. I'm working
    > on it tho.

    i hear there's a clinic in arizona you can go to.

    > Lastly, let's put the scroll thing to rest, please remember that I did
    > indeed say that once one figured it out, the interface responded in a way
    > that allowed me to ponder it, to play, to think. The double scroll made me
    > realize what a long list it was and that this interface allowed me to whip
    > it into shape and easily pick 4 pieces. I am excited to see how it develops.

    indeed. i truely appreciate you taking the time to commment on the
    project in detail, and your comments are totally valid, these are issues
    we all struggle with all the time, germane to design as well as art
    projects - naturally more so to the former than the later. at the
    germination of any piece of "interactive" art the first question i ask
    myself is how much do i care about the user. usually that quantity is
    quite high, as christopher suggested in a previous mail. indeed in this
    case again it is quite high. perhaps it is the agency of art to
    introduce unconventional paradigms that design can then put to good use,
    but i think that designers alone could arrive at those useful paradigms
    quicker (simply because of their training), but only if they are trained
    to explore new paradigms in the first place and not trained to rely on
    pre-existing standards that ultimately were invented by programmers, not
    designers or artists, way back when. judson said it earlier, its all a
    translation anyway.

    best,
    j

    >
    > [sgp]
    >
    > ps: Yes, I tried to ride it. Correction, I rode it. Magda witnessed the
    > whole embarrassing event. That thing really bucks!!
    >
    > From: "Peter von Brandenburg" <blackhawk@thing.net>
    > > I u/stood your point & have no issues w/ it per se. However in a larger
    > context
    > > it seems you're thinking like an architect whereas Cap is thinking like an
    > > artist. I clearly see that when the vector is 'ware or any sort of d/app
    > there
    > > is going to be convergence & even confusion & I don't mean to suggest that
    > such
    > > work does not have innate architectonic concerns or that an a priori
    > > architectural critique is nec inappropriate. Be that as it may, art &
    > > architecture are very different in that (if you'll allow me to put it in a
    > > dogshit practical way) architecture must *work* -- in vivo -- (tho not nec
    > when
    > > viewed as part of a larger self-referential corpus), whereas art's
    > requirement
    > > is rather that it function -- in vitro.
    > >
    > > You actually tried to ride Cap's Rauschenberg? You're a little big for
    > that
    > > aren't you? ^_~
    >
    > --------------------------------------------------------------------
    > t h i n g i s t
    > message by "sgp" <somebody@sgp-7.net>
    > archive at http://bbs.thing.net
    > info: send email to majordomo@bbs.thing.net
    > and write "info thingist" in the message body
    > --------------------------------------------------------------------
  • Scott Paterson | Fri Jun 21st 2002 1 a.m.
    P et al,
    First, let me say I don't think these distinctions between art and
    architecture to be very productive. But, to at least clarify terms, I would
    just like to mention that your argument below relies on a rather limited and
    outdated definition of architecture yet your "definition-collar" is loosened
    when discussing art. Bias? Maybe. I think that you are talking about
    building not architecture. There is no agreement about architecture's
    function. There is only possibly a general agreement about buildings as
    shelter. Buildings are one of many possible outcomes for architecture. You
    even seem to acknowledge this in your note to John, mentioning Michael
    Benedikt of Cyberspace: First Steps. So my point is only, let's not play the
    territorial pissing game. I am interested in intersections and
    collaborations: what they can offer and afford eachother...
    Best,
    [sgp]

    From: "Peter von Brandenburg" <blackhawk@thing.net>
    > S+: Architecture cannot fully divorce itself from functionality; if a
    building
    > is erected & the roof falls in then it is a failure. Conversely, if
    (perhaps
    > over time) a work of fine art exhibits properties or qualities opposite
    from
    > those which originally obtained or which the artist intended then in many
    cases
    > this is evidence of expanded functionality. In short, conceptual
    architecture
    > aside, we all know what architecture is supposed to do, there is no such
    > agreement about fine art & to the extent there ever is or has been, the
    focus
    > has changed thru the descent of art practice. Of course art may be
    "functional"
    > in the sense that architecture is (Rural Studio comes to mind), but its
    > functionality is still just *one* element in its aesthetic composition,
    whereas
    > in re architecture it remains the, ahem, foundation. Were functionality
    an a
    > priori requirement of art, it wouldn't be art, it would be illustration or
    > design. best, -- B.
Your Reply