Francis Hwang online artist, writer, and software engineer. His artwork includes "Ten-sided", in which ten fiction writers use blogs to collaborate on an improvisational narrative, and "The Unauthorized iPod U2 vs. Negativland Special Edition", in which he combined a U2 iPod Special Edition with Negativland's back catalog and auctioned the result online. His writing on technology and culture has appeared in Spin, Wired, ArtByte, and FEED. An active member of the Ruby free software community, he has spoken at the International Ruby Conference and is on the advisory board of Ruby Code & Style. He was Rhizome.org's Director of Technology from 2002 to 2006.

Jeff Martin: Can you tell me about your background and how you became involved in digital art preservation?

Francis Hwang: That's a pretty good question. You could say I've been programming computers on and off for twenty years. I programmed as a hobby when I was in elementary school and junior high, on and off; I had lots of other interests. And then I paid my rent doing computers for about ten years. So I have always had a strong interest in computers, and then the Internet, of course, which honestly made computers a lot more fun than they used to be, because it made everything more social and more visible to non-techies.

At the same time, I had a strong interest in art. My actual degree, my university degree, is a bachelor's in fine arts-in studio arts. I studied painting and drawing, and comic books, which I have ended up focusing on the last year or two. I was also writing and doing art criticism. I did a lot of writing for magazines like Artbyte and FEED.

I moved to New York in 1999. At that time there was a lot of technology writing that needed to be done and a lot of technology arts writing and apparently I was qualified to do that, having worked in both fields. I started working at Rhizome in 2002, worked there about 31/2 years, and left in the beginning of March 2005.

JM: How did you become involved in the preservation of the Internet-based artwork "Brandon"?

FH: Rhizome had been involved in this ongoing consortium of organizations, the Variable Media Initiative.

And my memory of it is that it was mostly initiated by Rick Rinehart at BAMPFA (Berkeley Art Museum, Pacific Film Archive), and the Langlois Foundation was instrumental in founding it, and also the Guggenheim, Caitlin Jones, John Ippolito, and Carol Stringari. Anyway, the point of the organization is basically to start establishing Best Practices for archival and preservation strategies for new-media art, or variable media to be more precise-which includes new-media art, but also things like performance and installation. "Variable media" basically means any kind of work that's going to change significantly over a period of time or place, so it's not a singular fixed object. And so we'd been having these occasional meetings, in addition to doing all the things we do individually as organizations.

"Brandon," which is a work that was commissioned by the Guggenheim in the early 2000s, was also in Rhizome's ArtBase, which is their online archive of Internet art. Rhizome was doing the show ArtBase 101 and "Brandon" was one of the things being exhibited. At the same time, the Guggenheim was planning to give more attention to "Brandon." It had been sort of hibernating for a while, which happens with works. But when we took the work out, we realized that it hadn't survived very well. It had been moved to a different server and no one had spent time looking at it and making sure it was up to date, so a lot of things simply didn't work. Caitlin Jones at the Guggenheim and I were working together. I was doing a lot of the technical stuff in collaboration with the artist. It was a collaborative effort between Rhizome and the Guggenheim.

JM: Can you be more specific about how you determined what the problems with the work were?

FH: One of the operational issues we had is that I hadn't seen "Brandon" when it first came out. Even if I had-sometimes you just see a lot of artworks and you don't have a lot of time to spend with them, or you don't remember them years later. In a normal commercial website you can say, "This image is broken and these links don't go anywhere." But, in fact, broken images and links that don't go anywhere can be part of an artwork. You can have code that breaks as part of the artist's intention.

So one of the first things we had to do was go through and catalog a lot of behaviors. But a lot of little things didn't work. There were JavaScript things that were supposed to scroll up and down and they were maybe moving too fast. There were links that were not popping up the right way. There were pages that were supposed to be generated on the fly by php, and they weren't working. There were a couple of little things that were written in Java-they'd been programmed by someone else-that just didn't work.

This is just a case of software in general. If you don't use software for a while, when you come back, it probably doesn't work. Unless you've managed to [maintain] the entire server top to bottom without changes.

They didn't even have it originally on the same server. I believe it had originally been installed on a Linux machine, and now it lives on an OSX server, and there's a lot of little things that aren't the same, even just like where things are stored on the server, like directory paths.

It turned out that a lot of the php code had been written for a version of php that basically doesn't exist anymore. It was php 3 or so. Something you never see-something I'd never seen in programming the web for seven years. Just because it's very old; this is how technology moves. And nobody would ever get up and say, I have this php application that was written seven years ago, and it's broken, can somebody help me get an old version of php? That's a really unusual request.

So I updated it. Mostly the php wasn't much of a problem; the changes weren't that major. The Java stuff basically just didn't work and we didn't have time to dig through and really resurrect them, because that stuff was inherently more complicated. Not because it's Java, but because of what they were trying to do with it. The original programmer-we weren't able to get in touch with him. And even if we were, it may not have helped, because who remembers codes they wrote seven years ago? So we ended up just closing off those areas of the site so they wouldn't be part of the artwork.

JM: You mentioned needing to catalog a number of different behaviors. Can you elaborate on that?

FH: A website is a bunch of pages that relate to each other in different ways. So you go to the front page, which has a bunch of images, and when you move your mouse over them, the images are supposed to change. You could describe more specific behaviors, like the fact that the images change, but if you keep moving your mouse back and forth over them the image will keep changing to other random things, which come from this collection of image files.

This is a problem with language in the sense that describing interactivity is extremely hard. And it's a problem that new-media art faces, but it's not a problem we face alone because other people have to do it too. A lot of these problems mirror problems you have when you work for a corporate design agency and you do a website. Or some game that cost five million dollars to produce-you better believe someone's trying to figure out how to write down those interactions.

So a lot of our work on "Brandon," was challenging because much of the behavior wasn't written down or it wasn't clear. I had a lot of e-mail conversations with the artist that were strikingly similar to e-mail conversations I might have with design agencies when I work with them; they say, "The graphic on the left-hand side, when you mouse over it, it doesn't work," and we have to go back and forth with me saying, "Which graphic-do you mean the yellow canary or the black cross-hairs?" There isn't a fixed language and because it's such a malleable medium it can take a long time just to get that stuff nailed down-just what is it supposed to do? You're telling me it's broken, I have no idea what that means.

JM: Since you hadn't been able to observe its behavior firsthand, how did you come to figure out just what the work should do?

FH: Well, Caitlin Jones seemed to have a real understanding of the work as a piece overall. And we talked a lot with the artist, who was able to say how it was supposed to act. We were lucky to have the artist around; if something had happened to her, if she had died, or if she was just not friendly to the project of reclaiming the work, then our job would have been a hundred times harder.

JM: Was that the artist's main contribution to the project, guiding you through what it was supposed to do?

FH: Yes, in addition to some technical help, but we did most of the technical implementation.

JM: In a lot of computer-based art, you have works like this that have a single creator but other people who actually work on the project. Is that a relatively common problem in the field of new media and net art?

FH: Yes, it's fairly common. To be clear, it's not exactly a team. Shu Lea Chang is credited as the artist for the work. And she was able to find programmers who wanted to help her out and get paid a little bit of money for their time, but it's a Shu Lea Chang work. And in that sense she has the final say. But it's also the case that-it's really common with a lot of works that the person who has his or her name on it isn't the person who wrote the code.

I don't know what I think of that situation. I think it has a lot of downsides to it, outside of preservation and restoration and these issues. One of the biggest problems with this project was that we couldn't get hold of the programmer. And in cases like this, you're kind of dealing with virtual organizations, it's not like a collective of people that you can pull together and get them to work intensely on the project for a month.

I think it's really been to the detriment of new-media art that we have not been good at nailing down a language for behavior-a language that doesn't rely nearly so much on theory but that is more concrete. We should be stealing this language more aggressively from neighboring disciplines-like information architecture, like video game design-and we've been really bad at it.

I was once on a panel, I remember this distinctly, where we got a bunch of different kinds of new-media proposals from mostly very accomplished artists, people who had met with a certain level of success in the field. But these proposals were so difficult to read. The artists would want to do some sort of interactive installation, and the technical part of the proposals would explain where they wanted the speakers to go. I know you know where to put the speakers; anyone can do that. I want to know what is going to happen when I go into the room, when I move around the room, and this is very difficult to describe.

So, yes, if Shu Lea Chang had programmed "Brandon" herself, it would have been a lot easier to recreate, but that is just how it worked out this time, of course. Now, if something had happened and Shu Lea Chang hadn't been able to help us but we had been able to talk to the programmer, that would have been helpful. I guess it's messy however you do it.

JM: Specifically in terms of migrating this piece forward, what actions did you take to keep the work more viable?

FH: Well, we already had it installed on an OSX server, which is Apple's operating system, which has a desktop version but can also work pretty well as just a server. Someone from the Guggenheim-their I.T. person-gave me access to the machine and said I could do whatever I needed to do with it. It had already been installed with sort of the basics-there was Apache and there was a version of php; Apache is a web server, and php is a programming language that's used for web programming.

But the version of php was totally out of synch with the actual php code. So one of the things I had to do was go through the php code and update it page by page and go through the php code and make sure that it was all working. This was after Caitlin, Shu Lea, and I had spent a lot of time e-mailing around to create an exhaustive list of all these things that were broken.

And the way these things work is, there's no way to do it quickly. You really just need to say "I'm going to be like a robot right now and I need the list of sixty small things and I'll just check them all off and when we're done, we're done." So we had this list, which included going through and changing the php code. A lot of this was that the php syntax had changed, which meant that certain things just didn't work. Meaning that the page would spit up error messages that the viewer could see, which was not intentional.

Most of those changes were tedious but not difficult. You could still read the intent even if the language was different. You could see, "Oh, this was meant to be a loop; they do loops differently now." So I think anyone with some experience with programming would have been able to get through that without much trouble.

There were little problems on the more front-end side, things with JavaScript, and there were one or two problems with the website's use of frames and how the frame interactions have changed, I think. There were definitely problems with the inclusion of audio files-these sounds that were supposed to play on a loop-so that was something I needed to tweak at the HTML level to cope with new browsers.

JM: You mentioned the problems with Java-portions of the site that were closed off?

FH: I looked into that and I just didn't have that much time to do it, so I felt that given the resources we had to devote to it there was just no way I could fix these things. Generally it was because I didn't enough about what these Java applets were supposed to do, or how they did them. And they seemed to be somewhat complex. It's the sort of thing that, given enough time, I could have just fixed or rewritten from scratch, which you do need to do sometimes. But then you're talking about days and weeks instead of hours. We were trying to get this out without stopping everything. So that's the decision we made. And I think Shu Lea was okay with the decision. Obviously it wasn't ideal, but most of the work was retained.

JM: Since this wasn't an ideal situation for the work, is this something that in the future could or should be revisited, given more time and more money?

FH: I think so. It's all possible.

JM: Maybe the better question to ask is, what did you and Caitlin do in order to maintain the work's viability for the future?

FH: We didn't have a lot of time to devote to anything extensive. And this is a difficult problem in programming anyway. I think that the e-mails that the three of us shared-we should be storing those as part of the archive. I think that helps to communicate the artist's intent. We didn't do a lot more than that.

It's hard to say. When I look at what's done in a commercial context- if you've got a half-million dollar contract to build a website for a big corporation, they require a lot of documentation. But the documents-they're a pain in the ass. It's very hard to write them and not hate them. They're boring and they're really extensive and they can go out of date quickly if the project parameters are changing quickly. The only reason you do them when you're working for a big corporation is because there's a lot more money involved. It's hard for me to imagine an extensive documentation process taking place on a work like this.

I do think there's a lot of promise behind something like the questionnaire that the Guggenheim and the Langlois Foundation developed, the variable media questionnaire. But it's difficult, because that questionnaire, for example, wouldn't cover the fact that, in "Brandon," you have this trial-and-jury applet. How the hell is that supposed to work?

The right way to do it in corporate projects is to do what's called "user stories." Basically the client, who in this case would be the artist, actually writes down sentences, or little paragraphs that are a couple of sentences long, that say, "when so-and-so does this, then this action occurs." In the commercial context, the goal is, let's get the client to explain their needs in their own terms, without throwing a lot of lingo in and without taking the process away from them so they have to spend some time thinking about it.

If organizations want to be serious about this stuff-and I don't know if it's economically feasible for everything-if they want to be serious about accessioning new-media artworks, holding on to them, and exhibiting them in ten years, I think they need to make those kinds of documents part of "the deliverables." The organization needs to say: "We pay you X amount of dollars so that we can exhibit the work, or whatever we pay you for, but one of the things we're paying you for is the documentation. If you don't give us the documentation we need, if it's not rich enough, you're not getting that last check." Because no one is going to do it for free, no one is going to do it for fun, especially because there's a very strong attitude difference between artists and people who work on behalf of conservationists, who worry about conservation and preservation. Artists tend to want to live in the moment, mostly, which is why they became artists in the first place. And then preservationists have this need to protect things on behalf of the future. It's a strongly opposing need. So one way is to say "Look, this is not fun, but this is part of what we're paying you for."

JM: Otherwise we're not really buying the work, we're basically renting it, because if you don't tell us how it's supposed to work it's going to end up dead.

FH: Yes.

JM: Are there problems with new-media works that happen over and over again, that you think people should be more aware of, or is each case unique?

FH: There are vague principles of keeping software, giving it longevity. And these principles are not developed in the art world, they come from the commercial world. Because if you think we've got it bad, imagine being some corporation that ten years ago spent ten million dollars for a giant payroll system, and now it's a thorn in their side because it's breaking all the time and they can't find the right servers to expand it. They worry about it on a much bigger scale than we worry about it.

There are general things to keep in mind, like: open source software is better than closed source; doing things in php or even Java is probably better than in DotNet. Flash and Macromedia stuff, it's a little tenuous, but Flash is very powerful in some ways.

Also, in the craft of computer engineering you have this idea of "coupling," which has to do with how different components are connected and how tightly they're connected and how easy it is for them to be swapped out. And that's part of it too. If your work needs a database, you better be sure that that database is a fairly open-source, common engine.

© 2006-2009 | Independent Media Arts Preservation, Inc.