Julian Bleecker: PDPal is public in many senses. The more obvious aspects of its public nature are that there are channels of participation that invite active engagement by a large audience. The web is one channel, PDAs another. PDPal is also public in that its "subject"--those things with which its audience engages--is, generally speaking, places in publicly accessible physical locations that can be experienced in some fashion by visiting that place. A more interesting way in which PDPal is public is the way it allows one to share the experiences of these places. One can filter the maps PDPal creates by looking at those of particular users; everyone's maps are available for anyone to view. This is perhaps the most evocative aspect of PDPal's "public" qualities.
Scott Paterson: I tend to think of the term public as a spatiotemporal phenomenon. It concerns the experience of collectively constructing zones where we then act out roles as citizens of that public. PDPal is a public art project because it provides two platforms that support the collective construction of these citizen zones. Inspired by psychogeography, cognitive mapping, and Hakim Bey's temporary autonomous zones, PDPal investigates methods of construction via dimensions beyond the latitude and longitude of geographic mapping, such as time, memory, and emotion. PDPal exists as a public art project in that it considers mobile devices and the web as constantly shifting ephemeral public spaces generated by the expressions of its population of users--a place we call the "communicity."
Marina Zurkow: By public art, I mean it's a project that is shared by many people in a public forum, open for others to witness and/or participate. It is public in the way it is disseminated, through kiosks both within institutions but also in the street, via beaming stations and free exchange between users' infrared ports. I am not forgetting that it is not public for everyone (is any art?); you need techno-literacy and techno-access to participate. But it is not a piece to own or consume.
SD: Why did each of you first become interested in the idea of doing a mapping project?
JB: My interest in PDPal as a mapping project continues to be around the possibility of some sort of cartographic mapping of experience. I'm excited by the idea of maps that are able to refashion traditional boundaries of space--flexing political, economic, and even natural borders and instead bounding space along another entire schema of attributes. With PDPal, one can assign to places attributes and ratings, such as "frequently desolate." What does New York City look like when such descriptions as these are mapped, and when the boundaries are between, say, blasphemous and dangerous zones, rather than two police precincts or the eastern side of a park?
SP: Having an architecture background, I've been making work that seeks the possibility for "architecture" as a protocol between the virtual and the real, that is an interface between the activity of our daily lives and the space of the internet. If we think of physical architecture as a social construct between our bodies and our world, we can also think of a dynamic architecture of information through which we can inhabit and demarcate place within any networked environment--such as the internet. Inherent to this type of work is the mapping of inputs to outputs. In this case the mapping is a kind of translation, an algorithm, an architecture.
MZ: I was first interested in doing a beaming wireless application that utilized character and explored a bridge space between the real and the imagined. This space was one I always perceived as being enriching narratively to both respective spaces, each bouncing off of and informing the other. Scott and I converged in our very different ideas about space and experience design, as I think very narratively (albeit as [I am] an experimental narrative maker, that thinking hinges on structure and arc, not on traditional unfolding of plot and conflict).
SD: Is the communicity a utopian notion or another form of data mining?
SP: I'd say it's neither utopian, for the simple reason that we've not dictated the ideal goal, nor data mining, in that the input/output structure is open ended. Our role as artists in this project has been as frame makers. We've often discussed the spectrum between work that asserts and work that frames. PDPal provides a provocative frame through which users assert. If we now speak about what constitutes the identity of a place as opposed to space, we get into issues of the criteria for description. We can begin by talking about our senses--touch, sight, hearing, smell, and taste--but we can also talk about memory, exposure, connectedness, duration, all of which deal with time. If city building codes are legislation written by elected politicians, PDPal, for me, is a collaborative architecture that exists in a series of ongoing feedback loops.
MZ: The more that the project is framed through the use of instruction sets and specific "assignments" (as in a classroom context), the more the communicity has viable play and doesn't simply call data mining by a glorified name. Currently, the communicity aspect of the piece is little more than simple data mining. But there are two ways in which we see growing communicities. The first is geographically based but very specifically framed. I wouldn't call it utopian as much as eye-opening to the ways in which the city can be used, transformed, and examined. For instance, a communicity of anarchist users will have a version of the city that is meaningful to them: sharing locales, sharing impressions, and uses of space that are meaningful to a group at large--a group that may or may not know each other outside the virtual environment. A classroom of students could build overlapping cities that reflect their critiques of the present city configurations. Another user group might find the community to be the equivalent of a menagerie of transformed fantastic city parts, together making this beast that is the city in all its raging glory and dynamism. The second way in which we perceive the communicity is more like a utopian architecture project, and something Scott can address better than either Julian or I can, having to do with refigured space based on shared dynamic properties, confluences of data, and artistic reinterpretations of users' flows (check me, Scott!). It's a revisualization project that is really off the Cartesian x/y grid.
SD: Describe each of your roles in the collaborative process--both functionally and psychologically.
JB: Functionally, we were all actively engaged in the conceptual work that went into the project. We spent many, many hours hashing through the project's motivation and what sort of meaning-making apparatus we wanted it to become. After the project had some conceptual underpinning, we became specialists. My role was the technologist, which meant that I did much of the general architecture of the "guts" of the PDPal system and, even more practically, did the programming for the PalmTM application and the middleware that constitutes what we refer to as the PDPal mothership--the online part of the application. I also worked closely with a really valiant and diligent team of researchers from Parsons [School of Design] who built the Flash application that is the front end to the web application: Austin Chang, Shruti Chandra, Vicky Fang, Frank Lin, and Jennifer Wheatley.
SP: Functionally I have been responsible for interface design, interaction design, and some production management of the website. I find I am often the linguistic glue between Marina and Julian because I have both a design and technical background. This has been interesting because I have to take into account both of their expertise in designing the interface and interactions. Marina and I work together on making sure the front-end design is consistent with the project goals and I work with Julian to make sure the schematics I've made are doable as well as meaningful. Through it all we developed some interesting working jargon so we had a check that we were all on the same page.
MZ: As Julian said, we all developed the project conceptually. This meant sitting around for hours fighting about how far out you can go with calling something a map, and what is feasible in software development on a relatively small scale for minimalist platforms like the PDA. Functionally, I am the character developer. I designed the Urban Park Ranger and although we all contribute to and critique its manifestation, I am responsible for its realization. I also do all the motion graphics for the project (intros, trailers, etc.) and all the spin-off (be that T-shirts or an analog version of the project). I also spearhead giving voice to the project, though Scott's been instrumental in contributing provocative language to the instruction sets and the phrasing of any textual components.
SD: I think the cartographic aspect of PDPal and its genealogy with the Situationists is clear, but I'm interested in how you think about the narrative/character aspect of the project. What is the role of the Urban Park Ranger beyond a help function?
SP: Every project has a voice or bias. It's the artist's prerogative to make this voice explicit or implicit. Much software-as-art work being done today has an implicit voice in the protocols inherent in the interaction, which is not readily apparent because the project is seen as enabling action rather than limiting it. The Urban Park Ranger on the contrary acts as a provocateur as well as a host to explain the particular bias of the software and in doing so inform the user of our critique of more traditional mapping techniques.
MZ: The world may be divided--somewhat unequally, I suspect--between those who need an anthropomorphic conduit and those who want their material straight up. I'm in the former camp most of the time. It's been our hope that this character gives tone to the piece--a playful stance--and through its characterization as a park ranger/crossing guard, a sense that this "city" we're trying to forge is populated. In addition, the character, by being developed as a system of malleable and morphing parts, suggests the flexibility of all of the parts within the established system of PDPal.
SD: Last question--three parts. I think one of the big issues with open systems is how to design a framework, as you put it, that is open enough to the spontaneous emergence of communicities but also encourages "good" input. What have you learned from the initial implementation at the Walker Art Center and what are you changing for the Times Square launch?
JB: I learned that there is a profound deficit that arises when attempting to simultaneously strive for technical and creative sophistication when one's resources are constrained. Conceptually the project is rather sophisticated and I am afraid that way we caught ourselves in a bit of a language sinkhole. I describe the project to friends and colleagues using the various idioms we've crafted over the last 18 months--"locale," "attribute," "route"--all supernaturalized amongst "we," but quite fast-and-loose when it comes to trying to give an elevator pitch to even clever folks. There's constantly this "What is PDPal?" question, and it's not meant to be a set-up question that one gives for the purposes of an interview. It's a real question, and you can see the earnestness in people's faces because they want to know what we've been spending so much time on. I'm hoping the changes we're making to the Times Square evolution of PDPal--the ability to create a more literally connected dialogue amongst users, as well as the commissioning of PDPal maps of Times Square that are historically, culturally, geographically specific and that mark the many facets of Times Square in authored ways--will bring us to the point where that earnestness for an understanding of PDPal is satisfied.
SP: First, that it's difficult to even overcome the perception of the PDA as a productivity device and, second, to transform it into a creative tool. We had to spend a good deal of time simply explaining how to use the PDA interface, let alone the PDPal interface. In the face of tabul(et)a rasa, most users froze up creatively. When given a very specific assignment, however, they more quickly generated a framework for remembering the basic functions, and when challenged by a specific point of view (e.g., the Urban Park Ranger), users had immediate entry into their own imaginative voice. For Times Square we have three directives to begin the experience. The directives grew out of research about Times Square's past, present, and future. We plan to have mapping workshops with the various populations that inhabit Times Square during the run of the installation as well as invite a series of guest map makers as a catalyst for discussion. Lastly, we added a feature to allow users to comment on each other's recordings, thus increasing dialogue and community.
MZ: I'd add that the directives we came up with--three questions--are distilled from thinking about the different ways a user interacts with a city: through time, movement, consumption, fantasy, memory, and projection. The questions we chose specifically for Times Square ask users to consider what and how they consume a place; what they remember and project; and what sort of transformative fantasies they have about the present--in other words, how they characterize that space.
The other thing we learned is that we no longer give total primacy to the software version of PDPal. We have made a one-minute film and several print versions of the project, having developed a core visual language that allows us to express it in a variety of forms, from the overtly interactive to the contemplative.