[This interview was completed in the fall 2000 for the online+print
exhibition ON OFF at afsnitp.dk and in the printed magazine Hvedekorn,
both based in Copenhagen, Denmark (http://www.afsnitp.dk/onoff/). Issues
touched upon are: the role of programming in creation and appreciation
of net art, the market value of net art, the (art) history of
programming, the (non)physicality of the net, and the formal and
political dimensions of net art.]

+ + +

Andreas Broegger: I would like to begin by asking your view about net
art in relation to painting, first of all because I know you used to be
a painter as well as a computer programmer, secondly because you often
speak of a certain painterly dimension in your net art projects.

Mark Napier: Art works best when it is interesting both conceptually and
visually. The Shredder is a good example of a project that has both a
conceptual and visual dimension. I spent a lot of time tweaking the
aesthetics of the layers of output text and graphics. I wanted the
shredded page to be variable, somewhat random, but still have a
structure that would create a visual balance and flow.

I enjoy the visual quality of graphics on the computer screen, the
luminosity of colors, the hard edges and the atmospheric blurs that come
out of distorted and pixelated computer graphics. There's a painterly
side to the medium that I want to explore further.

The web interface has capabilities that go beyond painting though. In
net art the artwork can move. It can change and evolve over time, which
creates a whole other dimension to this art form that just doesn't exist
in painting. In Pulse I spent a lot of time looking at how colors can
evolve over time, how the mood and character of a series of colors can
change and take on new qualities. That piece sets up certain color
qualities, color areas that pulse at different rates. Once the visitor
interacts with the piece they activate the color areas and the rest
cannot be predicted exactly. I created a potential for color
relationships, but the visitor actually triggers when and how the colors
will unfold. I don't control the final outcome of the piece.

And that's the fun of software: it can create results that I didn't plan
on.. Software can combine a simple set of rules to create a complex
result, that can go in directions that I can't predict, even though I
made it. To a software developer (my day job) unpredictable behavior
usually means bugs, and gives me headaches, but as an artist I often
prefer the unplanned results. In painting the medium can do things that
I can't predict as well, but once the paint dries, that's it. The image
is static.

AB: To push an analogy between painting and your current work could one
consider <tags> to be equivalent to the painter's brushes, and the
values in the tags as equivalent to the paint? In both cases the object
produced with the two aspects - tags/values and brush/paint respectively -
cannot be deduced from these two generalized aspects in themselves, only
from their specific combination.

MN: In any medium the object produced can't be predicted by looking at
the tools and materials of the medium. This is true of software
languages, as well as paint and canvas, charcoal and paper -- that's
what makes these tools so powerful and so attractive to creative people.
This is also true of language: an alphabet and a grammar can produce
endless combinations of words and sentences.

I don't agree that painting and software code compare so directly
though. The two media are completely different. Paint is a physical
fluid that is directly controlled by hand. Software code is a language
(of sorts) that is controlled through a computer interface. A painting
is a static physical object. Software is more like a machine with moving
parts, or a piece of music.

AB: Do you find these comparisons between net art and "traditional art
forms" meaningful and productive, or does it more often lead to a
reductive view of what net art is?

MN: Comparisons are useful when they serve to create something. Most
often comparisons between net art and traditional media end up saying
that net art is "better" or "worse" than traditional forms. Neither
judgment makes sense.

AB: To what extent do you think the creative dimension of net art
resides (or should reside) in the coding itself?

MN: What I do requires a strong knowledge of code, because I like to
create unusual effects that challenge assumptions about how the web
works. Like "shredding" a page, or merging separate pages (i.e. RIOT).
To do that I have to work around the restrictions the browser imposes,
and that means working closely with code.

Knowing how the code works gives me access to more of what the medium
has to offer. With Java and Javascript I can create visual effects that
the folks at Macromedia never put into Flash and Dreamweaver. For the
kind of art I make, this knowledge is essential. I'm always learning
more about how the technology works.

But there is no one way to be creative, and not all net art necessarily
relies on coding. Conceptual work can make a point just through html.
What concerns me are the curators and critics that are ignorant of
technology, and make decisions about net art without understanding how
the artwork fits into a bigger picture of the technology environment.

AB: You have previously spoken about a certain "secret" aspect in
programming, a part of the code that you would usually like to keep for
yourself, because it holds the key to how you created the piece. Perhaps
you would explain this further?

MN: There are two aspects to producing a software application. There is
the 'code' which may look something like this:

if (ns4 == true) {

this.x = this.css.left

this.y = this.css.top

}

and there is the actual 'binary' or machine language which may look
something like this (if you ever manage to see it on screen, which is
rare):

_"__!2A_J?HoU"se9[2]IOI?W-ZJ(OEb

The code, which humans can read and work with, is translated into
binary, which the machine can execute. This translation is called
compiling, or interpreting the code. If you open a web page in your
browser, then choose the View|Source option from the menu, you can see
the source code for that web page (html and maybe Javascript). In other
systems, such as Flash and Shockwave, you can't see the source code
because the Flash software compiles the code into a binary form. The
author keeps the code on his computer, and puts the binary file onto the
web, where it can be retrieved and executed (with the help of a Flash
plug-in).

In the software industry the code is very valuable since it contains the
knowledge, recipe or blueprint of how the software product is made. The
binary "executable" is distributed to the world, but the source code is
carefully guarded. As an artist I'm happy to share most of my source
code with other artists. Usually they can get to it just by looking at
the html View|Source option on the browser.

When I work in Java, the source code is not immediately available to
viewers of the artwork. In this case the source code becomes a unique
blueprint for the artwork. Whoever owns the source code in effect 'owns'
the artwork.

AB: Do you see the code itself becoming the "artwork" sometime in the
future then, code being sold at art auctions, displayed in museums?

MN: I don't think so, not as a routine event anyway. I'm sure code will
turn up in the collectibles market in some form, but probably more as a
curiosity than as a work of art. Code is like paint and brushes. We
don't revere Picasso's paint brushes, though I'm sure somebody owns a
few, and could sell them for a nice price.

AB: But would you see the possible "marketability" of the code as a
viable alternative to the current situation for net art, which is that
art institutions commission work from net artists, meaning that artists
have to make proposals (and do a lot of work) before possibly being paid
for their art? Or would you still rather favor an "open source"
principle?

MN: I prefer open source, but I have to eat, too. I'm still thinking
about this and don't have any good answers. Since I'm using Java more
now I will have to address this issue (as the source code in Java is
separate from the final compiled product and can be withheld, thus
making the source code rare in the art world sense).

AB: Would you describe the programming as a highly creative dimension in
itself in your own work, or does the creative dimension of your work
rather reside elsewhere: in coming up with an idea for the project, the
"look" of the project, its interaction with users, etc.?

MN: These are all dimensions of the creative process. My projects begin
with an idea, usually an idea about the web, how we use the web or how
it impacts us. But then the coding process creates other possibilities
and adds another dimension to the piece. The technology often limits
what I can do: there are limits to memory, and processing speed, there
are bugs and incompatibilities in the browser software. Other times the
technology reveals possibilities. Accidents happen, mistakes in the
code, that produce unexpected but wonderful qualities. Or I'll find some
software that suggests new ways of working with a problem.

In general, it's not about looking at code as art, but understanding how
the underlying technology affects the art. The invention of oil on
canvas significantly altered the nature of art. That new technology made
art portable. Paintings could be carried from place to place. They could
be large and durable paintings, but still lightweight. Images no longer
had to be painted directly onto walls or altarpieces or pieces of wood.
They could be moved, and so could change owners relatively easily,
opening up the possibility of a secondary market in which art could be
sold and resold. The technology of oil on canvas played a role in
transforming art from large public works to smaller, portable privately
owned pieces, which is how we know art today.

In the case of the internet, there's an even greater need to understand
the medium, since much of a networked artwork may be invisible to the
eye. In projects like Shredder and RIOT the collage you see on screen is
created by appropriating content from the web. I have talked to several
curators who did not understand the relationship of the artwork to the
medium it lives in. They didn't realize where the content of the piece
was coming from, and completely missed the point of these projects. In
Digital Landfill, and GraphicJam, the network is also a driving force
behind the work, and the uninitiated may not realize how these pieces
relate to the surrounding environment, to the space of the network, and
how other users contribute to the work.

These works are about distributed authorship and appropriation. They
exist in the space created by the network, which has different rules and
qualities than what we're used to seeing in the physical space we live
in. But these qualities are not immediately obvious and have to be
learned.

When I started working with computers I had to learn to visualize what
was going on in the machine. Once I learned how to 'see' the environment
of the operating system I had no problem navigating that space. Curators
and critics that look at net art have to go through this process as
well, but they may not realize it. If they look at screen shots, or look
briefly at a monitor, they may be looking at the work as a photograph, a
static image conveniently framed on the monitor. If they don't know how
that image was created, how it relates to the network, to other
visitors, to interaction, then they can't possibly understand the
message of the artwork.

+ + +

Continue to <a href="/object.rhiz?2462">Part 2</a>