What the GUI cost architecture

Daniel Davis – 27 February 2010


nce 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.