What the GUI cost architecture

Daniel Davis – 27 February 2010

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.



Join the mailing list to receive an email whenever a new post comes out. Otherwise, you can follow me on Twitter, or add the RSS feed to your reader.


  • Dan Whittet 28 February 2010 at 7:40 am

    This is coming up lately, what do we give up when we become “prisoners” of the interface, or giving too much validity to the model? Check out ” simulation and its discontents” by Sherry Turkle, MIT press. The essays look at the short history of computer simulations and what limits or constraints they create. There is an argument for “hand worked” calculations and understanding the science behind what we ask the computer to do.

  • Daniel 1 March 2010 at 5:56 pm

    Hi Dan, Just went down to the business library and picked up ‘Simulation and its discontents’. It looks really good, particularly looking forward to the chapters on ‘The View From the 1980’s’ and ‘Keepers of the Geometry’. I suppose any abstraction, be it GUI or scientific model, sacrifices nuances for efficiency and clarity.

Leave a comment