The Living on Architecture

December 6, 2009

Pulling data from local electronic sensors and remote data sources alike, architects Soo-In Yang and David Benjamin use building facades as a platform for public participatory media on the environment.  Through their work the duo pushes the boundaries of architecture to create environmentally conscious prototypes using open source design principles.

Work by The Living, Yang and Benjamin’s architecture firm, has been exhibited at the Innovation Lab in Copenhagen, the Chicago Museum of Science and Industry, and Eyebeam in New York, among other locations. They received a commission by the Architectural League of New York in 2009, an Architect Magazine R+D Award in 2008, the New York Prize Fellowship from the Van Alen Institute in 2007.

Amelia: We’re curious about the relationship between the environment, architecture and information and communication technologies. You are exploring that.  How do you define the work that you do, and how did you become interested in doing that work?

David: We started working together in architecture school [at Columbia University’s Graduate School of Architecture] doing some hands-on independent research about various interactive and responsive prototypes for architecture. We were very interested in building things ourselves working with today’s available technologies even though we were also interested in thinking big picture and being futuristic and almost Utopian in a sense.

Although a lot of our research began as a kind of incremental approach of making small-scale things that we could actually get our hands on and work with in our lab or studio, in the bigger sense we’re interested in the potential to connect information with the architecture. Architecture could be some kind public interface for information. Particularly we’re interested in environmental quality information.

Amelia: That’s an interesting idea: if buildings could display data about the environment perhaps they could make us more aware of the changes that we may not be able to see our surroundings, such as air quality, but that are nevertheless relevant to our lives. How could bulidings do this? What kind of data would they use?

David: There is a lot of data about the environment that is already collected through electronic sensors in buildings. The simplest ones are thermostats and energy use monitors. There’s also data from very sophisticated environmental monitoring systems like those that the Environmental Protection Agency (EPA) or the Department of Environmental Conservation (DEC) have. So there’s all of this data available, and sensors are getting cheaper and more networked. There’s more real-time information about the environment that’s available on websites. There are sensors that are gathering information which isn’t currently being displayed to the public. At the same time there’s a growing trend in architecture to embed dynamic systems, often lighting, into building facades. But, they’re typically just creating a pattern or decoration. For the most part these trends – dynamic displays and data – are not connected though it seems obvious to us that they could be.

Soo-In: Another reason why we became interested in this work is because the components, the sensors, the micro-controllers, all the technology that’s involved is becoming increasingly available. There are more and more people working on these kinds of things. That has allowed for an exponential growth in this field compared to even a few years ago. The technology becoming really cheap has a big impact as well on the amount of data collected, and the possiblity for integrating it architecturally.

Amelia: So one could show data on building facades. The building itself would  become a dynamic media platform. What’s your vision for how this could unfold?

David: That’s a really good question, something we’re still thinking a lot about. It’s still kind of early. The display could be about local air and water quality. It could also be about the environment more broadly- in terms of social environments, or the city as an environment or habitat for both people and non-humans. Part of our vision involves the connection between local systems and remote systems.

For example, a building in downtown Manhattan could know about the energy usage of a building in midtown Manhattan. You can imagine expanding this out.  Based on the combination of data from local and remote sources each building might be able to make a more informed decision about how to use energy.

A lot of office buildings will, in the summer, turn on their cooling systems before their workers arrive, but there is a slight flexibility in when those systems turn on. If each building can know about the whole system and peak energy, then by cooperating, by literally talking to each other about their data, maybe the system as a whole can be more efficient. It can tune itself and can, in a way, be better and more responsible about its role in the environment.

Amelia:
You’ve given two related but different examples of the way you use information and communications technology in the design of environmentally-connected buildings.  In projects like Living Light you are using networks of electronic sensors to create information displays on building facades. The building is displaying this information for a human audience. In other applications, your networks of sensors enable buildings to talk to each other. In those cases the buildings are displaying their data for other buildings.

Soo-In:
Yeah, that’s a good distinction. In general, we think of architectural systems as having input, processing and output. We’ve been exploring various ways to put those two outputs together. In some of our initial projects we were just connecting the local input, say a local sensor for carbon dioxide, with a local output like moving gills on a flexible surface. You could hold both the input and the output in one hand or two hands, but it could still provide a register of information and potentially an interesting functional solution.

Now we’ve been exploring the ability of these systems to become networked. It’s possible for all kinds of combinations of input and output, with various levels of sophistication in the processing.  Living Light in Seoul is an example of this.  We’re taking information from existing air quality sensors around the city. We didn’t deploy the sensors. They’re deployed by the municipal government of Seoul. We register their air quality data on a prototype building facade.  We combine the air quality data with a second input which we think of as a sensor for public interest and the environment: a text-messaging interface.

People across Seoul text into a hotline and receive back real-time information about the air quality of their neighborhoods.  We gather real-time data about when people are requesting information on air-quality and which neighborhoods they’re asking about. We display that on the building facade. In this case, the output is just lighting on a building surface. But in other cases the output could be things like management of energy usage, or other building functions.

Amelia: Speaking of inputs and outputs, you are both trained as architects but your process is heavily influenced by both IT design and by ecological memes. How do you view your work vis-a-vis architecture?

David: There are a lot of things in architecture that there are rules of thumb for, handbooks for, and we think that’s great because they’ve already been figured out. So if you want to span a certain distance and you want to use steel, then you get an I-Beam with a certain rating and you look that up in a table. These rules of thumb are helpful. We don’t need to test that. We don’t need to build a prototype, it’s already been tested and proven. We’re interested in exploring questions in areas where there is no rule of thumb. Where we do have to build it and test it in order to know how it’s going to work. That kind of frames how we look for the starting points of our Flash Research projects.

Amelia:
What are those?

David: Flash Research projects have the self-imposed constraints of a budget of a thousand dollars or less, a time frame of three months or less, and the goal of producing a full scale functioning prototype. We didn’t have a huge laboratory. So, how could we,  still explore new ideas? That was the impetus.

Flash Research projects deliberately begin in a very open-ended way. We want to be specific enough that we don’t just explore any path and all paths, but we also want to be open-ended enough that we don’t already know what we’re going to create at the end of the three months. We apply Flash Research to areas in architecture where we don’t already know the answer. The reason we need to build a full-scale functioning prototype is that there’s no exact precedent for it. There’s no rule of thumb. There’s no handbook.

Soo-In: At the end of Flash Research we don’t produce something like a full building but rather a system or a protocol or a platform. That is a seed, we hope in the future will grow into parts of a building. That’s necessary because we wouldn’t be able to build our projects from scratch always. If we have ideas that could be applied to existing buildings as a part or as an add on, it’s kind of like the seed for an ivy vine. It could go on the facade of other buildings or parts of other buildings.

The projects become seeds first, for ourselves. It becomes a hands-on demo of our ideas that we can show for grants or commissions. Then, the project itself can grow into something larger. Oftentimes, that process has been very step-by-step. We start with a prototype and keep improving on it or expanding it iteratively.

We produce an instruction manual for the very first step of the Flash Research project so that the students in our class [at Columbia’s Graduate School of Architecture] can grow that seed into a project of their own. These projects have a similar starting point as the starting point we had for our project. But the outcome could be and is very different. With the students in the class, we document our research and development on a blog. We also make public instruction manuals.  That allows people who aren’t in direct contact with us to grow this seed into something else as well.

Amelia: So, your work often culminates in a protocol or prototype that can be incorporated into larger projects in much the way that open source software programs contribute small modules of code to larger projects.  And you publish these projects to share with students and other architects. Do you see an explicit connection between your work and software design or even IT design processes?

David: In spirit, yes. We draw on work that’s been done by others say in hacking a certain air quality sensor and getting its data. Then, likewise, once we learn something new about a piece of technology we try to offer that back to the broader community. We’ve drawn off of this precedent that may have been established in software, but it’s slightly different in the physical realm.  It doesn’t necessarily involve using the same piece of code and checking it back in with a moderator, but its shares that same spirit.

Amelia:
For your most recent project Amphibious Architecture you have installed floating light displays in two New York City rivers.  These displays interpret data from water quality sensors. They also display public interest and awareness in this environmental data.  How do they do that?

David: As we explored with Living Light, in Amphibious Architecture people can query the system through SMS text messaging.  It encourages people to interact, not just to just watch.  While they’re interacting we get these great possibilities for feedback loops.  The lighting is on floating tubes in the river.  The lighting responds to the environmental sensors in the river, but it also registers the public interest in this environmental data because it responds to SMS.  It’s a kind of collective display exploring how we as a public feel about this data.  Are we interested or not?

Soo-In: Amphibious Architecture is an example of what artists and architects can do with environmental data that scientists in a lab are unable or unwilling to do.  The audience for our projects is much larger and wider.  We provide a much more immediate interface for environmental data than a scientist in a lab can.  The data we provide is accurate, but it’s very low resolution compared to science data.  Because it’s low resolution, communication with the public can be more immediate.

David: We don’t want to replace the existing science data on, say, dissolved oxygen in the East River, but we’re looking for ways complement it.  That’s something we apply in other ways.  In the same way, architects have done amazing work in creating really sophisticated patterns and aesthetics in the display of lighting on building facades. We don’t want to replace that or redo it. But, how can we take that a step further by charging those interactive facades with meaningful data?

Tags: , ,

Systems