Once when studying computer science I had to present a computer program to my lecturer, in his office. The computer in his office was dual-screen but all he had open was six text based terminal windows (like the DOS command line on Windows). He looked on expectantly, waiting for me to demonstrate my program by typing commands into the terminal. Coming from the School of Architecture I had never seen anyone operate a computer without a Graphical User Interface (GUI), and I had no idea how to operate it myself. After typing Abracadabra a few times, I eventually had to restart the computer and use the mouse and icons to open up my program. I left the office feeling pretty stupid. The feeling continued until I got my marking sheet back where my lecturer raved about how intuitive my use of the mouse and the GUI had been. The GUI is not all bad.
Recently I have been looking at old CAD programs, from the days before any sort of standard GUI. Like the story with my computer science professor, it is easy to see why in the 1980′s, mouse based GUI’s became so popular. But something I had not considered, until I started reading about these old systems, is what the architect gave up to use a GUI.
The most obvious ramification is that the GUI immediately limits the vocabulary of the architect. If the architect wants to draw a line between two points, there is probably an icon for it, but if they want to produce a catenary curve – like the curves of Gaudí and the Voussoir Cloud – they are probably out of luck. The software developer is entrusted with the generation of new vocabularies, dishing out new tools for the architect with every software release – doubly curved curtain walls in Revit 2010! The current trend towards scripting is a realisation of the GUI’s limitations and an attempt by architects to take control of their tools and as a consequence, their buildings. (See anything written by Kostas Terzidis).
A less obvious ramification of the GUI is that it destroys the history of how an object is created. In the pre-GUI days objects were created with lines of code, which provided a list of commands that needed to be executed to make the object. If the object did not look as intended, any of these commands could be edited, added to, or removed. However with the GUI, the focus shifted from editing how the object was made, to directly editing the object. This is because it is hard to visulise all the commands that generated an object with a GUI - in each instance the object is Tabula Rasa with its method of generation destroyed. So the only way to edit an object through the GUI is by adding further commands to it, or to undo the last command, thereby destroying the current one. The history of an object is important to architects who worship napkin sketches, smudges and Scarpa’s drawings – probably because how something was created tells us about why it was created. The history is also important if we want to revise a design and perhaps start with a square rather than a circle. Associative modelling and graph based parametric modelling are two techniques used to activate the history of a GUI based drawing.
I certainly could not live like my computer science professor and only use a text based interface on my computer. However the GUI is a bit like fast food, it is convenient, but it is important to know the sacrifice you are making to the health of your body or design for this convenience. It is reassuring to see that architecture has embraced digital technology to the point where some of these sacrifices are being mitigated.
The Voussoir Cloud Installation by IwamotoScott Architecture carries on Gaudí and Otto’s tradition of using hanging chain models as form finding tools.
A chain will naturally hang in pure tension, and inverting this shape produces an arch in pure compression. Producing a design in compression without any torsion or shear forces allowed Gaudí to build without flying buttresses, and the Voussoir Cloud Installation to be paper thin. In the Voussoir Cloud Installation, the form was found by specifying the points where the structure was to touch the ground and then, with software developed by Buro Happold, hanging virtual chains from these points, which define the edges of the surfaces. The shape of the curve is particular to the weight of the material. In this case the very thin timber veneer produces much flatter curves than if it was made out of concrete. The hanging chain model asks the material, almost in Kahn’s words, “what it wants to be” and the material falls into place. You can play with a similar tool called CADenary developed by Axel Killian and released free of charge.
WPA2 : Local Code / Real Estates is a project by Nicholas de Monchaux that utilises GIS data to identify abandoned sites, and Grasshopper to design a custom urban space for each site. 150 sites in total. With that many designs, even easy tasks like making a render becomes difficult: turning layers on an off in Grasshopper, sending each version to Illustrator and saving the image to become a single frame in the movie. But while the project shows of some dexterous file management skills, I still have some reservations about the architectural worth of this project:
My first concern is with what constitutes site in this project. Like in many digital projects, site has been reduced to the quantifiable parameters: solar incidence, wind direction, demographics and geometric data. This data driven, hyper-local approach leads to an erasure of context, as described by Francesca Hughes in AD 79:
“‘Context’ in the culture of parametric production returns, or is reinstalled, already digitalised, and edited to the bone: typically as a set of three to five measurable, and thus necessarily quantitative, physical parameters (latitude, wind direction, and typical rush-hour capacity, say). Once optimised, these parameters effectively ‘contextualise’ the system or proposal, argue that it is inthe right place at the right time. That is, context returns as a highly abstracted, carefully selected alibi. Architects have always, necessarily, artfully reduced context to harness it as a generator and justifier of action. This is nothing new.What is new is that with parametric systems this reductive process from the outset excludes any indeterminate or qualitative content –ironically such parameters are usually the more site-specific ones.”
With some much of the context excluded in Local Code : Real Estates, it is worth considering how responsive the designs actually are. Whilst they are geometrically unique, they have a universal, almost modernist, unity to them that denies context. Even in the renders context has been reduced to data – white geometric planes – with no indication of the inhabitants reacting to the lee wind planting necessitated by the data to reduce their energy consumption.
My second concern is the way the design is produced in Grasshopper. The code seems to use a rule based algorithm: place trees on the south side if there is no wind. The problem with this approach is that design can not be expressed in a formal logic. As Manual De Landa puts it in his 1993 essay “Virtual Environments and the Emergence of Synthetic Reason”:
“[early artificial intelligence] researchers explicitly put symbols (labels, rules, recipes) and symbol-manipulating skills into the computer. When it was realized that logic alone was not enough to manipulate these symbols in a significantly “intelligent” way, they began to extract the rules of thumb, tricks of the trade and other non-formal heuristic knowledge from human experts, and put these into the machine but also as fully formed symbolic structures. ”
In this situation, the computer un-intelligently executes rules on behalf of the architect who takes little responsibility for the results. It is a flawed method that finds neither the optimum or the apt-imum.
Both of these concerns might be answered with a “wait for the next revision,” a reply that has been given by various architects for decades. Sure, now with Moore’s Law we can produce hundreds more designs, much faster, but the fundamental problems of digital architecture remain: site is just data and design is just rules. I wish I could remember who asked “are we there yet?” but I suspect there have been quite a few. Local Code : Real Estates demonstrates that once we get there this technology will scale easily, but Local Code : Real Estates makes no progress towards getting us there.
I have a few details of this project wrong, so thank you to Nicholas de Monchaux for emailing me with a few further details. These designs are not intended to be built, like I assumed in my ‘First Concern,’ but rather act as an armature for public discussion. At about 3:30 minutes into the first video you can see people using the Berkeley Opinion software to comment on their local design. This of course brings up issues of public design, which have been endlessly discussed elsewhere. However what I find exciting about this proposal is how closely it relates to the Wikipedia bots, which were originally used to produce articles about cities from GIS and census data (that looked like this) these machine created entries could then be edited by individuals in the community to make them more relevant. Like the Wikipedia bots, I wonder if there is potential to open up a GIS API and let anyone develop a bot to populate these vacant sites. The bots would each design for the thousands of sites and the citizens would be free to pick and choose parts of each design that they liked. Such a system would not free us from the problem, identified by Francesca Hughes, of designing from data but the system might inspire us to move beyond the currently employed rule based design. (A bit like the Net Flicks Prize)
rss feed
