using cellular automata to support architectural ...

1 downloads 0 Views 6MB Size Report
management science and cognitive psychology (Eastman 1969). Since the ...... This study takes a mixed methods approach (Creswell 2003) as it combines an.
Title

Author(s)

From form generators to automated diagrams : using cellular automata to support architectural design

Herr, Christiane Margerita

Citation

Issue Date

URL

Rights

2008

http://hdl.handle.net/10722/50272

unrestricted

Abstract of the thesis entitled

From Form Generators to Automated Diagrams: Using Cellular Automata to Support Architectural Designing

Submitted by

Christiane Margerita Herr for the degree of Doctor of Philosophy at The University of Hong Kong in April 2008

Cellular automata (CA) are systems of cells capable of generating intricate patterns based on rules relating to local cell neighbourhoods. In the field of architectural design, CA have been adopted as one of a variety of generative design approaches, which aim to use computers to support design beyond imitating conventional drawing tools. Previous applications to architectural design have employed CA mainly to generate representations of physical building form. Furthermore, such applications have typically adopted CA models from other fields of study without considering possible modifications to specifically support architectural design.

This study explores how CA can be adapted to the architectural design context to support architectural design, focusing on the early, conceptual stages of the design process. Based on a literature review and initial proposition, an extended CA model was proposed to address the modelling of architectural form as well as the integration of CA into the conceptual design process.

To accommodate the exploratory nature of this study as well as the characteristically difficult to predict nature of design results, action research with a qualitative focus was adopted as the method of inquiry. The initially proposed extended CA model was developed through five research cycles, each of which consisted of the development of CA-based software implementations that were applied by architecture students in design studio and workshop settings. Field notes, interviews, design critiques as well as questionnaires and software interaction tracking were evaluated to inform the development of subsequent implementations.

The first three implementations were based on the initially proposed extended CA model, and focused on the generation of building form. For this purpose, CA with extended modelling capacities were introduced, such as non-uniform grids and cell neighbourhoods. These applications however yielded only limited success, as students tended to transcend the limits of given software by misappropriating it for their individual purposes. In response to these results, the fourth and in particular the fifth implementation integrated CA with diagrammatic representations to encourage re-interpretation during the conceptual design stages. These “automated diagrams” consisted of semi-automated diagrammatic representations that employed CA to respond to manipulations according to user-defined rules.

Results from the five implementations suggest that generic CA-based design support focusing on the generation of form does not provide sufficient opportunities for concept development. Diagrammatic representations integrated with CA-based functions could however enrich the early stages of students’ architectural design processes by encouraging individual interpretations of CA-generated outcomes. Student comments further suggested that the configuration and application of rules should be developed to enable more intuitive and less precise ways to configure and apply rules.

This study contributes an extended CA model adapted for architectural design purposes. Outcomes of this study suggest that CA-based architectural design process support is not limited to the generation of intricate patterns representing physical building form. CA may also support conceptual design processes by integrating rule-based element relationships with diagrammatic visual representations. Such “automated diagrams” enable designers to explore intangible aspects of design problems that are related to personal design intentions and interpretations.

From Form Generators to Automated Diagrams: Using Cellular Automata to Support Architectural Design

by

Christiane Margerita Herr Dipl.-Ing. (Architektur), University of Kassel, Germany MArch, The University of Hong Kong

A thesis submitted in partial fulfillment of the requirements for the Degree of Doctor of Philosophy at The University of Hong Kong

April 2008

Declaration

I declare that this thesis represents my own work, except where due acknowledgement is made, and that it has not been previously included in a thesis, dissertation or report submitted to this University or to any other institution for a degree, diploma, or other qualifications.

Signed …………………………………………………………… Christiane Margerita Herr Department of Architecture The University of Hong Kong

i

Published work In the course of this investigation, the following papers have been published: Herr, C.M.: 2003, Challenging Cookie-Cutter Architecture using Cellular Automata, in C. Soddu (ed), The Proceedings of the 6th Conference and Exhibition on Generative Art 2003. Generative Design Lab, DiAP, Politechnico di Milano University, Italy, 72-81. Herr, C.M. and Fischer, T.: 2004, Using Hardware Cellular Automata to simulate Use in Adaptive Architecture, in: H.S. Lee and J.W. Choi: Proceedings of the Ninth CAADRIA Conference. Institute of Millenium Environmental Design and Research, Yonsei University Press, Korea, 815-828. Herr, C.M. and Kvan, T.: 2005, Using Cellular Automata to Generate High-Density Building Form, in B. Martens, and A. Brown (eds), Computer Aided Architectural Design Futures 2005. The Proceedings of The Eleventh International Conference on CAAD Futures. Springer Verlag, Dordrecht, 249-258. Herr, C.M., Fischer, T., Wang, H.F. and Wei, R.: 2005, Demand-Driven Generative Design of Sustainable Housing for China, in Tsou J.Y. et al. (eds), Proceedings of the Fifth China Urban Housing Conference, Vol. 2. China Architecture and Building Press, Hong Kong, 703-710. Herr, C.M. and Kvan, T.: 2007, Adapting cellular automata to support the architectural design process, Automation in Construction 16(1), 61-69. Fischer, T. and Herr, C.M.: 2007, The Designer as Toolbreaker? Probing Tool Use in Applied Generative Design, in G. Yu, Q. Zhou and W. Dong (eds), CAADRIA 2007. The Proceedings of The Twelfth International Conference on Computer-Aided Architectural Design Research in Asia, School of Architecture, Southeast University and School of Architecture Nanjing University, Nanjing, China, 2007, 381-389. Herr, C.M. and Karakiewicz, J.: 2007, Algogram: automated diagrams for an architectural design studio, CAAD Futures 2007, The Proceedings of The Twelvth International Conference on CAAD Futures, Sydney University, Sydney, Australia, July 11-13 2007, pp. 167-180.

ii

Acknowledgements I am deeply grateful to my supervisors, Prof. Justyna Karakiewicz and Prof. Tom Kvan, who have both guided and encouraged me throughout this study and continuously provided tremendous support.

I would also like to thank my fellow students and researchers in Prof. Kvan’s and in Prof. Karakiewicz’s research groups: Dr. Song Gao, Steve Kuan, Dr. Thomas Li, Weidong Li, Kal Ng, Juliana Rotmeyer, Dr. Marc Aurel Schnabel, Dr. Hartmut Seichter, Dr. Ruffina Thilakaratne, Binqing Zhai, and in particular Dr. Janice Affleck and Yunyan Jia, who provided me with much-needed insightful and critical feedback throughout this study.

I would like to acknowledge the support and feedback from all students at The University at Hong Kong who have been involved in this study, in particular the 4th year students taking part in the studio test during the winter semester 2005. I would also like to thank Peggy Louie for her courage to explore CA-based design in her studio project as well as for her reliable and open-minded teamwork.

I would further like to thank the graduate students and staff at the Department of Architecture at the National Cheng Kung University, who have made the generative workshop possible, in particular Prof. Taysheng Jeng and Prof. Maolin Chiu. I am grateful to the 2nd year students who used Algogram in their studio work during the fall 2006 semester: Wu Tsz Ching, Zhang Jia Heng, Kwong Yan Kit, Ho Wing Ho, Yu Yuk Fan, Lee Man Yeng, Luk Lai Fun, Lo Yee Cheung, Kwan Chun Sing and in particular, Fu Hui Yan. I would also like to thank Dennis Fung and Abby Chan for sharing their design work. Thank you also to the many other staff and students at The University of Hong Kong, who were involved in studio critiques, discussions and private conversations on various aspects of my research topic, and even served as babysitters when required, in particular Haoyu Wang and Shalinee Coorey.

I am indebted to The University of Hong Kong for granting me a PhD studentship without which I could not have pursued this study.

Finally, I would like to thank my family, who have always found encouraging words to keep me going. What motivated me most, however, is that I could always come home to Lily and Tom at the end of the day. iii

Content From Form Generators to Automated Diagrams:.....................................................................I Declaration ...............................................................................................................................i Published work ........................................................................................................................ii Acknowledgements ................................................................................................................iii Content ...................................................................................................................................iv Figures...................................................................................................................................vii Tables ...................................................................................................................................viii Chapter 1. Introduction............................................................................................................ 1 1.1 Computers as conceptual design support .......................................................................... 2 1.2 CA as generative design approach .................................................................................... 4 1.3 Research focus and aims ................................................................................................... 6 1.4 Research scope and method .............................................................................................. 7 1.5 Structure of the thesis ........................................................................................................ 7 Chapter 2. Literature Review .................................................................................................. 9 2.1 Design process models .................................................................................................... 10 2.1.1 Linear and rational problem solving models ............................................................ 11 2.1.2 The nature of design problems ................................................................................. 13 2.1.3 Conversational models of design.............................................................................. 14 2.1.4 Summary .................................................................................................................. 18 2.2 Design support................................................................................................................. 18 2.2.1 Tools and media ....................................................................................................... 20 2.2.2 Representations for design ....................................................................................... 21 2.2.3 Sketches.................................................................................................................... 23 2.2.4 Diagrams .................................................................................................................. 26 2.2.4.1. Diagram theory................................................................................................. 29 2.2.4.2. Practitioners’ views .......................................................................................... 32 2.2.4.3. Computer-supported diagrams ......................................................................... 34 2.2.5 Summary .................................................................................................................. 36 2.3 Computers as design support........................................................................................... 37 2.3.1 Generative Design .................................................................................................... 38 2.3.2 Cellular Automata .................................................................................................... 41 2.3.3 Cellular Automata in Architecture ........................................................................... 44 2.3.4 Summary .................................................................................................................. 48 2.4 Summary and the research problem ................................................................................ 48 2.4.1 Research problem ..................................................................................................... 50 iv

2.4.2 Research questions ................................................................................................... 50 Chapter 3. Research Methodology ........................................................................................ 52 3.1 Action research and research methods in design............................................................. 53 3.2 Action research in this study ........................................................................................... 55 3.3 Implementation cycles in this study ................................................................................ 59 3.4.1. Cero 9 remodelling .............................................................................................. 60 3.4.2. A studio test at The University of Hong Kong.................................................... 61 3.4.3. Tainan generative design workshop .................................................................... 62 3.4.4. KCRC urban automata ........................................................................................ 63 3.4.5. Algogram............................................................................................................. 63 3.4 Data collection methods .................................................................................................. 64 Chapter 4. Extended CA........................................................................................................ 66 4.1 Extended CA for modelling form.................................................................................... 67 4.2 Integrating extended CA into the architectural design process ....................................... 70 Chapter 5. Five Implementations .......................................................................................... 75 5.1 Cero9 Re-modelling ........................................................................................................ 76 5.1.1 Introduction .............................................................................................................. 76 5.1.2 Initial assumptions.................................................................................................... 77 5.1.3 Aims and expected outcomes ................................................................................... 78 5.1.4 Implementation......................................................................................................... 78 5.1.5 Results ...................................................................................................................... 80 5.1.6 Discussion ................................................................................................................ 82 5.1.7 Resulting questions................................................................................................... 83 5.2 A studio test at The University of Hong Kong................................................................ 84 5.2.1 Introduction .............................................................................................................. 84 5.2.2 Revised proposition.................................................................................................. 85 5.2.3 Aims and expected outcomes ................................................................................... 85 5.2.4 Implementation......................................................................................................... 86 5.2.5 Results ...................................................................................................................... 87 5.2.6 Discussion ................................................................................................................ 89 5.2.7 Resulting questions................................................................................................... 90 5.3 Tainan generative design workshop ................................................................................ 91 5.3.1 Introduction .............................................................................................................. 91 5.3.2 Aims and expected outcomes ................................................................................... 92 5.3.3 Revised proposition.................................................................................................. 93 5.3.4 Implementation......................................................................................................... 94 5.3.5 Results ...................................................................................................................... 96 v

5.3.6 Discussion .............................................................................................................. 100 5.3.7 Resulting questions................................................................................................. 102 5.4 KCRC urban automata .................................................................................................. 102 5.4.1 Introduction ............................................................................................................ 102 5.4.2 Aims and expected outcomes ................................................................................. 104 5.4.3 Revised proposition................................................................................................ 104 5.4.4 Implementation....................................................................................................... 104 5.4.5 Results .................................................................................................................... 106 5.4.6 Discussion .............................................................................................................. 107 5.4.7 Resulting questions................................................................................................. 108 5.5 Algogram....................................................................................................................... 109 5.5.1 Introduction ............................................................................................................ 109 5.5.2 Aims and expected outcomes ................................................................................. 111 5.5.3 Revised Proposition................................................................................................ 112 5.5.4 Implementation....................................................................................................... 112 5.5.5 Results .................................................................................................................... 115 5.5.6 Discussion .............................................................................................................. 119 5.5.7 Resulting questions................................................................................................. 122 5.6 Summary: From form generators to automated diagrams ............................................. 122 Chapter 6. Discussion.......................................................................................................... 125 6.1 Summary: The research process.................................................................................... 126 6.2 Reconsidering support for designing............................................................................. 127 6.3 A new perspective on CA as architectural design support ............................................ 129 6.4 Automated diagrams...................................................................................................... 131 6.5 Implications ................................................................................................................... 133 6.6 Limitations .................................................................................................................... 136 6.7 Contributions ................................................................................................................. 136 6.8 Future research .............................................................................................................. 137 Appendix 1. Action research, applied ethnography and grounded theory: a discussion ..... 140 Appendix 2. Tainan generative design workshop data........................................................ 143 Appendix 3. KCRC urban automata presentation posters................................................... 151 References: .......................................................................................................................... 155

vi

Figures Figure 1: CA-generated form based on rules proposed by Schrandt and Ulam (1970) .......... 5 Figure 2: Linear, rational, and cyclical models of the design process................................... 11 Figure 3: Schön’s cyclic design process model..................................................................... 16 Figure 4: Conceptual design sketches by Gehry (left) and Miralles (right) .......................... 24 Figure 5: Venn diagrams (after Phillips 2006) ...................................................................... 27 Figure 6: Alison Smithson, diagram for an “appliance house” ............................................. 29 Figure 7: Kazuyo Sejima and Ryue Nishizawa: Park Café, Koga, Japan 1998 .................... 31 Figure 8: Architectural diagrams by Behnisch (left) and Campo Baeza (right).................... 32 Figure 9: Architectural diagrams by Bates (left) and Maki (right)........................................ 33 Figure 10: Gerbils in SEEK, Malagueira grammar by Duarte .............................................. 40 Figure 11: CA-based simulation of the development of the Chicago region ........................ 43 Figure 12: Variations of conventional urban CA-based models ........................................... 44 Figure 13: König and Bauriedel’s CA-based urban design process...................................... 45 Figure 14: Applications of CA to architectural design.......................................................... 46 Figure 15: They cyclic action research process adopted in this study................................... 55 Figure 16: Sequence of action research cycles in this study ................................................. 58 Figure 17: Diagrammatic overview of the action research cycles in this study .................... 59 Figure 18: Conventional CA and object-based (extended) CA............................................. 68 Figure 19: Potential variety of cell scales in architectural CA models ................................. 69 Figure 20: Schön’s model extended to integrate generative CA support .............................. 71 Figure 21: Fully automated and dialogue-based iterative design processes.......................... 73 Figure 22: High-density architecture for Aomori/Japan by Cero9........................................ 76 Figure 23: Visual description of rules used in the original manual design process .............. 77 Figure 24: Scripting window during the remodelling process .............................................. 79 Figure 25: Sequence of design moves in CA-supported remodelling process ...................... 80 Figure 26: Alternative cellular automata-generated versions of Cero9’s design .................. 81 Figure 27: Paper-based CA exercise ..................................................................................... 85 Figure 28: Graphical user interface of the utility used in this implementation ..................... 86 Figure 29: Exploratory design results generated with CA-based design support 1............... 88 Figure 30: Exploratory design results generated with CA-based design support 2............... 88 Figure 31: Tofu Automata Generator quick-start card .......................................................... 94 Figure 32: Forms generated with the Tofu Automata Generator .......................................... 95 Figure 33: Samples of workshop results ............................................................................... 96 Figure 34: Function use frequency in the Tofu Automata Generator.................................... 97 Figure 35: Perceived usefulness of functions in the Tofu Automata Generator.................... 98 vii

Figure 36: Examples of tool re-appropriation ....................................................................... 99 Figure 37: Sequence of manual rule execution on paper..................................................... 103 Figure 38: Graphical user interface of the CA-based software implementation ................. 105 Figure 39: Sequence of generating an urban new town model in layers ............................. 106 Figure 40: Excerpts from Peggy Louie’s presentation posters............................................ 106 Figure 41: Peggy’s conceptual urban model presented as urban form................................ 107 Figure 42: Algogram user interface..................................................................................... 113 Figure 43: Visual analysis of Algogram diagram................................................................ 114 Figure 44: Algograms by Finnie Yu, Ho Wing Ho, and Claire Fu ..................................... 115 Figure 45: School design by Abby Chan............................................................................. 115 Figure 46: School design by Lui Kam Fung ....................................................................... 116 Figure 47: Dancing school by Athena Lee .......................................................................... 117 Figure 48: Translation of algograms into building form by Finnie Yu ............................... 118 Figure 49: Studies of function overlaps by Adrian Lo ........................................................ 118 Figure 50: Tofu Automata Generator reference card (front)............................................... 143 Figure 51: Tofu Automata Generator reference card (front)............................................... 144 Figure 52: Perceived Usefulness of Tofu Automata Generator functions........................... 147 Figure 53: Frequency of use for each function of the Tofu Automata Generator ............... 150 Figure 54: Peggy Louie: KCRC Urban Automata Presentation I........................................ 151 Figure 55: Peggy Louie: KCRC Urban Automata Presentation II ...................................... 152 Figure 56: Peggy Louie: KCRC Urban Automata Presentation III..................................... 153 Figure 57: Peggy Louie: KCRC Urban Automata Presentation IV..................................... 154

Tables Table 1: Rational problem solving and the reflection-in-action paradigms summarized...... 16 Table 2: Goel’s classification of symbol systems (after Sobek and Patel 2005)................... 22

viii

Chapter 1. Introduction This chapter outlines the background, aims and the scope of this study. Section 1.1 introduces computers as architectural design support, and outlines the roles computers commonly play in current architectural design processes. It further introduces relevant terms used throughout this study. Section 1.2 relates cellular automata (CA), focus of this study, to the wider field of generative design and presents the aims of this research. In the following section (Section 1.3), the research scope of this study is outlined. Section 1.4 presents action research, the method of inquiry chosen for this study, and describes the research scope. The final section in this chapter, Section 1.5, lays out the structure of the thesis.

1

1.1 Computers as conceptual design support Computers are widely held to offer strong potential for supporting the architectural design process. Yet, applications of computers to architectural design mostly remain bound to the later stages of the design process, at the level of drafting, data storage or communication. Earlier, conceptual design stages seem widely unaffected by the introduction of computers to architectural design practice and education, and conventional paper-based sketching prevails as typically chosen architectural conceptual design support (Parthenios 2005, p. 108). This discrepancy is reflected by Lawson (2004), who expresses disappointment when describing current computer-aided design: “In fact computer-aided design has turned out to be rather a disappointment so far. There is little evidence that it has significantly improved the quality of design or made designing a better experience.” (p. 64) This study was motivated by the gap between the perceived potential offered by applications of computers to design on the one hand, and the lack of conceptual design applications on the other hand. Applications of computers to architectural design may take a variety of approaches, depending on the role computers play within the design process. This study investigates cellular automata (CA), a generative design approach, as conceptual design process support. Conceptual design takes place in the early stages of the design processes, when new ideas are developed and gradually refined. At this exploratory stage, design processes are characteristically described as ambiguous, playful and unpredictable. The conceptual design phase involves the creative development of design solutions to ill-structured problems, during which alternative solution proposals are generated and explored (Goel 1999). Conceptual design processes are open-ended, with no clear beginning and end. According to Parthenios (2005, p. 112) architects initially need to be free of most constraints when engaging in conceptual design processes. During this stage, restrictions are increasingly applied, such that the exploration of possible solutions is gradually narrowed down until a suitable response to the design problem is decided upon. Conceptual design forms a crucial but also somewhat elusive part of every architectural design process, as emphasized by Tschumi (ibid., p. 114): “Architecture is the materialization of concept. (...) Architecture is not about form. Architecture is about idea.” Conceptual design process support typically aims to enrich architects’ idea development processes by encouraging the generation of a variety of alternative ideas or concepts (see for example Frazer 1995). Design processes have been described to be of a cyclical, conversational nature (Schön 1983). New ideas are typically developed through the repeated externalization of thoughts and their subsequent evaluation, which leads to re-consideration of initial proposals and gradual idea development. At the conceptual design stage, architects typically use freehand sketching to support their design processes. Based on studies observing designers 2

during the early design stages, Schön and Wiggins (1992) suggest that sketches support creative thinking by providing visual representations that enable designers to make unintended discoveries upon inspecting them. The conceptual design process can thus be described as repeated cycles of sketching, inspecting, and revising. Suwa and Tversky (1996) argue that when viewing their own sketches, designers are able to see new relations and features that suggest ways to refine and further develop their ideas. Multiple interpretations are made possible through abstract, ambiguous types of representations such as sketches and diagrams that encourage exploration of related concepts (Goel 1995). While the conceptual design stage consists of idea generation and development, the ensuing design phases are described as more constrained and structured to enable refinement and detailing of initial concepts (Goel 1999). While computers are rarely used to support conceptual design processes, they are typically applied at the refinement and detailing stage to visualize, compare and implement initially developed ideas (Suwa and Tversky 1996). This use of computers in design aims primarily at increasing the speed and efficiency of processes that can be automated to some extent, such as computer-aided drafting, three-dimensional modelling, document storage and comunication. Computer support for such tasks is typically offered in form of “tools”. In analogy to non-digital tools such as scissors, rulers or pens, these tools characteristically facilitate a specific task, usually the manipulation of two-dimensional drawings or threedimensional models, such as in the drawing of lines and curves, or in “move”, “extend” or “skew” functions of standard CAD systems. Rather than concentrating on specific tasks and the corresponding tools, however, computer-based support for the conceptual design stages could also provide environments that enhance the architect’s creativity (Glanville 1995). Carrara (1991) suggests that instead of endeavouring to develop a system capable of autonomous creative design, approaches to support conceptual design should aim at providing “a context in which creative design could be made easier and its results better”. In this context, ambiguity and fluidity are vital conditions enabling creative design processes and should be embraced by conventional CAD systems (McCullough, Mitchell et al. 1990). Applications of computers to architectural design often aim at fully automating aspects of the architectural design process. In this study, computers are used to enhance rather than fully automate the architect’s conceptual design process. The design process thus becomes hybrid, consisting of both semi-automated sequences and conventional modelling activities. For this reason, software developed in the context of this study is referred to as “design support” instead of the commonly used “design tool” throughout this thesis. This is intended to emphasize the strong focus on process and context in conceptual design, rather than concentrating on the software itself or design outcomes.

3

1.2 CA as generative design approach This study investigates the application of CA as conceptual architectural design support. CA form part of a variety of generative design approaches that aim to use computers to support design processes beyond the automation of conventional drafting or model-making procedures. Generative design approaches instead harness the capability of computers to process large sets of data in order to generate a variety of alternatives in the early design stages, from which the designer may then choose the most appropriate one for further development. Generative design typically employs rule-based procedures to generate such alternatives, whereas different generative design approaches employ different types of rules. Among the more well-known generative design approaches are shape grammars and evolutionary algorithms. Mitchell (1990), for example, identified compositional rules in Palladian villas and developed a shape grammar to remodel existing as well as to generate new “Palladian villas”. Frazer (1995) proposed the use of genetic algorithms to create varieties of design solutions in analogy to biological evolutionary processes. Shape grammars, genetic algorithms and other generative design approaches typically create unanticipated and thus apparently creative results in form of two- or three-dimensional shapes. Based on their theoretical and methodological underpinnings, generative design approaches and related tools have been described and classified as either “top-down” or “bottom-up” oriented. Schmitt (1993, pp. 42-45) gives a basic discussion of both approaches. More recent examples include Chase (2005) and Scheurer (2005). In top-down oriented approaches, initially defined overall forms are iteratively differentiated into more detailed forms to fulfil additional design criteria, as in parametric geometry variation. In bottom-up generative design, configurational rules are iteratively applied to generate forms that are initially difficult to predict. CA, the generative design approach explored in this study represent, in this sense, a bottom-up oriented generative design approach. Initially proposed as “mathematical games” by Schrandt and Ulam (1970), CA employ simple rules to transform basic shapes (cells), typically squares or cubes that are arranged on regular Cartesian lattice grids. CA cells can assume different predefined states, often consisting of binary opposites such as “on” or “off”, which can change based on rules stipulating conditions. Such conditions typically relate to each cell’s surrounding cells (neighbourhood). Though based on simple rules, the recursive application of such rules can quickly generate intricate and unanticipated patterns. Among the most well-known CA systems is the Game of Life, developed by Conway and first introduced by Gardner (1970). It illustrates how a collection of cells can live, die or multiply based on a small set of simple rules, generating various patterns throughout the course of the game. 4

Two- or three-dimensional CA-generated patterns seem related to architectural design at several levels. As the three-dimensional CA in Figure 1 illustrates, they can be reminiscent of urban or architectural plans or building form. CA further depend on procedural rule-based logic, which can be related to rules governing architectural composition or functionality used in architectural design processes. CA are based on spatial relationships between cells, which usually refer to some form of cell “neighbourhood”. Finally, relationships between CA cells have a temporal and procedural dimension, which can be linked to the gradual development of design proposals during the architectural design process

Figure 1: CA-generated form based on rules proposed by Schrandt and Ulam (1970)

To give an example of a typical simple CA system, the following paragraph lays out the rules of growth used to generate the three-dimensional patterns illustrated in Figure x. The rules were originally proposed by Schrandt and Ulam (1970) in an early paper exploring three-dimensional CA systems. Our growth is in the plane subdivided into regular squares. The starting configuration may be an arbitrary set of (closed) squares. The growth proceeds by generations in discrete intervals of time. Only the squares of the last generation are “alive” and able to give rise to new squares. Given the nth generation, we define the (n + 1)th as follows. A square of the next generation is formed if:

(1)

it is contiguous to one and only one square of the current generation;

(2)

if touches no other previously occupied square except if the square should be its “grandparent”;

5

(3)

of this set of prospective squares, of this (n + 1) generation satisfying the previous condition, we eliminate all those that would touch each other. Again there is an exception for those squares that have the same parent; these are allowed to touch.

In three dimensions the growth rule which we have adopted is the same. One merely replaces the squares by cubes and observes all our three provisions. (pp. 233-235)

With the features of CA outlined above, CA are considered relevant to computer-aided architectural design as a generative design strategy (Chase 2005, Krawczyk 2002). Applications of CA to architectural design, however, have so far remained few, and their scope has mostly been limited to specific design projects. CA are typically used to generate intricate three-dimensional patterns that are subsequently interpreted as directly representing physical building form. Though they are usually applied at the initial, conceptual design stages, neither their relationship to creative design processes nor their connection to conventional design support, such as sketching, have yet been explored in-depth.

1.3 Research focus and aims This study explores the application of CA to support conceptual architectural design processes. A review of previous work employing CA in the area of generative design suggests a potential to be further explored in the context of conceptual architectural design processes. To develop new knowledge regarding how the use of CA can contribute to conceptual architectural design, this study initially focused on extending its capabilities to model architectural form. For this purpose, the study proposed an extended CA model (outlined in detail in Chapter 4) that suggests modifications to conventional application of CA in order to expand the capacity to model architectural forms and contexts. The extended CA model indicated how it could be integrated into conceptual architectural design processes. As this study progressed, however, the initial focus was changed to accommodate a wider understanding of the role of CA in the architectural design process beyond form generating and modelling support, drawing on conventional conceptual design support such as sketches and diagrams. As this study aims to inform theory development with insights derived from applied design contexts, the initial CA model is developed and tested through a series of five software implementations, each of which features the application of CA-based software in design studio or workshop settings. The initial research focus on CA as a way to model and generate architectural form gradually expanded and focused increasingly on conceptual, dialogical ways of supporting concept generation in analogy to sketches and diagrams.

6

From these outcomes, this study presents a new perspective on CA as support to conceptual design processes by integrating rule-based logic and diagrammatic visual representations.

1.4 Research scope and method To support the explorative strategy described in Section 1.3, this study employs action research as a method of inquiry, as the applied, open-ended and cyclical nature of action research provides a basis for integrating design applications and research aims. Throughout the five implementation cycles, insight is gradually developed and fed back on the extended CA model initially proposed. As this study involves design applications, which characteristically produce initially unanticipated results, data collection focused primarily on qualitative data. While quantitative data collection requires initial definition of the nature of the results to be measured, qualitative data collection accommodates unexpected outcomes, which occurred frequently throughout this study. Initially, this study was intended to progress from theory-building inquiry employing qualitative data collection to a subsequent phase of testing the initially developed extended CA model with an emphasis on quantitative data. Accordingly, the third implementation cycle focused on quantitative data collection but yielded only limited results compared to qualitative data collected in the same implementation cycle, such that the following implementations reverted to open-ended qualitative data collection. As this study focuses on applied design processes of architecture students as well as software development to gain understanding of CA as support for conceptual architectural design processes, research outcomes are not limited to theoretical insights. The applied design processes forming the central part of this study necessarily entail software development, student learning and design results. As this study focuses on developing and contributing to design theory in the context of a specific generative design paradigm, these secondary aspects form contributions of this thesis, but do not constitute central aims. In the context of this study, the main purpose of developing software was to gain understanding of the nature of CA as design support as well as open-ended user feedback. For this reason, these secondary observations and contributions are reported only insofar as they support the primary aims of this study.

1.5 Structure of the thesis Chapter 1 introduces characteristics of conceptual design processes and presents CA as a generative design strategy. It further outlines the aims of this study as well as the research method employed.

7

Chapter 2 reviews literature relevant to this study. It provides a background to the nature of design problems and design process models, discusses conventional design aids such as sketches and diagrams in relation to their role in the design process, and introduces generative design as well as applications of CA to architecture in further detail. This chapter also presents the research problem as well as the research questions.

Chapter 3 presents action research as a method of inquiry in relation to research in the field of architectural design. It further gives an overview of the five implementation cycles in this study from a methodological viewpoint.

Chapter 4 develops an extended CA model for applications to conceptual architectural design based on the literature review in Chapter 2.

Chapter 5 presents a detailed account of the five action research cycles of this study.

Chapter 6 summarises the outcomes of the study and relates findings from the implementations back to initial hypotheses.

8

Chapter 2. Literature Review This chapter establishes the historical background and the contextual framework of this study. It introduces positions and previous findings from three areas of research, which are drawn upon to develop an approach to CA as conceptual design process support that involves both designer and computer as active participants of conversations. First, design process models are discussed as a basis for the integration of CA into the architectural design process. To this end, Section 2.1 illustrates the differences between linear and conversational models of the design process and their historic development. Section 2.1 concludes with a more detailed review of conversational models of design, which emphasize the cyclical nature of the design process and are adopted as a basis for the extended CA model proposed in Chapter 4. As this research aims to support the early, conceptual design stages, the following Section 2.2 reviews literature on conventional design aids typically used by designers during the early design stages. This section focuses on the use of sketches and diagrams to support creative thinking during the conversational design process described in the previous section. For this reason, this section outlines three perspectives on diagrams – the theoretical perspective, the practitioner’s perspective and computer-based strategies to support diagrams in architectural design. Section 2.3 briefly introduces approaches to the application of computers to design. As CA are one of a variety of generative design approaches, literature on generative design approaches and precedents is reviewed to provide a background for the following, more specific sections on classic CA and on precedents for applications of CA to the field of architectural design. The chapter concludes with a brief summary, the research questions of this thesis and a preliminary proposition proposing the need for extensions to conventional CA for applications to conceptual architectural design.

9

2.1 Design process models Different design process models imply different views on the nature of the design process. This section reviews and contrasts linear and rational design process models with conversational design process models. This discussion subsequently serves as a basis for a model that outlines how CA can be integrated into the architectural design process. Military strategies and successes of the Second World War incited researchers of various disciplines to pay increased attention to systematic and goal-oriented processes (Cross 1984, p. ix). Design became subject to scientific methods of enquiry during the Cold War period of the 1950s and 60s, and design process models were developed with the objective to describe and analyse how design works. The aim was to understand the design process and improve it in a way that placed less emphasis on and which was less dependent on artistic genius and inspiration. Design was treated as a rational reasoning activity that had much in common with problem-solving in other disciplines. The earliest model for capturing design as a systematic activity was probably the “systems approach” or “mission-oriented approach” as practiced by NASA (Rittel 1984, p. 318), which subsequently informed management science. Early models of the design process were inspired by similar studies in the areas of management science and cognitive psychology (Eastman 1969). Since the first Conference on Design Methods, held in 1962 (Jones and Thornley 1963), several generations of design researchers have proposed their views on the design process in form of distinct design methodologies (Cross 1993, p. 17). Among the earliest advances in the area of design methods were those by the Design Methods Group surrounding Alexander (1963) and Jones (1963), who presented their seminal papers at the first Conference on Design Methods in 1962. Early proponents of the systematized design process turned against their earlier theories only several years later, disappointed with the lack of successes of the approach. Alexander famously criticized design methodology: “If you call it, “It’s a Good Idea to Do”, I like it very much; if you call it a “Method”, I like it but I’m beginning to get turned off; if you call it a “Methodology”, I just don’t want to talk about it.”(Alexander 1971). Following this initial disappointment, increased attention was paid to the particular nature of design problems. Rittel and Webber (1973) distinguished “tame” problems from “wicked” problems, which accounts for the deficiencies of earlier rational, scientific approaches to design. For Rittel, this distinction of design problems from other problem categories marked the transition from design methods of the first to the second generation (Rittel 1984, p. 322). Design process models of the first generation are typically linear (Figure 2, left-hand sinde) or depend on the rational division of design problems into smaller problems which are solved separately (Figure 2, middle). Cross (2006) implicitly regards this transition as the

10

threshold between “design methods” and the current “design research”. The transition also relates to Downton’s classification of research methods into “research for design” and research about design” (Downton 2003, see also Section 3.1). Further developing the idea of design as a process of continuous feedback between designer and context, design researchers have come to view design as a cyclical process (Figure 2, right-hand side) that can be described in form of a dialogue-based model. This approach underlies the model proposed by Schön (1983), which has parallels to dialogue-based design process models developed in Cybernetics. The following Sections give further details on the history and characteristics of linear, rational and conversational design process models.

Figure 2: Linear, rational, and cyclical models of the design process

2.1.1 Linear and rational problem solving models Early models of the design process see design as a sequence of distinct design phases. Rowe (1987, p. 47-49) describes the models of Asimow (1962) and Archer (1984), which both feature a sequential progression of design phases in a static order. Designers are assumed to follow these steps from beginning to end. This understanding of the design process implies that all design problems can be tackled by addressing the issues relevant in each design phase one after the other. Asimow's model contains a vertical structure involving a sequence of activities, and a horizontal structure describing decision-making cycles found in all phases of the design process. The general sequence of activities in this model proceeds from abstract considerations to more concrete and specific ones. Phases are connected by feedback loops to explain how decisions can be traced back in case changes or difficulties occur. Archer's (1984) model, originating from the ideological context of the Hochschule für Gestaltung at Ulm, presents design as an objective and rational activity. It progresses from an analysis phase to a creative phase which leads to a phase of execution. He proposes a detailed model that attempts to link characteristics of the designer (such as training and experience) to the brief and the problem definition. The ensuing phases of the design process are described as data collection, analysis, synthesis and development, reaching fruition through communication. Archer’s (1984) model seems to centre on data collection, as in the phases of analysis, synthesis and development designers are supposed to revert

11

back to data collection if the results of the process seem unsatisfactory. Another characteristic of these models of the design process is that design is described as a general process, irrespective of context and particular circumstances. Variations of such design process models, summarized as “waterfall models” are still taught and practiced today, in particular in engineering contexts (Dominick et al. 2001). Other attempts to model the design process as an entirely rational process do not rely so much on the sequential progression through distinct phases. Instead, they emphasize the decomposition of larger problems into their hierarchically structured aspects or constituent sub-problems, which are then solved separately. Rowe (1987, p. 51) terms this position the information processing theory of problem solving. The assumption behind this approach is that once a given “problem space” is sufficiently defined by determining all relevant variables, problem solving can proceed in a rational manner, such that even complex problems can be solved by using only a small, finite number of basic information processing mechanisms. Simon (1981, p. 143) describes the decomposition of ill-defined problems into smaller problems to explore partial solutions. According to Newell et al. (1962), this division itself is a creative activity as it helps to redefine the initially vague problem statement. Newell and Simon (1972) developed a framework for human problem solving called the “General Problem Solver”, implemented in form of a software program. The theory behind the General Problem Solver attempted to explain all behaviour as a function of memory operations, control processes and rules. The reasoning implicit in GPS is that, if a desired situation differs from a present situation by differences D1, D2, …, Dn, and if action A1 removes differences of type D1, action A2 removes differences of type D2, and so on, then the present situation can be transformed into the desired situation by performing the sequence of actions A1A2…An. (Simon 1981, p. 143)

Hatchuel (2002) characterises Simon’s (1996) views on the design process as confined within a decision making and problem solving paradigm. Simon describes design as a search through a problem space, whereby designers tend to make decisions in a style Simon describes as “bounded rationality”. This concept emphasizes problem solving on a “satisficing” principle, with design decisions influenced by subjectivity, tacit knowledge, rules of thumb, heuristics or ad hoc moves. The design process is thus distinct from the process of objective optimization but remains a largely rational problem-solving activity. Simon attempts to capture creativity by introducing “imagination”, which he assumes provides the initial list of actions necessary to start a process of problem solving heuristics. The research approach outlined above have been questioned as concerned primarily with description and classification rather than practical application of their findings. 12

Hatchuel (2002) notes the deficiencies of seeking to clarify and define initially ill-defined tasks early on, suggesting that vague notations are effectively creative strategies to invite further ideas. While some of the studies outlined above informed the development of software tools for aiding or automating all or part of the design process, Yakeley (2000, p.35) states that overall, studies of this kind tend to stand as models isolated from practical use. They have however created a picture of the design process and the cognitive functions and processes it involves, which designers combine in an individual manner when designing.

2.1.2 The nature of design problems Shortcomings of rational approaches to design as described in Section 2.1.1 above, gradually became evident when applications of “scientific” methods to design lacked success (Cross 1993, p. 16) and design problems seemed to elude rational strategies to solve them. In response to Simon’s The Sciences of the Artificial, published in 1967, Rittel and Webber (1973) characterized design problems as “wicked” and inherently incompatible with Simon’s intention of establishing a rigorous science of design (Coyne 2004, p. 6). The new focus of attention was on the particular nature of design problems, which had been largely ignored in earlier approaches. Jones (1984) describes his experience in writing a comprehensive account of design methods: What’s striking is that each method begins with a first stage that is extremely difficult to do, which has no description of how to do it, which is intuitive. What emerged in writing the book was that to use design methods one needs to be able to identify the right variables, the important ones, and to accept instability in the design problem itself. One has to transform the problem and the solution all in one mental act or process. (p.331-332)

Problem types have generally been distinguished in terms of the clarity of their definition. Rowe (1987, p. 40-41) describes “well-defined”, “ill-defined” and “wicked” problems. Well-defined problems can be exhaustively formulated and subsequently solved by relying on a known set of techniques and knowledge. For this reason, Rittel and Webber (1973) also described this type of problem, commonly dealt with in much of applied science and in applied engineering, as “tame”. Ill-defined problems lack the definition of well-defined problems, with both ends and means of the solution unknown in their entirety at the outset of the problem-solving exercise (Newell, Shaw and Simon 1967, p.71). According to Rowe (1987), this type of problem is commonly found in architecture and planning and while the general thrust of the problem may be clear, a large part of the problem-solving effort is usually spent on problem definition and redefinition. In their influential article “Dilemmas in a General Theory of Planning”, Rittel and Webber (1973) characterised design and 13

planning problems as “wicked”. According to Rittel and Webber, wicked problems can be distinguished from tame problems by the following characteristics:

o

There is no definitive formulation of a wicked problem

o

Wicked problems have no stopping rule

o

Solutions to wicked problems are not true-or-false, but good-or-bad

o

There is no immediate and no ultimate test of a solution to a wicked problem

o

Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly

o

Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan

o

Every wicked problem is essentially unique

o

Every wicked problem can be considered to be a symptom of another problem

o

The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution

o

The planner has no right to be wrong

This description of design problems as ill-defined or wicked problems gave rise to a new generation of design research approaches, which turned away from earlier attempts to treat the process of design as either a linear sequence or a rational form of optimisation. Design researchers dropped their ambition of developing a general science of design as “…design is fundamentally concerned with the particular, and there is no science of the particular” (Buchanan 1996, p. 16). Solutions to ill-defined problems are not absolute but necessarily satisfactory or appropriate within a specific context. The design process was thus recognised to be of an argumentative, participatory nature (Cross 2006, p. 2). This new view on design problems resulted in a change in approach to design theory as well as design research. Design research paid increased attention to the theoretical analysis of the particular nature of design problems as well as empirical observations of design practice.

2.1.3 Conversational models of design In the rational view of the design process as discussed in Section 2.1.1, a problem statement is merely a starting point. Rittel and Webber (1973) however, claimed that a problem statement corresponds to a solution of a design problem. This means that an essential part of the design process consists of defining and redefining the problem statement while the solution is developed. The process of defining the problem is cyclical in nature, and results in a statement of the problem that already contains the solution (Elliott 2002, p. 51). Solutions to a wicked problem cannot be judged true or false (Rittel and Webber 1973). In 14

conversational models of design, the designer makes decisions by negotiating the various goals and demands of a design process in direct feedback within a given situation, as described by Schön (1983): [A designer] works in particular situations, uses particular materials, and employs a distinctive medium and language. Typically, his making process is complex. There are more variables - kinds of possible moves, norms, and interrelationships of these - than can be represented in a finite model. Because of this complexity, the designer’s moves tend, happily or unhappily, to produce consequences other than those intended. When this happens, the designer may take account of the unintended changes he has made in the situation by forming new appreciations and understanding and by making new moves. He shapes the situation, in accordance with his initial appreciation of it, the situation "talks back," and he responds to the situation’s back-talk. (p.78-79)

Design processes involve both external and internal conversation. External conversation takes the form of public discussion, with stakeholders participating in the solution finding process (Rittel 1984, p. 320). Another aspect of the design process is the internal conversation designers engage in as part of their design thinking. Schön (1983) describes this type of private conversation as a dialogue between the designer and the situation, or reflection-in-action: In a good process of design, this conversation with the situation is reflective. In answer to the situation’s back-talk, the designer reflects-in-action on the construction of the problem, the strategies of action, or the model of the phenomena, which have been implicit in his moves. (p.79)

Schön describes the design process as reflection-in-action (Schön 1983), characterized in terms of three distinct activities: framing, moving and reflecting. Upon engaging into a design process, designers produce a “frame” for the situation encountered that functions as a guide for subsequent action or “moves”. Design moves initiated by the designer will change the situation under consideration in some ways. Stepping back from the situation, the designer then assesses the changes and devises a strategy for the next design move. This last, reflective step forms the basis for further cycles of moving, reflecting and framing, ideally until the designer is satisfied with the results of the process. This study focuses on the “move” in Schön’s design process model and proposes an extended design “move” to accommodate CA-based generative design support in Chapter 4.

15

Figure 3: Schön’s cyclic design process model

In Schön’s model, the situation is not just subject to imposed changes but “talks back” to the designer, which drives reflection and renewed framing activities. The “backtalk” of a design situation results from the designer perceiving new aspects of a situation when stepping back and reassessing it (Schön and Wiggins 1993). This process has similarities to the widely accepted understanding of problem solving processes as consisting of analysis, synthesis and evaluation; but it involves many such cycles, usually in connection with some form of external representation. While reflection in Schön’s model is explicit to allow for a conversation to happen, the design process also generates a form of implicit “knowing-inaction”, tacit knowledge accumulated by practitioners who frequently engage in design processes. Knowing-in-action enables intuitive actions that are performed without explanation and seemingly effortlessly (Schön 1983, p. 50). Tacit knowledge is an important factor in design processes but is not well integrated into the rational problem-solving paradigm. The reason for this is that tacit knowledge is not readily made explicit, as practitioners are often unaware of this type of knowledge or cannot put it into words (for a more detailed discussion of tacit knowledge, see Polaniy 1967). For this reason, the way designers use rules in design has been characterized as largely implicit, diverse, contextually dependent and subject to exceptions and modifications (Schön 1988). Overall, Schön’s model draws primarily on the observation of practitioners and does not attempt to provide designers with truths or methods to follow. Table 1 (after Dorst and Dijkhuis 1995, p. 263) gives an overview of the rational and reflection-in-action paradigms as outlined above. Table 1: The rational problem solving paradigm and the reflection-in-action paradigms summarized

Designer Design problem Design process Design knowledge Example/ model

Rational problem solving information processer (in an objective reality) ill defined, unstructured a rational search process knowledge of design procedures and ‘scientific’ laws optimization theory, the natural sciences 16

Reflection in action person constructing his/her reality essentially unique a reflective conversation artistry of design: when to apply which procedure / piece of knowledge art/ the social sciences

Schön’s work is based on a phenomenological point of view (Dorst 2004), which stresses the individual construction of reality and contrasts with the positivistic point of view underlying conventional scientific methods. In this view, the construction of meaning is heavily dependent on the individual interpreting an object as well as the individual’s previous history and environment. Person and object are thus inextricably connected. Schön’s (1983) model of the design process provides an account of the design process that emerged from the observation of practitioners at work rather than theoretical assumptions. As such, it describes design in a way that does not so much separate or label particular design stages, but provides insight into the cyclical, conversational aspect of design processes at all stages of the design process. In this study, Schön’s (1983) model serves as a basis for the development of a model that describes how CA may be integrated into the early stages of the design process. Schön’s (1983) model emphasizes the cyclical nature of the design process, which progresses through cycles of “framing”, “moving” and “reflecting”. Such cycles of design reasoning are typically supported by sketching in the architectural design process, which enable the designer to engage in a conversation with the situation (Schön 1983). The importance of conversation in creative thought processes has been similarly emphasized from a cybernetic point of view by Glanville (1999), who refers to Pask (1969) in his characterisation of the design process. Glanville (1999) describes conversation as a circular form of communication, in which understandings are exchanged:

I characterize design as a conversation, usually held via a medium such as paper and pencil, with an other (either an "actual" other or oneself acting as an other) as the conversational partner. (…) Design-as-conversation will be familiar from the doodle on the back from the envelope upwards. I believe the value of the doodle is an instance of creativity firing the doodler's enthusiasm, personal research, and commitment. Creativity also may be found elsewhere. But this circular process certainly is one in which novelty - a distinguishing feature of design and so typical of creativity - can be generated, whether the novelty is global, or only to the person designing, at that instant. (p. 88)

In this view, participants of a conversation build meanings though the conversation itself rather than relying on the communication of predetermined meanings, whereby differences of understanding during conversation are the source of new thoughts. The cybernetic point of view presents the source of meaning and novelty as inextricably linked to both designers and their medium of communication and interaction. In architecture, the medium of communication for such design conversations is typically the sketch. Sketches allow 17

designers to use external representations to reconsider and assess their thought development. The use of sketches in the design process is examined further in Section 2.2.

2.1.4 Summary Design processes typically do not follow a sequential or easily predictable logic, despite early attempts to categorize them as such. Rittel and Webber (1973) described the characteristic open-endedness of design problems as “wicked”, as such problems defy attempts at applying purely rational problem solving strategies. Wicked problems are illdefined and require designers to redefine the problem in order to proceed – not merely in the initial stage, but also at various later stages during the design process. Schön (1983) described the nature of the design process as reflective. Designers typically engage in some form of conversation with the situation at hand. Design problems tend to resist categorization in terms of problem structure but are subject to continuous interpretation by the designer (Dorst 2004). In terms of Schön’s theory, this interpretation can be described as the imposition of structure upon an unstructured problem context. Design problems and solutions thus evolve in parallel, with the designer using various modes of conversation and representation to negotiate the challenges he encounters. Gadamer (1986) posits that the basic operation in the acquisition of knowledge is interpretation. Interpretation is a dualistic activity, involving both a “revealing of what the thing itself already points to” and “an attribution of value to something” (ibid., p. 68-69). Dorst (2004) describes these aspects of interpretation as “objective interpretation” and “subjective interpretation”, which find different applications within the design process. For design processes or stages that require increased control and objectification of design goals and decisions in order to communicate and negotiate with stakeholders, objective interpretation may be needed. Subjective interpretation becomes important in a design project or stage that is ill-structured and requires subjective structuring in order to make sense of the problem. To support this process of subjective structuring, in particular during the early design stages, architects typically make extensive use of sketches and diagrams. These representations provide a means to externalize ideas and engage in the creative conversation with the situation described by Schön (1983).

2.2 Design support This study explores CA as design process support. Based on the discussion of design process models in the previous section, this section focuses on the nature of design support in relation to the design process. It primarily discusses the role of sketches and diagrams,

18

which designers typically rely on during the early design stages, and leads to a review of literature on computers as design support in Section 2.3. Buchanan (1995, p. 18) characterizes design as the “liberal art of technological culture”, whereby technology denotes not a product but the “discipline of systematic thinking”. According to Buchanan, in an earlier period of Western culture every liberal art possessed such a discipline of thinking, which was not perceived as restricting or limiting but as enabling for the individual who mastered it. Buchanan (1995) continues to argue that the power of design lies in bridging the separation between words and things or theory and practice that is prevalent in contemporary culture: Argument in design thinking moves toward the concrete interplay and interconnection of signs, things, actions, and thoughts. Every designer’s sketch, blueprint, flow chart, graph, three-dimensional model, or other product proposal is an example of such argumentation. (p. 19)

Buchanan’s description of design argumentation features the conventional design aids of sketches, diagrams and models. These design tools are used to amplify designers’ creative process, but they also focus the designer on particular ways of working and thinking. According to McCullough (1996), a tool directs the attention of the user, to the extent that its function becomes the user’s focus: “…as the saying goes, when you hold a hammer, all the world looks like nails. Its function extends some powers of your hand, and prevents the use of others. In other words, it serves a specialization.” (p. 59). Using design tools, however, requires specialist skill. Such skills are an essential part of the design process and the “discipline of thinking” described by Buchanan. “In routine, skilled tool use the user is disattending from the tool (and the practices of its use) in attending to something else.” (Glock 2003, p. 224) Used in this way, tools tend to “disappear” from the user’s conscious focus of attention and instead become extensions of the body (Polanyi 2003, p. 59). To support their design processes, designers make use of a wide variety of techniques and tools. The choice of tools depends on the particular goals within a design process: According to Dorst’s (2004) characterization of the different aspects of design processes, tools may be employed for objective interpretation purposes in well-defined problems or subjective structuring of ill-defined problems. In case objectification of design goals and strategies is required, tools provide technical means for predefined ends (Glock 2003, p. 223). In design processes that involve mainly subjective interpretation, however, tools need to support the open-ended conversation that Schön (1983) described as reflection-in-action as discussed in Section 2.1.3. For this reason, design aids that support objective reasoning can be described as goal- or output-oriented, while tools that aid designers in subjective interpretation tend to 19

be process-oriented. The design aids mentioned by Buchanan (1995, p. 19) all have in common that they provide designers with some form of external representation of internal ideas (Galle and Kovacs 1992). External representations such as sketches assist designers by serving as external symbol systems to facilitate thinking and support emergent ideas (Do 2005, p. 384). Representations thus play an important role in the early design stages which is the focus of this study. Design tools can be distinguished further according to the interaction between designer and design tool. Gibson (1977) proposed the term “affordance” to describe the workable capability of a medium or tool. Affordances are relationships between the world and an “actor”, describing potential actions that may take place between objects and actors. While affordances are a property of the world that do not have to be visible, known, or desirable (Norman 1999, p. 39), humans need to perceive them in order to make use of them. A door, for example, can afford opening in the way that the perception of a door handle allows an approaching person to deduce that this door can be opened by pushing. These “perceived affordances”, in combination with constraints and conventions, guide the interaction of humans and objects (McCullough, 1996, p. 198). The properties of an object thus determine the possibilities for action. Depending on their properties, tools can thus afford actions that can be employed in solving tasks. According to McCullough, "a tool is a moving entity whose use is initiated and actively guided by a human being, for whom it acts as an extension, toward a specific purpose" (1996, p. 68). In order to function as the almost invisible extension to the designer’s body as described by McCullough (1996, p. 68) and Glock (2003, p. 224), design tools need to fulfil a number of criteria. An example list for such criteria is given by von Wodtke (2000, p. xi): “For tools to be used creatively, they must be: enabling (…), liberating (…), simple (…), unobtrusive (…), lightweight and portable (…), affordable.” While such criteria are intended to guide the development of digital design tools, they also refer to properties characteristic of the conventional design support of sketches and diagrams, which are discussed further in the following sections.

2.2.1 Tools and media According to Glanville (1995, p. 6), design aids can be differentiated into tools and media. This distinction is useful when considering the different needs of designers in different stages of the design process. In the previous Sections, two aspects of design activity were distinguished according to Dorst (2004): subjective and objective interpretation. Designers may approach a problem in a goal-driven and structured manner or seek open-ended results by way of an exploratory design process. These strategies require different types of support. Objective interpretation emphasizes control, while subjective interpretation fosters 20

exploration and discovery. Glanville (1995, p. 5) describes tools as devices to automate what humans do, at increased speed. He distinguishes tools from media as described by McLuhan (1994), which tend to take on a life of their own even though they might have been intended to serve as tools. Media are not mere carriers of information, but shape both their content as well as their socio-cultural context by the characteristics of the medium itself (McLuhan 1994). When considering the application of technology to design, Glanville (1995, p. 6) recommends acknowledging its medium character: “Then we allow that a technology has its own character: and we recognise that character, its qualities, and we acknowledge it as being more than just a tool. We accept it as what I call "a medium" (...)”. Glanville (1995) argues that in this property of media lies a potential to aid design processes: Then, the technology, being treated as a medium, can become a participant in our (design) activities, for it is recognised as a (potential) contributor due to the separate character it is understood to have. At this point, it helps form undertakings not by amplifying our intentions but by extending—in-forming—them: in more conventional words, we could say that a medium helps turn data into information. As such, when we do something through a medium, it may return that something to us modified in ways other than we had anticipated (ie, more than amplified), as if repeated back to us by other correspondents in a conversation, as a phrase is re-presented to us in new words to help us confirm the co-respondent has "understood" ( p. 6)

This strategy may be employed to get beyond the limitations of designers’ imagination. It is based on the concept of conversation underlying novelty generation as proposed by Laing et al. (1966) and Pask (1975). Negroponte (1975) adopted this model as a paradigm for visual creativity and communication in the early days of the Architecture Machine Group, which pioneered applications of the computer to the architectural design process. Schön’s model of the design process as discussed in Section 2.1.3 is based on a similar view of the creative process. By returning input in modified and unanticipated ways, media in the sense described above may support the conceptual design stages by providing opportunities for inspiration. As this study aims to employ computers in their capacity as medium in the sense of Glanville (1995) and McLuhan (1994) to support designers in the role of a conversation partner, the term “design support” will be used instead of the term “tool” when reporting on the software implementations developed over the course of this study.

2.2.2 Representations for design Design support used for creative design typically provide designers with some form of representation. Goldschmidt and Porter (2000) claim that designers cannot design without

21

representations.

Representations

in

design

include

three-dimensional

physical

representations (models), two-dimensional representations such as text, sketches, or notes as well as verbal representations. Representations, whether paper-based or computer-aided, enable designers not only to record or communicate their thoughts, but also aid in developing new ideas (Fish 1996). Goel (1995) observed three aspects of representations used to support the design process: Designers manipulate representations of the world rather than the world itself. They also use a variety of different symbol systems to represent the world. Goel (1995) further states that these symbol systems are correlated with different problem-solving phases and cognitive processes. Representations thus become inseparable from the design process. He distinguishes external representations into three types of symbol systems of significance to design: notational, discursive, and non-notational symbol systems (Table 2). Table 2: Goel’s classification of symbol systems (after Sobek and Patel 2005)

Definition

Examples

Notational System structured well defined specific unambiguous ZIP code telephone number musical score

Discursive System structured well defined specific ambiguous natural languages predicate calculus

Non-notational System unstructured unclear vague ambiguous sketches sculpture seismograph readout

According to Goel (1995), non-notational symbol systems are essential for innovative design because their ambiguous nature encourages creativity: “This ambiguity allows for multiple interpretations, which in turn facilitates transformations between different ideas. It simultaneously encourages divergence and discourages premature convergence.” (Sobek and Patel 1995) Drawings play a critical role in the design process (Robbins and Cullinan 1994, Fish 1996, Purcell and Gero 1998). During the design process, designers employ different types of drawings. Initially, relatively unstructured forms of drawing are used, which are considered to be related to creativity and innovation in design (Herbert 1988). Later in the design process, drawings tend to become more structured and subject to conventions, for example in the case of plans and Sections in architectural design. Drawing types may be distinguished based on a number of criteria, for example (1) the type of information contained in the drawing, (2) their audience: whether they are only used by the designer himself or to communicate with others, and (3) the format and medium of the drawing. Fraser and Henmi (1994) proposed a classification system of architectural drawings. They distinguish “referential drawings”, “diagrams”, “design drawings”, “presentation drawings” and “visionary drawings”. Lawson (2004a) refers to the taxonomy of drawings by Fraser 22

and Henmi (1994) as mainly based on drawing characteristics. He proposes a more elaborate taxonomy "based on the way in which knowledge is being manipulated in the minds of the member of the design team and communicated to other participants." (Lawson 2004a, p. 33) Lawson’s taxonomy distinguishes the following drawing types: “presentation drawings”, “instruction drawings”, “consultation drawings”, “experiential drawings”, “diagrams”, “fabulous drawings”, “proposition drawings” and “calculation drawings”. Drawings have more functions than as mere external data storage: "external representations are not merely inputs and stimuli to the internal mind (…) they have much more important functions than mere memory aids.” (Zhang 1997, p. 179) Zhang further suggests that “the form of a representation determines what information can be perceived, what processes can be activated, and what structures can be discovered from the specific representation." (ibid.) The focus of this thesis is on the early design stages, when architects are developing conceptual ideas. The drawing types prevalent in the early phase of conventional architectural design processes are sketches and diagrams. In Goel’s (1995) theory, these drawing types are identified as “non-notational symbol systems”. When developing his theory of notational systems and creativity, Goel (1995) specifically studied architectural sketching. He argues that these drawing types are chosen over other types of drawings as they can provide representations with varying amounts of ambiguity to foster continuous idea development and creative thinking. The following sections discuss the nature of sketches and diagrams in further detail and analyse their role in creative reasoning.

2.2.3 Sketches In architectural design, the established design support of choice is sketching, which is used at all stages of the design process, from initial ideas to refinements of the final shape. Sketches as described here are not presentation drawings but support the designer in the reflective thought process described by Schön (1983, see also Section 2.1.3) Sketching is not a linear or deterministic process but involves a variety of different activities when exploring design alternatives. Neiman et al. (1999) describe the following sketching activities: the transformation of shapes, the changing of viewpoints, drawing types and media, the establishing of constraints, referring to previous sketches to infer possible solutions, frameworks and design strategies, and the evaluation of proposals. Sketching is often a playful, explorative activity: "We found the designer "plays games" by defining rules, selecting strategies and design moves between self-imposed rules, and discovering and evaluating the outcome." (Neiman et al., 1999) Sketches work by enabling designers to externalize their thinking into graphic representations that provide visual cues for revision and refinement of design (Suwa and

23

Tversky 1997). In Schön’s description of the design process (Schön 1983, see also Section 2.1.3), the designer is engaged in a reflective conversation with the design problem. In this cyclical model, the designer “sees” and then “moves” design objects in a process of sketching, reflecting, and sketching again. While continually manipulating sketches, designers respond to the changes brought about by their interventions by changing their perception of the problem. Goldschmidt (1991) has described this process as involving the two basic operations of “seeing as” and “seeing that”. The different modalities of seeing in a dialogue-based design process have led Goldschmidt (1995) to describe the sketching designer as “a team of one”. Sketches thus enable the framing and re-framing of a design problem (in the sense of Schön 1983), and as a consequence aid in the production of new ideas (Fish 1996). Figure 4 illustrates design sketches by Gehry (Schank Smith 2005, p. 226) and Miralles (ibid., p. 244). Gehry’s conceptual ink drawings study possible elevations of the Guggenheim Museum in Bilbao. Miralles uses crayon to “…form crucial relationships between concepts or representational spaces” (ibid., p. 245) in the design of the Mollet del Valles Park and Civic Center.

Figure 4: Conceptual design sketches by Gehry (left) and Miralles (right)

While design representations are frequently described as “talking back” to the designer (Schön 1983, Goldschmidt 2006), in conventional sketching it is indeed the designer himself who interprets what he sees, perceiving this perspective change as “backtalk” of an active conversation partner. Sketches, however, can only “talk back” if the representational system allows for visual discovery. Goel (1995) holds that the unique quality of design representations is their tolerance for ambiguity. He describes drawings as amorphous symbol systems that enable thought processes that are vague, fluid and ambiguous (see for example sketches by Gehry and Miralles in Figure 4). Such processes, he claims, are essential to human thought and defy current cognitive models that emphasize precise, rigid, discrete and unambiguous symbol systems. Analysing and summarizing previous work in the field (Herbert 1988, Goldschmidt 1991, Robbins and Cullinan 1994, Fish 1996, Lawson, 1997), Gao (2006, p. 40-43) identifies the following key cognitive properties of drawings: 24

1) Recording and communication Drawings record and store data generated during the design process, and serve to externalise ideas or for subsequent reference. Drawings are also used in both internal and external communication of the designer (Schön 1983, Fish 1996).

2) Dual mode of cognition Norman (1993) describes pictorial representations as support for experiential cognition, the reactive and automatic thought characteristic of skilled behaviour. Pictorial representations are assumed to facilitate the interaction between perception and memory. According to Gombrich (1982), two aspects of this process may be distinguished: recognition as well as emergence. Emergence is recognition resulting in the inference or reinterpretation of images (Soufi and Edmonds 1996, Oxman 2002). Schön and Wiggins (1992) describe this phenomenon as unexpected discovery, which results from designers reading new aspects in their drawings.

3) Cognitive monitoring Drawings enable constant feedback during their production, thus enabling a monitoring process that guides design reasoning by continuously adjusting the input parameters of the monitored process (Fish 1996).

4) Segregation Pictorial representations allow humans to segregate form for selective attention (Fish 1996). Selective attention is essential for human cognition, which is based on abstraction and representation (Norman 1993).

Lawson (2004b) describes two modes of content in drawings: symbolic and formal content. Symbolic descriptions are more economic than formal geometric descriptions as they refer to concepts already known to the designer, such as “it looks like a squashed sun” (Lawson 2004b, p. 450). Formal geometric descriptions require much more effort to convey the same information: the “squashed sun” could also be described as “it is a long flat ellipse with some lines growing radically from it all around and extending out about as far as the vertical diameter” (ibid.). Lawson suggests that novice designers tend to use formal geometric descriptions, while more experienced students tend to use symbolic references to design precedents. Symbolic references to information beyond the drawing are essential when interpreting drawings during the design process. Symbolic references also tend to rely on conventions, such that designers often use similar graphic elements to refer to similar concepts (Do and Gross 1997). Sketches produced during the design process for the purpose 25

of developing a design in the early stages, i.e. during the conversation a designer holds with himself or herself, are not very formalized. They serve the immediate purposes of the designer’s reasoning process. Lawson (2004a, p. 45) refers to this type of drawing as “proposition drawing”: “The proposition drawing is right at the very centre, the heart of the design process. These are drawings where a designer makes a 'move', or proposes a possible design outcome.” Besides the rather general term “sketch”, a further type of drawing used in the early design stages is often distinguished: the diagram. The following Section introduces diagrams as formalized sketches and conceptual design tools and discusses several views on the notion of the diagram.

2.2.4 Diagrams When engaged in conceptual design during the early design stages, designers produce sketches as well as diagrams, a particular form of sketches. While the distinction between sketches and diagrams remains blurry, some key aspects of diagrams may be singled out:

o

they express complex things in simple terms

o

they are abstracted forms of representation

o

they indicate relationships between elements

o

they require interpretation

Similarly to sketches, diagrams in architecture are used in two basic functions: to communicate with others, and to aid the designer during the design process. A famous example for a diagram for communication is the London Underground Map (Lawson 1997, p. 251). It presents an abstracted map of the connections between underground stations rather than a map of geographical locations. Dogan and Nersessian (2002) distinguish diagram use in domains that are well-defined or ill-defined. In fields concerned primarily with well-defined problems, diagrams indicate causal or temporal relationships between elements of the diagram. They are used primarily for their economy of means to convey complex information visually: “In science there is a primary type of representational diagram, engineered to clarify, symbolise and signify function” (Phillips 2006, p. 69). This type of diagram may be described as representational diagram: it is designed to “visually represent factual knowledge” (Kamps 1999) and is intended to be interpreted relationally, visually, geometrically and topologically. In science, a great variety of canonical diagram types have been developed, each adapted to a specific area of inquiry. Famous examples include the DNA double helix pattern developed by Crick, the Lorenz attractor and meiosis diagrams, or the more generic graph and tree diagrams, mind maps and flow charts. In the

26

following paragraph, Venn diagrams are briefly discussed as an example that relates to the outcomes of this study (see also Section 5.5). Venn diagrams were introduced by John Venn, a mathematician and philosopher, in 1881. Venn diagrams use two or more overlapping circles to study the similarities and differences of sets of items (Venn 1880). Although Venn diagrams were originally intended to be used as a means to organise mathematical sets and logical relationships, this type of diagram has been adapted to other fields of inquiry as well. It is commonly used in the classroom to help students when comparing and contrasting two items by providing visual modes of understanding (Whitin and Whitin 2000). Spheres are typically given labels for general characteristics, and shared characteristics are listed in the overlapping area between the circles (for a detailed discussion of Venn diagrams, see Edwards 2004 and Stewart 1992, p. 51-64). Venn diagrams relate closely to Euler diagrams, Johnston diagrams and Spider diagrams, which all present variations on similar modes of graphic representation. Venn diagrams may however also be used in other interpretations: Phillips (2006, p. 68) contrasts the classic Venn diagram with adaptations of Venn diagrams in design. Figure 5 below shows the basic analytic Venn diagram to the left-hand side. The middle diagram shows Reima Pietilä’s interpretation of a Venn diagram, defining the intersection of two circles architecturally as “ambitious boundary zone” or “sacred area subject to taboo”. The righthand diagram illustrates a Venn diagram as used by theatre designers to analyse the orchestra as a territory that links audience to stage.

Figure 5: Venn diagrams (after Phillips 2006)

In architecture, an ill-defined problem domain, conceptual diagrams are used to both represent and generate ideas. Such diagrams are characterized by their abstraction level and can also be found in the domain of scientific discovery. In architecture, conceptual diagrams encapsulate the generic characteristics and constraints of a design solution and indicate possible specific solutions. Dogan and Nersessian (2002) emphasize that abstraction in conceptual diagrams helps to avoid early commitment to a specific solution, thus enabling exploratory reasoning. The power of conceptual diagrams lies in their capability to elicit interpretation. Lawson describes human perception as a process of seeking meaning: “We 27

can apprehend, manipulate and remember images which are meaningful far more easily than those which are not” (1997, p. 251). Conceptual diagrams, through their ambiguity, thus evoke interpretations. While designers often use this quality to drive design processes, such diagrams may also cause confusion when used to communicate with others who interpret them differently. Conceptual diagrams have both constraining and generative capacities. On the one hand, they crystallize ideas in the early stages of design (Suwa and Tversky 1996). On the other hand, they generate ideas through interpretation. Dogan and Nersessian (2002) describe Louis Kahn’s design method as an example, who recommended first developing a conceptual idea and implementing it in different schemes. “The diagram is, therefore, a maeutic and hermeneutic device - a form of intellectual midwifery that brings complex ideas into clear consciousness, through interpretation.” (Phillips 2006, p. 69) Tschumi described the creation of the diagram as “the moment when, instead of you driving the project, the project starts to drive you” (Finch 1996, p. 17). Tschumi’s description illustrates how diagrams can become imbued with an authority that guides the creative process. Dunster (2006, p. 29) echoes this account: “In architecture this is also the point or moment from which the actual construction appears to design itself, to take over the pen, pencil or computer of the architect to make every move compelled, inexorable, inevitable, immanent to the process.” Diagrams are at the same time about architectural problems and their potential solutions, while also implicitly providing evaluation criteria that a design is judged against. While conceptual diagrams tend to be unique, there are also established types of diagrams that are commonly used for both design development and for communication. An example for such a diagram type is the bubble diagram, which represents relationships between architectural functions in a building. Using bubble diagrams, the architect is released from the necessities of the plan to freely manipulate functional relationships that are gradually forming a strategy for planning arrangements. According to Phillips (2006, p. 70), “The bubble diagram can be made quickly, changed constantly, interlaced with text and collaged over images. For the rational architect it is an essential representation for thinking that can also be used as a substitute for sketching.” Conventional bubble diagrams are thus limited to represent relationships and “no other information should be inferred from them” (Lawson 1997, p. 251). Emmons (2006, p. 455) however suggests that bubble diagrams could be understood in a much richer sense when their origin as organic metaphor is taken into account: “Architectural [bubble] diagrams need to be understood as not merely transparent to facts but as creative constructions built upon the organic metaphors of body-building-cosmos that animate architecture as a vital living body.” Figure 6 shows an early bubble diagram drawn by Alison Smithson (Schank Smith 2005, p. 198-199). 28

Figure 6: Alison Smithson, diagram for an “appliance house”: Planning of functions for a prefabricated housing project in the early, conceptual design stages

Pure types of diagrams, such as the bubble and Venn diagrams discussed above, can again become the basis for further design exploration through sketching: “Because architects think through the end of a pencil, the freehand sketch (…) can transform representational diagramming, be it bubble, composite, flow, system (or any other) into a hybrid type which is both symbolic, sequential and operational.” (Phillips 2006, p. 71) Architects are likely to adapt and change diagrams for specific tasks arising from their design processes. Practitioners’ accounts of the way diagrams fit into their practice can therefore vary considerably between individual architects. The following three Sections give an overview of the theory and use of conceptual diagrams in architecture from three different viewpoints: that of theorists (Section 2.2.4.1), that of practitioners (Section 2.2.4.2) and that of CAD tool developers (Section 2.2.4.3).

2.2.4.1. DIAGRAM THEORY Pai (2002) describes a historical process after the First World War that saw the end of the classic portfolio and the emergence of the “discourse of the diagram”. While the classic architectural portfolio of the Beaux Arts tradition centred around images of buildings and a preoccupation with their “types”, the discourse of the diagram provided architects with new possibilities. According to Pai, the diagram propelled essential changes in the relationship of 29

architect and image and the nature of architectural discourse: “The discourse of the diagram is then not just the diagram, but a whole array of concepts, tropes, and modes of representation.” (Pai 2002, p. 199) Diagrams as a form of discourse transcend the realm of paper and lines. “A diagram is therefore not a thing in itself but a description of potential relationships among elements, not only an abstract model of the way things behave in the world but a map of possible worlds.” (Allen 1998, p. 23.16) Allen emphasizes that diagrams are not schemas, types, formal paradigms or other controlling devices, but that their nature is that of place-holders, instructions for action, or descriptions of possible formal configurations. This characteristic of diagrams is also central to Eisenman’s description: Generically, a diagram is a graphic shorthand. Though it is an ideogram, it is not necessarily an abstraction. It is a representation of something in that it is not the thing itself. In this sense, it cannot help but be embodied. It can never be free of value or meaning, even when it attempts to express relationships of formation and their processes. At the same time, a diagram is neither a structure nor an abstraction of structure. While it explains relationships in an architectural object, it is not isomorphic with it. (Eisenman 1999, p. 27)

Due to this generative capacity, diagrams have been characterized as “abstract machines”, as described by Deleuze and Guattari: "The diagrammatic or abstract machine does not function to represent, even something real, but rather constructs a real that is yet to come, a new type of reality." (Deleuze and Guattari 1987, p.142) For Deleuze, diagrams do not have an intrinsic connection with visual representation, but are rather a property of matter, an “intensity” that drives processes of formation and becoming. He uses the term "abstract diagram" (or "virtual multiplicity") referring to topological plans such as the vertebrate body plan, but also the "body plans" of non-organic entities such as clouds or mountains (de Landa 2002). Benjamin describes non-representational diagrams as essential tools for experimentation and research in architecture: “Were a line or diagram to become experimental sites then - excluding the insistence of the pragmatic - they can no longer be representations since they would have given up that determining hold in which identity is determined by a relation to an outside.” (Benjamin 2000, p. 144) Thus, lines and diagrams need the incomplete, which enables continual reworking and opening up of possibilities. Representation can be reintroduced in this context as an effect of the diagram instead of the diagram being taken as representation. Within this discourse, the work of several practitioners has been described as “diagrammatic practice” or “diagram architecture”. The work of van Berkel and Bos, Sejima and MVRDV has in common that they make use of diagrams during their design processes as well as a diagrammatic understanding of architecture. van Berkel and Bos describe their

30

use of a Klein bottle diagram in the design of a public space between traffic networks in the Arnhem project:

As the ultimate outcome of shared, motion-based relations, the Klein bottle is an infrastructural element in two respects: pragmatically and diagrammatically. As a concept, the Klein bottle has come about as a result of studies of shared, interactive, local conditions. As a diagram, the Klein bottle becomes an actor in the interactive process as it begins to evoke new, more specific meanings at, for instance, structural and spatial levels. (van Berkel and Bos 1998, p. 23.22)

The term diagram architecture was coined by Toyo Ito in 1996 to describe a particular quality in the work of Sejima (see Figure 7), who characteristically reduces buildings to a special kind of diagram. "You see a building as essentially the equivalent of the kind of spatial diagram used to describe the daily activities for which the building is intended in abstract form." (Ito 1996, p. 18)

Figure 7: Kazuyo Sejima and Ryue Nishizawa: Park Café, Koga, Japan 1998

Vidler (2000, p. 3) describes Sejima's work as forming a new genre of architectural abstraction that derives buildings of a minimal aesthetic from simple diagrams of function and space. The work of MVRDV, in contrast, relies on various mapping strategies, which results in diagrams derived from data: Neither a map nor a model of an existing geography, this environment is a virtual model of data as if it were geography, inserted into the morphologically transformed structures of cities and regions. Its architects refer to topologies and topographies and prefer to identify what they do as mapping rather than drawing. (Vidler 2000, p. 1)

31

The examples of van Berkel and Bos, Sejima and MVRDV illustrate a rather recent and radical understanding and use of the diagram – or the diagrammatic – that is to a large extent based on theoretical discourse. The following Section illustrates the broad variety of approaches to the diagram that can be found in architectural practice by giving an overview of a range of practitioners’ accounts.

2.2.4.2. PRACTITIONERS’ VIEWS According to Dunster (2006, p. 29), diagrams accompanied the rise of modernist architecture. Initially connected to function and circulation patterns, diagrams lent authority to modernist buildings: "...the diagram has held a privileged place in the development of modern architecture as at once responding to the aesthetics of rationalism and the authority of functionalism." (Vidler 2000, p. 9) After a phase of rigid functionalism, however, architectural diagrams as used in practice today seem to have recovered qualities evident in Le Corbusier’s diagrammatic sketches, which were “…redolent of spatial and aesthetic potential compared with those prepared by the following generation, either in drawn or built form." (Vidler 2000, p. 13) Diagrams are used in a variety of ways in current practice, which is illustrated in the following by referring to a number of architects’ own accounts of their approach to diagrams, assembled in the January 2006 edition of the Architectural Review journal.

Figure 8: Architectural diagrams by Behnisch (left) and Campo Baeza (right)

Behnisch describes diagrams as both explanatory devices that focus on the general idea and as a guiding the design concept through “the battles of implementation and realisation”, as illustrated in the diagram shown in Figure 8 (left). For Sauerbruch, diagrams can serve as communication tools, or as a means to “rationalize our instincts”. Ahrends sees diagrams as essential for the enquiry, exploration and search for meanings and means of understanding. A similar statement is made by Russum, who also describes the iterative and collaborative process of generating a robust concept sketch as “touchstone for the design development”. Similarly, Pali sees the diagram as framework for architectural projects that are bound to

32

become increasingly complex during the design process and need a strong core idea as a guide. Campo Baeza likens the diagram to a seed that already contains within itself the entire project (see Figure 8, right). Gregotti describes his preoccupation with building sections, which he develops as a core diagram from which the “organism” of the building is developed. Ito emphasizes the ambiguous quality of diagrams: “A diagram is located somewhere between a concept and a plan. Or, in other words, it is a visualisation of a concept, still remaining abstract.” The best diagram, according to Maki, is simple “because its power lies in its suggestiveness for broader interpretation.” For Bates, the value of diagrams lies in “the suggestive, implied and interpretive uses to which it was placed in the course of the design and documentation of the project”. Figure 9 below gives example diagrams by Bates (left) and Maki (right). Moussavi and Zaera Polo give the most abstract description of the diagram as “material organisation that prescribes performance”. They mention a three-dimensional diagram of spatial performance as central in the design process for the Yokohama Port Terminal. For Moussavi and Zaera Polo, a diagram does not determine the form of the project: several forms of mediation are necessary to arrive at the final building.

Figure 9: Architectural diagrams by Bates (left) and Maki (right)

The previous paragraphs illustrate the multiple understandings and uses of diagrams in contemporary architecture. Several characteristics can however be singled out: First, most architects mentioned above – with the exception of Moussavi and Zaera Polo – refer to diagrams as hand-drawn, simplified sketches produced early in the design process. Their role is typically either as a means for gaining understanding, as an idea generator or as an explanatory device. Some architects, however, voice critical opinions on the use of diagrams in architecture. Miller, for example, regards diagrams as mere analytic devices, and

33

distinguishes

diagrams

from

concepts:

“Although

buildings

can

be

analysed

diagrammatically, I believe their genesis was one of concept rather than through the exercise of diagram. The diagram can be used to explain a building a posteriori but is not necessarily a tool in its development.” Nield criticizes simplistic diagrams and cautions that “a building is not merely a diagram of use”. Wilson also argues against the diagram as a stringently reductive design tool: “For media-circulated new-millenia projects the role of the diagram is twofold. First, it is prescriptive, proffering a sort of DNA/hieroglyph, which purports to have already solved all contingent issues. In its second role, the same diagram is offered to the observer/critic as a yardstick against which to measure the finished building, a ‘fast-track-packaging’ of architecture, a reduction to the ‘one-liner’ to the ‘headline’.” Buildings, according to Wilson, should be experienced in all their spatial, material and phenomenological qualities on site.

2.2.4.3. COMPUTER-SUPPORTED DIAGRAMS With the introduction of the computer to architecture, attempts have been made to support the early design stages by digital means. The following paragraphs focus on approaches to sketches and diagrams taken by CAD researchers, in particular the approach proposed by Gross and Do (2001). In current design practice, computers are already well-established for computer-aided drafting purposes, but the role of computers in the early design stages is only beginning to be explored (Goldschmidt 2004, p. 215). One of the reasons is that creative thinking in the early design stages thrives on representations that are vague, fluid and ambiguous. Goel (1995) characterizes such representations as non-notational symbol systems, which are different from the well-defined and unambiguous notational symbol systems commonly used in computation. Approaches to this problem mostly aim to support sketching by reproducing or amplifying paper-based sketch-like interfaces with digital means (Koutamanis 2006a, p. 278). In these systems, sketches produced by drawing – either conventionally on paper or on a graphic tablet – may be enriched or augmented with additional annotations or data, and sketches may be categorized and stored within a data base for later retrieval (see for example Landay and Myers 2001, Robinson and Robertson 2001, Ishii et al. 2002). Such techniques are perceived capable to “change the use of the sketch from an essential but discontinuous process, to the status of a readily transmissible resource carrying information forward to further, more accurate representational stages, as part of an evolutionary flow of data.” (Woolley 2004, p. 191) Much effort in CAD research has been done in the area of sketch recognition, which aims to capture drawings for various purposes, for example to generate 3D models, for storage in data repositories, or as a basis for other types of automated response of the computer (see for example Koutamanis 2006a, Bailey 2000, Park and Gero 2000, Leclercq 2001). 34

In this context, Gross and Do have developed the electronic cocktail napkin, a software prototype to support conceptual sketching and diagramming. For this purpose, Gross and Do (1996) have put forward a distinction between diagrams and freehand sketches. Do and Gross (2001) describe diagrams as drawings that aim to capture as well as generate design concepts and guiding principles, while sketches depict physical form. Diagrams employ symbolic representations and focus more on relationships of basic design components than on building shape:

A diagram is made of symbols and is about concepts. It is abstract and propositional: its elements and spatial relations can be expressed as a set of statements. It explores, explains, demonstrates, or clarifies relationships among parts of a whole or it illustrates how something works (a sequence of events, movement, or a process). (Do and Gross 2001, p. 136)

Do and Gross contrast diagrams with sketches, which they characterize mainly in terms of drawing quality and its focus on form: A sketch, in contrast, is about spatial form. It is executed with a finer resolution that indicates attributes of shape. A sketch often comprises repetitive overtraced lines made to explore precise shape, rather than the intentionally abstract shapes of a diagram, and it uses graphic modifiers such as tone and hatching to convey additional information. (…) Although a sketch falls short of precisely determining positions, dimensions, and shapes, it often provides more detailed information than a diagram. (Do and Gross 2001, p. 137)

A similar distinction of sketches is proposed by Koutamanis (2006a, p. 281), who differentiates “representational” and “diagrammatic” sketches. Building on this distinction, the electronic cocktail napkin supports both informal freehand drawings made during conceptual design and the editing and managing of diagrams and drawings. Based on two empirical studies, Do (1995) proposed that elements of a graphic vocabulary are associated with specific design concerns, which results in a conventionalized set of graphic symbols that are employed in diagram design: "Our empirical studies showed that designers share a universe of conventional symbols and configurations when thinking about different design concerns. Therefore we can program a computer to recognize these conventions and use them to infer design context and intentions." (Do 1997) Do and Gross (2001, p. 146) propose the following criteria as guidelines for the design of a computer tool to support designers in thinking with diagrams:

o

Freehand drawing input, as opposed to structured diagram entry and editing. 35

o

Maintaining spatial relations among elements as the diagram is transformed.

o

Recognizing ‘emergent’ patterns and configurations in a diagram.

o

Performing transformations that carry one diagram to another.

o

Identifying similarities and differences among diagrams.

o

Representing designs at varying levels of abstraction and detail.

The definition of diagrams proposed by Gross and Do - "A diagram differs from a sketch in that it contains symbols." (Do 1995, p. 470) - seems to be primarily aimed at allowing computers to recognize and store graphic representations in databases. For similar reasons, Dave (1993) proposed simplified, graph-based notations as a basis for incremental problem re-structuring over the course of the architectural design process. Dave (1993) proposes that basic, “diagrammatic” notations could be associated with domain relevant interpretation to become meaningful (ibid., p. 94). Gross and Do (1996, p. 183) however admit that the distinction between sketches and diagrams is rather blurry in practice. Pillips (2006, p. 70) describes that one type of representation may be transformed into the other during the design process. Overall, the classification of symbols contained in architectural diagrams for recognition purposes, or the provision of “intention recognizers” based on drawing content as proposed by Do (2005, p. 403) seems to relate more to conventionalized functionalist diagrams than the ambiguous exploratory diagrams that elicit individual interpretations as described in Sections 2.2.4.2 and 2.2.4.3.

2.2.5 Summary Design aids for architectural design typically provide designers with some form of representation. Architects make use of different types of representations depending on the stage of the design process. Representations may be goal- or output-oriented, such as presentation models or working drawings, or they may be used to support the creative reasoning process. During the early design stages, architects typically use freehand sketching. Sketching facilitates the reflective conversation designers are engaged in when developing ideas (Schön 1983, see also Section 2.1.3). Diagrams are a particular form of sketches that is commonly employed for communication and explanation purposes as well as in the development of architectural concepts. While functional diagrams employ a conventionalized set of graphic elements, conceptual diagrams can take a variety of shapes. Conceptual diagrams are typically ambiguous and are capable of generating multiple interpretations while still remaining rather simple and abstract. As such, they form an essential source of inspiration and creative idea development in the early design stages. Gross and Do (2001) have proposed an approach to using computers to support diagrams in

36

architectural design which aims to enable the computer to recognize, interpret and store diagrams. This thesis develops an approach to CA to support the early design stages by drawing on previous research on the role of sketches and diagrams in the conceptual design phase.

2.3 Computers as design support CA are one of a variety of generative design approaches, which aim to use computers to support design processes beyond providing a digital drawing board. Following a review and discussion of design process models and sketches and diagrams as conventional design support, this section briefly reviews approaches to employ computers as design support. It then concentrates on generative design and discusses conventional CA as well as applications of CA to generative architectural design. As a generic tool, computers have found a variety of roles in the field of architecture. In 1975, Negroponte characterized architects’ interest in computers as looking to “achieve the automation of what at the onset is assumed not to be Architecture, with a capital A, but the associated baggage.” (Negroponte 1975a, p. 4) Early Computer-aided design (CAD) researchers envisioned the computer in the role of a designer: based on the supplied data, it would generate design solutions (Lawson 1997, p 287). Recounting the changing focus of his research on computers in design, Cross (2001) describes his early vision presented in Cross (1977): “This vision of the intelligent computer was based on an assumption that a machine can design – that it can be programmed to do a lot of the design work, but under the supervision of a human designer.” Negroponte (1970, Negroponte and Groisser 1970) deemed it necessary that computers should “understand” design to cope with context dependency and missing information, two characteristics of architecture. This role of the computer in design has been recast as more has been learned about the nature of the design process and the limitations of computers. Cross (2001) cautions that machines should not necessarily take over everything human beings do, and proposes research on computers as design machines and computational models of design activity as a way of investigating human design behaviour. Today, computers are ubiquitous in architectural practices. They are typically used to support well-defined tasks, for example in communication and collaboration, drafting, data management, or for simulation and testing purposes (Steele 2001). Computers have facilitated the design, manufacturing and building of new types of forms, such as Gehry’s Guggenheim museum in Bilbao, Spain. The use of computers in creative design – as “real design tools” (Lawson 1997, p. 287) – is however still rather limited. Gehry, as many others who rely on computers to present, manage and build architectural projects, uses

37

conventional sketches and models during the early design stages (see Section 2.2.3, figure 4). What, then, would constitute the nature of “real design tools”? Exploring the question of whether computers can be creative, Boden (2004, pp. 3-6) proposes that creativity can appear in three different forms: 1) it can involve making unfamiliar combinations of familiar ideas, found for example in poetic imagery, collage, analogies. 2) Creativity can mean the exploration of an established thinking style or conceptual space to come up with a new idea – Boden (ibid.) compares this type of creativity to finding a new way by reading a map. 3) Transformational creativity is used to transform conceptual spaces and involves the changing of underlying concepts and rules. While computers have been applied to combinatorial and exploratory creativity tasks, their use in transformational types of creativity remains limited (Boden 2004, p. 305). Lawson (1997) proposes three potential tasks of the computer in the design process, describing computers not as replacements for human designers, but rather as a responsive medium that acts similar to a colleague. Computers may generate design solutions based on data supplied by the designer, who selects and evaluates proposals. Computers may also be used to evaluate proposals made by the designer by providing data on cost, lighting, circulation, etc. Computers may further provide expert help based on large databases of expert knowledge. This study explores CA to support the conceptual design process. To this end, it draws on the capability of computers to provide rule-based processes that generate forms. Instead of proposing full design solutions, however, the aim of this study is to use CA-based generative processes to support the early design stages by actively providing feedback for designers involved in conceptual design. To provide a background on generative design, the following sections briefly introduce generative design approaches, with more detailed sections focusing on CA and previous applications of CA to the field of architectural design. These applications are examined with regard to the nature of the conceptual design process identified in earlier sections.

2.3.1 Generative Design CA are one of a variety of generative design approaches. Generative design approaches aim to utilise the computer not merely as a substitute for the conventional drawing board, but also as support and source of inspiration in the early, conceptual design stages. Generative design approaches have emerged from the search for strategies to facilitate the exploration of alternative solutions in design, using computers as variance-producing engines to navigate large solution spaces and to achieve unexpected but viable solutions (Negroponte 1970). In generative design, algorithmic procedures are often used to produce arrays of alternative solutions based on predefined goals and constraints, which the designer then

38

evaluates to select the most appropriate or interesting. A variety of strategies to generate variety have been developed, which often rely on techniques adapted from other fields. They include algorithmic growth, artificial life, fractal images, emergent behaviour, genetic algorithms, cellular automata, shape grammars etc. (Fischer and Herr 2001). One strength of the computer as a generative design tool stems from its capability to perform tasks that rely on numerically formalised dimensional or relational constraints. Computer-supported generative design processes can feature different levels of automation and manual user intervention respectively. Generative design processes are often implemented as completely automated systems: "Most generative systems aim at a complete spatial design (detailing being an unpopular subject), with minimal if any intervention by the human designer." (Koutamanis 2001) To achieve this, the computer needs to be equipped with a complete and unambiguous understanding of the design task (ibid.). Approaches to generative design in this context have thus frequently focused on space allocation systems (Eastman 1975) or shape grammars (Stiny 1975, 1980, Stiny and Mitchell 1978, Mitchell 1990, Hersey and Freedman 1992). Steadman (1976, 1983, 2006) has put forward a framework for architectural shape that is based on rectangular arrangements. Rectangular arrangements are rectangular patterns that are produced by recursive application of dissection rules. In this way, exhaustive catalogues of all topologically distinct arrangements can be generated for planning, optimisation and analysis purposes. Steadman (2006) grounds his emphasis of rectangular cells and their arrangements on the economically motivated prevalence of such patterns in both vernacular and contemporary built form. His work has however been criticised for its overemphasis of twodimensional mathematical reasoning (Burry 2006), his simplification of shapes as found in vernacular building fabric to support his reasoning and his ignorance of cultural and artistic values that lie at the heart of architectural creativity (Blundell Jones 2006). The discussion of Steadman’s views clearly illustrates the contrast between a formal, abstracted and pragmatic view on architectural design and a humanist perspective that sees buildings as special cases embedded in a unique context. Early attempts at developing fully automated generative design systems are based primarily on the former, whereas more recent developments in generative design increasingly acknowledge that not all design knowledge can be made explicit to allow the complete automation of design processes. Fully automated generative design processes rely heavily on formalisable evaluation methods to distinguish appropriate solutions from others automatically in order to produce meaningful results in their respective design contexts (Stiny and March 1981). Seeking to automate the process of evaluation, evolutionary approaches to design have introduced evaluation mechanisms that test potential solutions for validity without the need for a designer’s judgement during the design process. In fully automated generative design 39

systems, the designer usually interacts with the system by initially defining constraining relationships and setting relevant variables, typically by means of computer programming. After the generative process is completed, the designer decides on whether to accept the outcome or to repeat the process with modified initial settings. Other generative processes, however, are more responsive. As an early model for responsive, automated architecture, Negroponte presented SEEK in 1970 (Negroponte 1975, p. 46-47, see figure 10, left). SEEK was a machine-controlled environment of stacked cubes, populated by a colony of gerbils. The system adapted cube locations to changes initiated by the gerbils, which would constantly create new configurations through their activity. Recent approaches to shape grammars often involve the designer to make choices at certain stages in otherwise ruledriven processes (Chase 1998). Based on a set of rules derived from the architecture of Siza, Duarte (2004, see figure 10, left) has proposed an interactive design system that combines a discursive grammar and user input to generate buildings in the architectural style of Siza.

Figure 10: Gerbils in SEEK, Malagueira grammar by Duarte

In such systems, human designers are typically required to make design decisions that require more holistic, context-based understanding and judgement (Cross 1977). In evolutionary design approaches, the design process is organised as cyclic process that generates increasingly appropriate solutions by way of repeated selection at every design cycle (Frazer 1995). This selection may be made manually by a designer or by automated evaluation mechanisms. Even more flexible is the approach to generative computing described by Yakeley (2000), who suggests that computers could take the place of conventional pencil sketches: “…in the context of the design conversation, (…) there is potential for a more equal dialogue if the pencil sketches were replaced with a medium that might offer suggestions to the designer's ideas.” (Yakeley, p. 39) Yakeley argues that instead of taking the conventional role of an electronic pencil, or a repository of data and information, the computer could become “an electronic partner able to contribute to the conversation of design, and to become an active voice of 'back talk'.” (ibid.)

40

While earlier approaches to generative design focused on “combinatorial creativity” or the exploration of predefined search spaces (Boden 2004, p. 3, see also Section 2.3), recent approaches to generative design increasingly aim at aiding in what Boden (2004) describes as “transformational creativity”. This type of creativity is typically encountered in the conceptual design stage and usually accompanied by sketching or diagramming. Transformational creativity emphasizes exploration and discovery, typically leading to unanticipated results that allow the re-conceptualisation of the initial design task. To enable transformational creativity, generative design approaches are needed that are less bound to variations of initially predefined parameters. Koutamanis (2001) suggests to focus more on the “augmentation of intuitive creative capabilities with computational extensions” to support design exploration (Koutamanis 2001). Strategies to support conceptual design processes with generative approaches include the combination of different generative approaches, the integration of computer-based processes and human feedback, the recognition of “lucky accidents” as valuable design contribution, and the use of ambiguity to provide a platform for multiple interpretations. Describing the generative rationale underlying the work of Frazer, Chu, Spuybroek, Eisenman and other practitioners, Steele (2001, p. 136) characterizes this approach as “letting the computer lead”. The aim of this approach is to utilize the computer to initiate processes that lead to unanticipated results and inspire the design process, and thus contribute to concept development. De Landa states that in this new role, architects wishing to “breed buildings inside the computer” must “become hackers” to build and adapt the necessary tools (De Landa 2002).

2.3.2 Cellular Automata The use of generative approaches in design is motivated in part by the need to manage and express increasing complexity of often interrelated factors that determine the design processes. In designing contemporary urban environments, a multitude of requirements and constraints have to be observed, that can often overwhelm designers (Negroponte 1970). In this context, CA have received attention from architects and urban planners as a generative strategy that is characterized by the simplicity of its mechanisms on one hand and the potential complexity of its outcomes on the other. Driven by local communication between cells over time, behaviour in CA is based on often strikingly simple rules executed in parallel by cells arranged within larger grids. CA were originally developed by the mathematicians Ulam and von Neumann in the late 1940s. While Ulam initially used CA to study "games of chance" (Ulam 1952, Schrandt and Ulam 1970), von Neumann (1966) employed the concept in his work on self-reproducing automata. Conventional CA systems have been described in Burks (1970), Toffoli and Margolus (1987), Wolfram (1984) or

41

recently in Ilachinsky (2001). The ‘Game of Life’ CA implementation developed by Conway and first introduced by Gardner (1970) popularised CA, as it offers visual insight into the complex behaviours resulting from simple transition rules and a limited number of states. With cells relying on one-, two- or three-dimensional neighbourhood grids of squares or cubes to determine their states, CA are inherently spatial, context-sensitive systems. Despite the simplicity of rules and neighbourhood relationships typically found in CA systems, they produce intricate patterns that are difficult to predict. Due to this property, CA have become a computational paradigm of choice in much laboratory research interested in patterns with such characteristics, and have been applied to a wide range of fields to study complex phenomena, ranging from cryptography to traffic simulation and biological modelling. Conventional CA are usually based on Ulam’s (1952) initial model. Such systems feature discrete (non-continuous) notions of time and space in combination with simple transition rules and limited numbers of states. Cells are stationary and have constant neighbourhoods. During the early stages of CA work, however, von Neumann had also proposed an alternative variant: He developed two cellular systems with the capacity to selfreplicate, which Burks (1970, pp. 4ff) refers to as the "kinematic automaton system" and the "cellular automaton system". The kinematic automaton system consists of idealised robotic units, capable of moving and attaching to each other in a space filled with other mobile cells of similar kinds. Systems of this type, although closely related to CA in the early stages of their development, are not considered as CA today and are usually referred to as "swarm" models (Coates and Miranda 2000). Von Neuman's cellular automaton system follows the design porposed by Ulam. It consists of stationary logic-processing cells within fixed grids and forms the basis for the design of conventional cellular automata systems today. At their reduced abstraction level, conventional CA oftentimes fail to satisfy experimenters in terms of their capacity to model more differentiated phenomena. To deal with this issue, a number of modifications and extensions are available to better fit the nature of more concrete problems and situations. Such applications of conventional CA to particular fields of study have typically produced adapted or extended CA models. Extensions to conventional CA models include not only a greater variety of transition rules but also alternative state transition models, for example stochastic or majority models. Cell neighbourhoods may become extended ‘interaction neighbourhoods’ (Hengselmann 1996) that can be more extensive than the classic neighbourhoods comprised of 4 or 8 direct neighbours.

42

Figure 11: CA-based simulation of the development of the Chicago region from 1850 to 2000

Numerous CA applications have been developed in the fields of urban planning and geography, which have typically focused on capturing the dynamic and non-linear properties of urban growth processes (Batty and Xie 1994, Couclelis 1997, Batty and Torrens 2001). Figure 11 illustrates a sequence of steps in a CA-based simulation of the urban growth process of the Chicago region (Batty and Torrens 2001, p. 31). Next to modelling and simulating urban growth, CA models have been used to evaluate the consequences of planning scenarios (Yeh and Li 2002). Such models are usually based on previous observations of growth processes and combine traditional statistic models with CA to capture process characteristics related to spatial relationships (Itami 1994). These models differ from to conventional CA in that they are typically adapted to particular situations by defining specific transition rules, a larger number of possible states - usually describing types of land use - or different definitions of local and global neighbourhoods. CA applications are increasingly concerned with empirical applications rather than theoretical explorations (Torrens and O’Sullivan 2001), which has resulted in further extensions of these models. Cells that are able to change their position in model space as well as their transition rules are of particular interest in studies of pedestrian or motor traffic behaviour. For this purpose, cells may also be able to remember their history and to refer to past events in their decision making. While a large number of attempts have been targeted at extending the discrete notion of time in classic CA models, neighbourhood relationships and over-simplified transition rules, only few researchers have investigated spatial models different from classical grid lattices. For some tasks, CA models may be combined with other spatial modelling techniques into hybrid concepts. In this context, O’Sullivan (2000, 2001a, 2001b) has explored graph automata, a combination of CA and graph theory, to approach a more 43

natural variety of spatial relationships. Figure 12 illustrates variations of CA-based models as responses to the representational problems of conventional CA proposed by O’Sullivan (2000, p. 7).

Figure 12: Variations of conventional urban CA-based model variations (ovals) as responses to the representational problems of strict CA (rectangles)

O’Sullivan’s hybrid model combines the continuous and repetitive nature of space found in classical CA with a representation of space that focuses on relational frameworks containing objects characteristic in graph models. Graph-based CA representations of space are heterogeneous, comprising a variety of object types and sizes. Thus introducing irregularity into CA models, results from this type of CA have been shown to describe networks of spatial relationships more effectively than traditional space-filling volumetric models at high resolution. A similarly flexible approach to CA-based modelling is adapted in the context of this thesis and described in detail in Chapter 4.

2.3.3 Cellular Automata in Architecture The first architectural design project to bring together a generic understanding of useable space and microcontroller-enhanced building elements is Cedric Price’s Generator project (Hardingham 2003). Price approaches architectural space much like a CA system, using volumetric units controlled by both the building’s users and by a central computer. The essential difference between most CA experiments in generative architecture and Price’s 44

Generator Project is that CA are usually employed to explore possible variations during the design stage and before planned structures take physical shapes. Price’s Generator Project was instead designed to show actual variation of its physical form during the time of its use. As generative design support, CA are seen as “pattern generators” that allow the exploration of formal composition techniques (Chase 2005, p. 692). CA are typically used in the form of volumetric models that transcend traditional types of models in that individual volumetric units are capable of changing their properties according to predefined rules. Though CA are based on deterministic rules, the complexity of local interactions between cells produces outcomes that are seemingly non-deterministic and difficult to predict. Representing a standard approach for experimentation in generative design (Bentley and Corne 2002), CA have been used mainly to explore variations of possible solutions resulting from the tempo-spatial development of initial setups over time (see for example König and Bauriedel 2005, figure 13). Design constraints are typically implemented in a bottom-up manner in form of simple rules that govern the local behaviour of each cell. The overall outcome of a CA system, however, is often complex and difficult to predict from these rules. The inter-dependencies of neighbouring cell states, however, provide localized evaluation mechanisms. This characteristic supports local instead of global control models, and has been presented as potential for further developing generative architectural design (Koutamanis 2003).

Figure 13: König and Bauriedel’s CA-based urban design process

As a generative design strategy, CA are typically chosen for tasks that involve simple constraints operating on large numbers of elements, where differentiation and variety are sought (Watanabe 2002). CA systems developed for design or planning purposes are usually implemented as fully automated generative systems. After initial variables are set, the CA process is run without a designer’s interaction for either a specified time or until a desired situation has been reached, as for example in the experiments by Krawczyk (2002), Anzalone and Clarke (2003, 2004) and König and Bauriedel (2005). Without the feedback of a designer during run-time, however, self-sufficient CA tools are unlikely to produce desirable, practically useful architectural designs. While CA have been explored in the context of architecture, previous applications tended to use existing systems like John H. 45

Conway’s Game of Life (Gardner 1970, see also Section 2.3.2), as in the case of Krawczyk (2002), who experiments with CA rule sets and interprets complex spatial results as architectural form (figure 14, right).

Figure 14: Applications of CA to architectural design by Coates, Watanabe and Krawczyk

A strong interest in form derived from function alone is expressed by Coates et al. (1996, see also figure 14, left), who see their experiments with CA in architecture as the expression of an aesthetic of pure function. Extending Price’s generic view of space evident in the Generator project to architectural form in general, Frazer (1995), who had previously been involved with Price’s

Generator Project (Hardingham 2003) as a consultant, and his

students at the Architectural Association built the Universal Constructor articulating a view of architecture as “logic in space” (Frazer 1995, p. 45). The system is implemented as a hardware CA system controlled by a host computer that functions also as a human-computer interface. Neither the electronic circuitry nor the cubic geometry of the Universal Constructor’s modelling units are designed to directly correspond to architectural concepts other than tempo-spatial logic states. As a generic system, applications of the Universal Constructor depend largely on interpreting software used in given applications, which maps cubes, their location, their 256 states and neighbouring relationships to built form. Frazer (1995) emphasises the difference between conventional CAD, generative “form generators” and his approach: Both the datastructures and the user interfaces of CAD systems are designed to develop the geometry of form rather than the geometry of relationships. At the ‘Computer-Aided Architectural Design Futures Conference’ in Eindhoven in 1987 we introduced the concept of ‘plastic’ or ‘soft’ modelling in contrast to the rigid implications of solid modelling. The idea was to solicit from the user information of a higher order about the relationships between the elements. Ultimately, we proposed a set of powerful ‘relational operators’ to encourage the user to specify logical relationships between elements rather than specific geometric coordinates. (Frazer 1995, p. 32)

46

Though focused on form, a number of researchers have extended their CA systems when looking for greater differentiation than that achievable with classical two-state automata. In their experiments, Coates et al. (1996) have also increased the number of possible cell states and emphasize the role of environments and feedback in providing opportunities to develop greater diversity in CA models. In addition, Coates et al. (1996) have explored mapping strategies that allow the generation of continuous surfaces based on the dynamics of a CA model. Anzalone and Clarke (2003, 2004) use CA systems to manage the complex interrelations between the elements of a building system and rely on “formal interpreters” (Anzalone and Clarke 2004, p. 155-156) as additional mapping strategies to derive form. Krawczyk (2002) deals with the problem of functional requirements by adopting enlarged cells to create contiguous areas in floor plans, by overlapping and altering shape edges into curves and by providing vertical supports for cantilevered elements. Post-rationalisation measures of this kind demonstrate that a number of basic premises of classical CA systems may be changed in order to produce meaningful architectural form. While it is possible to use uniform, space-filling grids of cellular units (voxels) at high densities to approximate form, Mitchell (1990) states that this is rarely useful in architectural design. This strategy can result in the CA system being used to generate form according to only few constraints regarding a particular architectural scale, and requires subsequent manual changes to respond to additional design constraints. This conflict is clearly visible in Watanabe’s (2002) ‘sun god city I’ design (see figure 14, middle), where units of a cellular automata system are arranged according to lighting criteria but many cells lack vertical support as would be required if the model is used for architectural purposes. Testa et al. (2001) proposed a more flexible approach to support bottom-up architectural experimentation, in which architectural elements are capable of agency. In different types of set-ups, Testa et al. (2001) have explored the consequences of local interaction of building elements, which results in potentially surprising results similar to the applications of CA to architectural design described above: “The ‘running of the system’ consists of designating components, defining their agency in local terms, and then tracking the macroscopic outcome of their interaction.” (Testa et al., p. 483) While being based on an understanding of generative computer support as essentially a form of simulation similar to CA-based urban planning tools, Testa et al. features graphic representations of varying abstraction as well as varying types of feedback and manual intervention or feedback by the designer.

47

2.3.4 Summary Computers have become ubiquitous in architectural practices today (Lawson 1997). They are mainly used for computer-aided drafting, but also for communication and collaboration, data management, or for simulation and testing purposes. In the early, conceptual design stages, however, computers are still rarely used (Goldschmidt 2004, Parthenios 2005). Generative design approaches aim at supporting creative design processes, typically by generating a variety of proposals based on initially supplied data, which the designer then selects from. In architectural design, CA are recognized as a generative design strategy that allows the implementation of design constraints in form of simple rules that govern local cell behaviours. While based on simple rules, overall outcomes of CA systems are often complex and difficult to predict. CA have been applied in a variety of fields, including biology, physics and urban planning. In these fields, CA are well-established tools that are used mostly for simulation purposes. Conventional CA systems have however been expanded and adapted to suit the specific purposes in each particular field of study. In architecture, CA have been used by a number of researchers and practitioners, who typically used CA-based software to generate architectural form (see for example Coates et al. 1996, Watanabe 2001 and Krawczyk 2003). These approaches are mostly based on CA models adopted from other fields of study, and are usually implemented as fully automated systems that do not allow for user feedback or modifications during run-time. Overall, previous approaches to CA as architectural design support do not follow a coherent framework. Applications of CA to architectural design typically remain limited to the formal aspect of design and the scope of particular projects.

2.4 Summary and the research problem In the field of generative design, a number of attempts have been made to use CA as design support in the conceptual stage of the design process. These approaches are typically based on CA models adapted from other fields of study, which employ CA predominantly not as generative design support but as simulation mechanisms, such as the examples from the area of urban planning discussed in Section 2.3.2. In these examples, CA are used as they offer ways to employ simple rules to cope with quantifiable constraints in dynamic, bottom-up processes such as urban growth patterns. As transition rules operate according to local cell neighbourhoods, CA can also handle complex geometrical relationships that would be difficult to simulate with other means. Previous applications of CA to the field of architectural design have considered CA mainly in isolation from related fields of study that focus on creative design support. As a result, previous research on CA as architectural design support has tended to adopt conventional CA models from other fields of study with 48

little adaptation to architectural design. Consequently, such approaches have tended to focus on developing an abstract and reductionist notion of architecture compatible with abstract mathematical models, as shown in the examples discussed in Section 2.3.3. In other fields, however, CA models have often been adapted for specific purposes. The resulting CA models diverge from conventional CA in order to describe their context of application in less abstract ways. Similar adaptations may benefit CA models intended to support architectural design. Previous approaches to CA are often implemented as fully automated generative systems that do not allow designers to interfere during the generative process. The focus tends to be on the generation of patterns which are subsequently interpreted as building form. Furthermore, existing work in the field has typically been limited to the scope of single projects, and no theoretical framework has been established yet. This thesis aims to apply CA in the context of early, conceptual design, where CA may play a different role than in previous work. To explore the application of CA to the conceptual design process, this thesis relates CA to research on the nature of the conceptual design process as well as research on the nature of sketches and diagrams, design representations typically used in the early stages of the design process. Rather than the sequential progression through particular phases, as proposed in linear and rational models of the design process examined in Section 2.1.1, more recent research has characterized the design process as cyclical and reflexive in nature. Schön’s (1983) model of the design process describes the design process as “reflection in action”. In particular during the early design stages, when initial concepts are developed, designers engage in a conversation with the situation that is based on repeated cycles of design “moves”, changes initiated by the designer, and a subsequent evaluation and reflection of these changes. The “reflective conversation with the situation” described by Schön (1983) is facilitated by visual representations. Such representations are characteristically vague and ambiguous to some extent and provide not only a memory aid, but also encourage visual discovery through interpretation. In architectural design, sketches and diagrams are typical examples for this type of representation. While frequent feedback loops between designer and representation are central to the conceptual design stages, current approaches to CA as architectural design support tend to be implemented as fully automated systems that do not permit the designer to interact with the system during run-time. As such, CA-based generative design systems are limited to produce a variety of design proposals within the predefined limits of the software. As a result, the process of working with a CA-based generative system is rather different from engaging in the open-ended cyclical design process characteristic of conceptual design processes. This study aims to address this disparity by exploring ways to apply CA as generative design support during the conceptual design stages. 49

2.4.1 Research problem To apply CA as generative design support during the conceptual design stages, this thesis considers extensions and modifications of conventional CA models, as they are common in other fields of study to adapt CA systems to domain-specific tasks. This study further relates CA to the early stages of the design process as described by Schön (1983). CA are employed to provide computer-based representations to support conceptual design, which are different from conventional representations such as sketches in that they offer rule-based processes and basic numeric evaluation functions. The design process model proposed by Schön (1983) is extended to include CA-based design support as part of the design “move”. In this extended model, CA support is offered in form of optional, small-scale steps to an otherwise conventional design process. This avoids the problems connected with the rigidity of fully automated generative systems, which tend to restrict designers to merely setting initial parameters and do not allow much intervention during the generative process. The approach to CA proposed in this study gives the designer opportunities to intervene and direct the design process, which is intended to accommodate rules as used by designers, which have been characterized as largely implicit, diverse, contextually dependent and subject to exceptions and modifications by the designer (Schön 1988).

2.4.2 Research questions Based on the research problem outlined above, the main research question of this study is:

How can CA support the conceptual stages of the architectural design process?

From this general question, two sub-questions can be derived that reflect the aim of this thesis to develop an extended CA model for architectural design purposes:

1) How can conventional CA models be adapted to architectural design? 2) In what ways would such adapted CA fit into the conceptual design process?

Based on the literature review, a proposition is developed as a preliminary answer to the research questions above.

Proposition and preliminary extended CA model: To support the conceptual stages of the architectural design process, conventional CA need to be modified. These modifications constitute a new, extended CA model and a generative design approach tailored to support conceptual architectural design processes. The 50

preliminary extended CA model is outlined in detail in Chapter 4 and serves as a starting point for the action research cycles documented in Chapter 5. It addresses two aspects:

1) Modifications to conventional CA models required for modelling architectural forms and contexts. 2) An extension of Schön’s model of the design process that integrates CA as optional design “moves” within a cyclical, reflective conceptual design process.

51

Chapter 3. Research Methodology This chapter outlines the research approach taken in this study. Based on the initial proposition, a preliminary extended CA model for conceptual architectural design support was developed, which is outlined in detail in Chapter 4. This Chapter describes the method of inquiry adopted to accommodate a sequence of applied tests that served to explore and further develop the initial CA model. As these tests involved software development as well as design applications by architecture students in workshop or studio settings, action research was chosen as a research methodology that accommodates the applied nature of design. Action research pursues action (change) and research (understanding) at the same time (Dick 1999), with understanding increasing through a cyclical process of action and reflection. This chapter introduces action research in the context of research methods in design in Section 3.1, and gives an account of action research in the context of this study in Section 3.2. Section 3.3 gives an overview of the five action research cycles of this study and outlines methodological choices made in each software implementation in detail. Section 3.4 discusses qualitative and quantitative data collection methods as they were employed over the course of this study. Appendix 1 gives a further brief comparison of qualitative research methods considered for application in this study.

52

3.1 Action research and research methods in design Research methods in the field of architecture vary considerably depending on the particular aspect of architecture under investigation, and range from scientific methods used in areas such as building physics and construction to qualitative methods of inquiry common in areas such as housing research or history. The nature of design related research, however, remains subject to an ongoing debate: Groat and Wang (2002), reviewing diverse research methods available to researchers in architecture, clearly distinguish research from applied design. Laurel (2003) emphasizes the synergy of both domains, while Downton (2003) argues that design can be a form of research and refers to the description put forward by Archer (1981) and Frayling (1993) of three areas of investigation: “research for design”, “research about design” and “research through design”. In Downton’s view (2003), the process of designing can be regarded as form of investigation that produces individual knowing as well as shareable knowledge and thus qualifies as research. Glanville (1999) even holds that scientific research is a restricted form of design. The positions outlined above indicate the importance of both design and research in the field of architecture as well as their complementary nature. In the context of architectural design, is widely agreed that design research is difficult to contain for empirical research purposes (Lawson 1997, p. 39) and may require flexible modes of investigation. This study takes a mixed methods approach (Creswell 2003) as it combines an initial proposition developed from a literature review with an explorative action research process. The aim of this study is to explore how CA – an established method of investigation in scientific fields of inquiry such as mathematics or biology – can support the conceptual architectural design process. Based on a review of previous work in the field, a preliminary extended CA model for this purpose was developed, which is outlined in detail in Chapter 4. The testing and further development of this initial model required applied design, which in the context of this study is understood as the process of developing software implementations based on initial assumptions, and applying them in architectural design processes. Results from five such software implementations were used throughout this study to inform further development of the initially proposed extended CA model and subsequent software implementations. This iterative research process is primarily qualitative in nature, with both research questions and the type of collected data subject to changes from one software implementation to the next. Moreover, the nature of results in this type of designbased research process is open-ended, as design processes cannot easily be predicted. For this reason, this study focused primarily on collecting qualitative data, as quantitative data collection focuses on data of a predefined nature. The purpose of this applied phase of 53

research was to allow for open-ended development of initial assumptions to capture unexpected results as they are commonly found in design processes. Data collection methods however changed over the course of the five software implementations this study and are discussed in further detail in Section 3.4. In order to choose a method of inquiry for this study, the following criteria were initially identified as essential characteristics: The research method should allow for an actively involved researcher and be flexible enough to accommodate various modes of action. It should furthermore accommodate unexpected results as well as changing or emergent variables during the research process. Finally, it should allow for the research process to be based on initial assumptions. According to these criteria, action research was found to be the research method most appropriate to this study. A more detailed discussion of three research methods initially considered for the purpose of this study – action research, applied ethnography and grounded theory - is outlined in Appendix 1. Groat and Wang (2002, p. 111) characterize action research as construction of knowledge through the process of change, with a focus on developing practical results through improving specific situations. While not the same (McMahon 1999), action research is closely related to Schön’s (1983, see also Section 2.1.3) approach to reflective practice, who grounds his approach to an epistemology of practice on a close examination of practitioners, including architects. Schön (1983, p. ix) argues that reflection-in-action “is susceptible to a kind of rigor that is both like and unlike the rigor of scholarly research and controlled experiment”. Swann (2002) argues that the design process can be considered a research process, with a clear focus on action. He suggests “… that action research and the action of designing are so close that it would require only a few words to be substituted for the theoretical frameworks of action research to make it applicable to design” (Swann 2002, p. 56). The similarities between the process of design and action research are further emphasized by Stapleton (2005), who regards both approaches as "activities for changing social reality": Both are cyclical and emergent, with action research having a plan-act-observe-reflect cycle and design a problem-analysis-synthesis-evaluation cycle. Action research, as a qualitative methodology, can also successfully combine both qualitative and qualitative approaches that are necessary to investigate the craft of game design. (Stapleton 2005)

The emergent nature of action research in Stapleton’s (2005) description refers to the flexibility of action research to accommodate insights resulting from unexpected outcomes of action. If necessary, even the research approach itself may be modified: new variables may only emerge during the process of investigation through action. The following sections introduce action research in further detail and outline how it was applied in this study. 54

3.2 Action research in this study Action research is typically characterised as cyclic, participative, qualitative and reflective model of inquiry (Greenwood and Levin 1998, Kemmis and McTaggart 1998). It follows a cyclical process, where initial hypotheses are tested by intervention in a situation and observation and evaluation of the outcomes of this action, which then leads to a repetition of the cycle if further changes are deemed necessary (Hopkins 2002, see figure 15). Dealing with open-ended processes, action research is characteristically responsive to changes in situation and context. Dick (2000) outlines the following steps usually taken in action research: 1. identification of shortcomings (for example in educational activities), 2. initial assumptions in regard of the problem, 3. formulation of a plan, 4. carrying out of an intervention (the action), and 5. evaluating the outcomes and development of further strategies in an iterative fashion.

Figure 15: They cyclic action research process adopted in this study

Action research typically aims to effect changes in a situation deemed deficient (ZuberSkerrit 1992) and tends to produce theory as a side effect (Jonas 2004, Argyris et al. 1985, p. ix). McMahon (1999) traces the similarities of reflective practice as proposed by Schön (1983) and the cyclic action research process to “the link originally made by Schön between the idea of the reflective practitioner and the concept of grounded research.” (McMahon 1999, p. 167) Action research is however different from reflective practice in that it always involves strategic action, “…a deliberate and planned intent to solve a particular problem (or set of problems)” (ibid.). It thus combines essential features of both the design process 55

and a structured mode of investigation. Action research has a characteristic openness for theory development during the research process, where an observing and often involved researcher can always add to or modify preliminary assumptions or hypotheses until they fit the situation adequately. In the context of this study, the involved researcher takes on the role of a designer. Action research takes a two-fold approach to rigour: while plans to change a situation might be rather subjective and based on individual experience, action research results can be directly measured either quantitatively or qualitatively from the changes brought about in the situation under investigation. In addition, repeating the cycles of action research is seen as a way to increase validity of successful intervention strategies (Dick 1999). Both strategies are adopted in the context of this study, as detailed in Section 3.3 and Section 3.4. As data collection and interpretation develop in parallel, action research allows for changes in methodology that may become necessary in later cycles. This feature makes for action research being a flexible methodology that can cope with unexpected outcomes that frequently occur in design processes. In the same manner, evaluation criteria for collected data may change over the course of design processes, as data interpretation develops in parallel. In the same way as design problems have no ‘stopping rule’ (Rittel and Webber 1973), action research can never be formally ‘complete’. The goal in action research is to reach a state of saturation, where either the situation under investigation or theoretical models are sufficiently improved, or it is unlikely that repeated action cycles will yield further insight. Reported action research typically emphasises the complexity and open-endedness of action research practices. Greenwood and Levin (1998, pp. 127-149) for example recount a number of case studies, in which the context dependency and unpredictability of action research processes is highlighted. They emphasise the necessity for action researchers to respect the specific requirements of a particular context and its stakeholders in order to produce adequate results. For this reason, any aspect of action research may be changed to fit particular needs, including change of initial goals, data collection methods as well as evaluation and reporting methods. Concluding their description of necessary diversity in action research, Greenwood and Levin (ibid., p. 149) argue that new knowledge develops from both positive and negative outcomes, and that unsuccessful action research results present an important source of knowledge. Understanding is generated by the attempt to change a system and the often unpredictable results of this attempt. In this way, action researchers need to be willing to “live with uncertainty” (ibid.) and willing to question the research approach even while the research process is under way if results are deemed unsatisfactory.

56

The starting point for this investigation was a set of assumptions of how CA can support the conceptual architectural design process that was developed from a literature review of previous work in the field. These assumptions were developed into a preliminary extended CA model to support conceptual architectural design in parallel to an initial software implementation, the Cero9 remodelling. This initial extended CA model was further developed through four additional software implementations, which were applied by students of architecture in studio or workshop settings. In this study, each of these applications constitutes an action research cycle. With results of one cycle informing the following research cycle, abstraction of observations into theory and software developed gradually and in parallel. Research outcomes of this study are typically threefold in each implementation cycle:

o

Software development: New software was created by the author for each implementation cycle, resulting in the gradual development of software functions and interfaces.

o

Theory development: Observations made in the testing of software implementations in the design studio served to inform the development and continuous modification of abstracted theoretical models.

o

Student learning: Students were able to learn about new approaches to design and were often inspired to explore architectural ideas in unconventional ways. In interviews, tutorials and questionnaires, students mostly commented positively on this experience.

In this study, the initially proposed extended CA model served as a starting point for an exploratory process of developing abstracted theoretical models through the design, application and observation of software implementations. It is not the intention of this study to focus on the development and testing of software tools. Test implementations in this study were not the ends but the means by which approaches to CA as architectural design support were explored. Software implementations, in particular those developed in the first action research cycles, thus remain partly fragmented and rather specific in their scope. The last software developed in the course of this study, Algogram, is the most generic of the software implementations developed and may be improved further to be applicable in a wider range of contexts and users in the future. This study comprises five implementation cycles, illustrated in the diagrams below. Figure 16 illustrates the sequence of steps taken within each action research cycle (left), and shows the interrelationships (middle) as well as the sequence (right) of the five action research cycles throughout this study. Figure 17 gives a more detailed overview of all five 57

research cycles. For a detailed description of the methodological aspects involved in each implementation, see the following Sections 3.3 and 3.4.

Figure 16: Steps in each action research cycle (left), the cyclic nature and interrelationships of action research cycles, and the sequence of action research cycles in this study (right)

58

Figure 17: Diagrammatic overview of the action research cycles in this study

3.3 Implementation cycles in this study The five software implementation cycles were initiated to examine the main research question of how CA can support the conceptual architectural design process. Though this general aim remained the same over the course of this study, the research approach taken over the course of the implementations continuously developed, varying in both research focus as well as methodology. For this reason, methodology and content are intertwined, and cannot be separated clearly. This also applies for evaluation criteria, which change together with the developing understanding and interpretation of action research outcomes. While similar in that the subject of investigation were CA-supported design processes, the five software implementation cycles employ a variety of settings and user groups, which

59

offers an opportunity to gain a broad understanding of how CA-based software can support applied designing. This approach is a response to the exploratory nature of this study that aims to build qualitatively new understanding rather than test predefined hypotheses. Instead of formal hypotheses, this study spells out initial assumptions present at the start of each action research cycle as a basis, but remains open for new insights that develop as a result of observing or being engaged in applied design processes. In the context of action research (as described in detail in Sections 3.1 and 3.2 above), applied design processes are recognized to be highly specific and unique. Developing understanding from observations in such circumstances requires a certain open-endedness of the initial research focus as well as research method. For the purpose of this study, both were developed to a more specific format based on observations of applied design processes over the course of five action research cycles. Consequently, this study takes advantage of a variety of settings in which to apply and to develop an understanding of CA-based design support. The following paragraphs describe and give reasons for the methodological choices taken in the action research cycles in this study, and explain how feedback generated by each software implementation was used to structure the following implementation. The following paragraphs also present the development of the initial proposition throughout the action research cycles. Though some repetition might occur with Chapter 5, which lays out the context, contents, process and outcomes of each implementation in detail, it is the purpose of this section to give an account of the research process in terms of methodology.

3.4.1. CERO 9 REMODELLING This initial software implementation was used as a test bed for the initial proposition derived from a literature review of previous work on the use of CA in architectural design, and were published in form of an early position paper (Herr 2003) and in the context of a tangible interface project (Herr and Fischer 2004). The working assumptions at the start of this research cycle were those inherent in the initial extended CA model (see also Section 2.4), which addressed two aspects: Modifications to conventional CA models for conceptual architectural design purposes, and the extension of Schön’s (1983) model of the design process to include CA as optional design “moves”.

Initial Assumptions CA can assist architectural design in the design of modular, high-density building typologies by generating alternatives within rule-based constraints set by the architect.

These assumptions were further developed in parallel to the remodelling of an existing architectural project by the architects of Cero9. The remodelling of this project was chosen 60

as its architectural approach, in terms of both design process and outcomes, seemed close to the initially envisioned application of CA to generate modular, high-density building massing. Over the course of four weeks, in November 2004, the author developed CA-based software to re-create the design process described by Cero9. Observations from the software development and application process were used to modify initial assumptions concerning the potential of CA in conceptual architectural design. Evaluation criteria in this implementation cycle related primarily to the ability of CA-based processes to model the chosen architectural design proposal. Two models for the application of CA as conceptual design support were developed as an outcome of this exercise, which are described in detail in Chapter 4. Outcomes from this research cycle were presented at the CAAD Futures 2005 conference in Vienna, Austria (Herr and Kvan 2005). A further developed theoretical model of extended CA was presented in an Automation in Construction journal paper (Herr and Kvan 2007).

3.4.2. A STUDIO TEST AT THE UNIVERSITY OF HONG KONG In this research cycle, new software was developed that implements the extended CA model developed during the Cero9 remodelling described above. The aim of this software implementation was to present architecture students with generic CA-based software to be used in a design studio setting at The University of Hong Kong. The software was given to a group of 23 postgraduate students of architecture for a one-week design exercise at the beginning of the winter semester 2005. The main focus of this research cycle was to collect data on student’s perception of the software interface and the way students chose to apply the software in their individual design projects.

Revised Proposition CA can assist architectural design in the exploration of new building typologies by providing architects with generative functions to create building volumes through the definition and execution of rules.

The studio test was used to collect data on the students’ output and experiences. Evaluation criteria in this implementation cycle related to students’ perception of software utility and scope of the design outcomes produced with the software. They remained however rather open-ended to allow for unanticipated insights based on studio observations. Design work was assessed in a design critique at the end of the week, with reviewer’s comments and general observations documented in form of field notes. Open-ended student feedback voiced during the computer-supported design process was documented in field notes.

61

3.4.3. TAINAN GENERATIVE DESIGN WORKSHOP Further developed software could be tested at a generative design workshop held at National Cheng Kung University, Tainan, Taiwan in April 2006. The workshop participants consisted of 17 postgraduate students, most of whom were experienced in using CAD software. The workshop lasted for one week, during which students, working in groups of two or three, applied two software implementations (one of which was developed in the context of this study) in a design exercise with a relatively open brief. Compared to the previous implementation, the software developed for this workshop was less generic. It aimed to provide students with several predefined functions to quickly generate surprising volumetric compositions of simple geometric elements:

Revised Proposition CA can support architectural design in the exploration of new building typologies by providing architects with generative functions to create building volumes. Such rules should enable architects to quickly generate surprising results based on relatively few input variables.

Similar to the previous studio test, this research cycle was used to test and collect feedback on both functionality and interface of the software. Evaluation criteria initially focused on questionnaire data on students’ perception of control and surprise in the results generated with the CA-based software. At the end of the workshop, however, initial evaluation criteria were recognized as rather limited, and the focus of observation shifted to applications the students developed for the software that contradicted or extended initial assumption by the software developers. Design outcomes were reviewed in a final design critique at the end of the workshop. Field notes were taken throughout the workshop to document observations. The workshop was further used to collect quantitative data in addition to field notes and design outcomes. To this end, a framework was developed that allowed the tracking of students’ use of software functions. In addition, questionnaires containing both multiplechoice and open-ended questions were used to collect data on several aspects: students’ perceptions of interacting with the software, distribution of tasks within design teams and feedback on software functionality. The outcomes of the workshop, however, demonstrated that the scope of the initial framework for both data logging and questionnaires was too narrow to capture essential observations, which were mainly of a qualitative nature and derived from field notes made over the course of the workshop. The implementation and its outcomes were published in a conference paper for CAADRIA 2007 (Fischer and Herr 2007).

62

3.4.4. KCRC URBAN AUTOMATA Outcomes and observations from the generative design workshop challenged the assumption that CA-based design support could benefit architects by providing generic form generating software. Following the workshop, an opportunity arose to support an individual postgraduate student at The University of Hong Kong in her studio design project. In late April and early May 2006, software was developed according to her design framework, which was based on using rule-based compositions of volumes to develop urban models. In this case, the software was specific and tailored to her individual preferences and needs. In this case, CA-based design support was used to manage a complex arrangement of elements based on a set of rules. The software allowed the generation of alternatives to present a variety of urban models for the designer to choose from.

Revised Proposition CA can support architectural design in the exploration of new building typologies by providing rule-based functions to generate a variety of complex urban or architectural models.

Software in this research cycle was developed in close collaboration with the student. Data was collected mainly in the form of field notes and design results, as well as an interview with the student. The graduate student’s feedback on utility provided the primary evaluation criteria, with design critics’ feedback at the final presentation serving as additional evaluation factor. As a result of reviewer’s comments during the final design critique of this studio project, visual representations and their interpretation became the focus of the investigation, which led to the following implementation.

3.4.5. ALGOGRAM This research cycle was based on the recognition of individual interpretation as a central element of the early design process. Instead of providing CA-based software support to generate building volumes, this software implementation focused on assisting students in their individual thinking. The previous implementation had made use of abstract representations to create diagrammatic models subject to reinterpretation. Algogram further builds on this approach to using CA-based design support by focusing on ways to encourage students’ explorations. Algogram was developed for the initial phase of a second-year studio project at The University of Hong Kong in October 2006. Nine students used the software during their conceptual design phase, which lasted for two weeks, after which they switched to other means to further develop their concepts into architectural building form. The focus

63

in this research cycle was on collecting data on the way students applied the software to their individual design projects, on students’ perception of the abstract graphic representations and on the general usefulness of the software interface provided.

Revised Proposition CA can support architectural design in the conceptual design stages by providing architects with “automated diagrams”: graphic representations that consist of abstract and simple elements that encourage individual interpretations and whose relationships are defined by rules.

Outcomes from the design studio were assessed in two design critiques. During the application of Algogram, data was collected in form of field notes and semi-structured individual interviews with each of the students who participated. Evaluation criteria for the software within this implementation cycle were students’ perception of software utility as well as ability of the software to aid students in developing conceptual ideas based on threedimensional configurations of functions. In addition, student sketchbooks were reviewed for clues on the role of the software in students’ design processes. Results from this software implementation were published in a conference paper at the CAAD Futures 2007 conference (Herr and Karakiewicz 2007).

3.4 Data collection methods Testing the CA-based software implementations in design studio and workshop settings entailed a close collaboration between the author and architecture students in all research cycles of this study. This study was initially intended to begin with a phase of quantitative data collection to test the initially proposed extended CA model. It was assumed that this research phase would lead to a phase of quantitative data collection once an approach to CA as conceptual architectural design process support was sufficiently framed. Qualitative data was gathered mainly in the form of field notes, interviews and assessment of student design results. After an emphasis on qualitative data collection in the first two implementation cycles, the third implementation cycle – the generative design workshop in Tainan – was taken as an opportunity to collect quantitative data in a more structured framework. The outcomes of this test implementation, however, demonstrated that the quantitative evaluation framework employed was too narrow. Data collected by software interaction logging and multiple-choice questionnaires did not capture results adequately. The main finding in this research cycle was that students decided to misappropriate the software in

64

unanticipated ways for their individual purposes. For this reason, data collection in the following test implementations reverted to the more open-ended qualitative data collection methods mentioned above. Action research typically comes to an end when the problem that initiated the research process is sorted out in some way. In research-driven action research, the research process may be ended when repeated action research cycles do not yield any more significant new data. In this study, action research cycles led to a new perspective on CA as conceptual architectural design support that differs considerably from initial assumptions. The extended CA model and the various approaches to CA explored in this study, in particular the results of the fifth implementation, Algogram, constitute an answer to the main research question of this study.

65

Chapter 4. Extended CA From the literature review and the research questions presented in Section 2.4.2, an initial proposition was developed, which consists of a preliminary extended CA model to support conceptual architectural design processes. This chapter outlines the extended CA model and focuses on two main aspects: 1) proposed extensions to conventional CA models for modelling architectural forms and contexts, outlined in Section 4.1, and 2) a model of the integration of CA into the architectural design process based on Schön’s model of the design process, outlined in Section 4.2. This initial model formed the starting point for the series of software implementations described in Chapter 5.

66

4.1 Extended CA for modelling form The initial proposition derived from a review of previous work in the field consists of an extended CA model to support conceptual architectural design. The two sections in this chapter each address a particular aspect of this extended CA model. While this section presents modifications to conventional CA models for the purpose of modelling architectural forms and contexts, the following section focuses on the integration of CA into the conceptual design process. While CA have been explored in the context of architecture, previous applications have tended to adopt existing systems like John H. Conway’s Game of Life (Gardner 1970) without much modification. As illustrated in Section 2.3.3, such studies typically generated complex spatial patterns by experimenting with rule sets, with the resulting threedimensional patterns usually being interpreted as architectural form. This approach, however, limits applications of CA to architectural design to the aspect of building form within an abstract context. As conceptual architectural design support, CA may also be used to address other architectural requirements. Whether addressing form or other requirements, applications of CA to the conceptual design process could benefit from modifications to the rigid framework of conventional CA models. Adaptations of conventional CA models as common in other fields of research are usually intended to “achieve some measure of representational realism” (O’Sullivan 2000, p. 7) that is appropriate to their specific field of application. A CA model for conceptual architectural design needs to provide an answer to the question for the meaning of both cells and rules in an architectural context. Considering CA applications in the urban planning field, O’Sullivan (ibid., p. 2) asks: “What do the cells represent? And, given what they represent, what is an adequate set of allowed cell states?” O’Sullivan states that answers to these questions will subsequently affect the “construction, meaning, and interpretation” (ibid.) of transition rules. O’Sullivan (ibid.) proceeds to argue that these questions can only be answered in the specific context within which CA are applied, and suggests a number of generic possible variations of conventional CA models. Together, these variations constitute an “objectbased approach” that diverges from abstract and generic conventional CA models. This approach aims to present a range of options, and leaves the attribution of meaning up to the designer of specific CA models. In conventional CA models, rules are typically bound to cell shapes and arrangements, and remain rather abstract. Within an object-based approach, however, rules could be used to describe and map more specific forms of interaction between cells. In this study, an increased number of choices with regard to CA properties is seen as beneficial in the context of conceptual architectural design. While O’Sullivan’s (ibid.) proposal is intended to inform the application of CA to urban design, a number of 67

these suggestions are found to provide appropriate extensions to the application of CA to architectural design. Figure 18 illustrates the extensions of conventional CA models adopted to form the initial extended CA model in this study. They are explained in further detail below.

Figure 18: Conventional CA and object-based (extended) CA

Conventional CA systems such as those described by von Neumann (Burks 1970), Ulam (Schrandt and Ulam 1970), Conway (Gardner 1970) and Wolfram (1984) (as discussed in Section 2.3.2) are based on regular lattices of identical cells, with cells in discrete states at discrete time steps. This abstract approach limits applications to architecture: Modelling architectural form with such CA systems requires volumetric models of high resolution. With cell form and grids limited to regular Cartesian lattices, cell states need to remain rather abstract to represent a wide variety of potential cell properties, which limits their ability to represent architectural contexts. Similar challenges arise for the construction of transition rules based on such cell definitions, which need to remain at an abstract level of description as well. O’Sullivan (2000, p. 3) argues that in the context of urban planning, “More object-based approaches to cells – where cells represent land parcels, administrative areas, or even individual buildings – almost invariably require non-regular lattices…”. While object-based CA models may become increasingly heterogeneous, O’Sullivan (ibid.) also suggests that this “…may ease the problem of defining transition rules”, as rules become less abstract and more objectspecific. In this context, more architectural design specific CA systems, featuring non68

regular lattices and more specific transition rules, could help to improve model accuracy and descriptive potential. They could furthermore improve computation performance, as conventional CA models at high resolutions can require extensive calculation time - in particular if less simple rule sets are processed. An object-based approach to develop a CA system to support the architectural design process could take different mapping strategies to relate elements in the model to elements in a design context. A CA model may describe a design context rather figuratively, such that cells represent tangible architectural elements of various sizes. On the other hand, the dynamics of abstract CA models may also be mapped onto secondary, external geometry (as presented by Coates et al. 1996, see also Section 2.3.3). Mapping decisions typically concern appropriate scale and granularity of cells in the model – a cell may represent a pixel in a satellite image, a city block, a building or an individual brick, depending on the focus of a particular investigation (figure 19). In combination with the properties of the CA model, mapping strategies selected for a specific task determine whether a CA system adequately represents a design context.

Figure 19: Potential variety of cell scales in architectural CA models

Conventional CA are typically employed to simulate bottom-up dynamics that are driven by parallel local interaction of cells. In the context of urban planning, O’Sullivan (2000, p.3) states that while “much of the emphasis in CA approaches … has been on the emergence of global structure from local events” (ibid.), many urban phenomena are driven by non-local or global interactions and relationships. This observation also applies to architectural design, which typically involves responding to global as well as local constraints given in form of design briefs, regulations or in the form of existing contexts. Non-local interaction of cells implies a departure from conventional CA models, which feature spatially stationary neighbourhoods, i.e. neighbourhoods that are similar at each location throughout the grid. Varying neighbourhoods are also required in an object-based approach to cell modelling as described above: With cells of different sizes and properties located in irregular grids, cell neighbourhoods need to accommodate varying local grid topologies. In the context of conceptual architectural design, transition rules in CA are not necessarily intended to simulate previously observed dynamics as is common in the case of 69

urban planning, illustrated by the examples discussed in Section 2.3.2. Instead, their purpose is likely to vary according to a specific design project and a designer’s intentions. When used as conceptual design support, the use of CA within a specific project is furthermore likely to change throughout the design process, as a result of the designer’s evaluation of intermediate design results. The increased dependency on the designer’s feedback requires CA models that are flexible enough to cope with changes occurring over the course of a design project and thus need to be flexible, which affects transition rules as well as cell properties and compositions. In summary, three basic modifications are suggested for an extended CA model for conceptual architectural design: an object-based approach to cells, the introduction of irregular lattices and heterogeneous neighbourhoods, and transition rules that may change during the design process.

4.2 Integrating extended CA into the architectural design process In the previous section, changes to conventional CA models were suggested that relate primarily to the modelling of architectural contexts. This section considers the potential role of CA in the conceptual architectural design process. Conventional CA are typically used as fully automated simulation engines and do not allow a designer input other than the setting of initial parameters. As discussed in Section 2.1.3, however, conceptual design processes have been shown to depend on frequent feedback cycles, which allow for creative thought development by providing opportunities to the designer to reconsider intermediate results. According to Schön (1983), designers engaged in conceptual design processes make use of design support to assist in the reflective conversation with the situation they are engaged in. For this reason, conventional conceptual design support usually provides representations in the form of sketches and models, which allow for different interpretations and visual discovery. Used as exclusive, self-sufficient tools, CA are thus unlikely to integrate well into the architectural design process nor generate desirable outcomes. In this study, Schön’s (ibid.) conversational theory of the design process is adopted as it acknowledges the strong feedback component of open-ended conceptual design processes. As stated in Section 2.4, these characteristics have not been sufficiently acknowledged in previous applications of CA to architectural design. Instead of prescribing a particular method, Schön aims to support and assist existing processes, which usually depend on the specific setting of the design problem. To solve a design problem, the designer initiates a conversation, attempting to make the setting ‘talk back’, such that a responsive design process may happen. The design process model proposed by Schön portrays designing as an exploratory activity that allows for a process of exploration without determining the outcomes. During the

70

conceptual design stage, the designer uses tools to externalize design proposals and modifications, which allows for the subsequent evaluation and modification of intermediate results. Schön’s theory thus suggests a potential for investigating dialogue-based rather than fully automated generative design processes. In this study, conventional sketching is taken as a model for introducing CA to the architectural design process. When considering the potential of CA in such an iterative process, the bottom-up nature of CA can support exploratory processes. CA systems, however, are typically applied as fully automated systems that operate according to predefined rules and usually do not allow modifications during run-time. In Schön’s description of the design process, though, the responsiveness of a design process is essential to maintain constant feedback to the designer, who evaluates intermediate results and decides on subsequent design moves. Within CA systems, evaluation is typically based on local interaction rules, which produce emergent results rather than allowing for directed development. To provide more flexible evaluation mechanisms besides predetermined local rules, this study proposes to integrate CA into a design process that involves both CA-based design support and the designer in close dialogue. The integrated process employs CA in their variance-generating capacity, and adds the designer’s top-down capability to assess and control overall development. This allows the generative process to be controlled and directed according to the designer’s current assessment of intermediate outcomes rather than leaving assessment to the end of a fully automated generative sequence.

Figure 20: Schön’s model of the design process as reflection in action (above) and an extended model integrating generative CA support (below)

71

Figure 20 illustrates how CA may support the design process in an extension of Schön’s (1983) original design process model, as discussed in Section 2.1.3. CA are integrated into Schön’s model as optional design moves, the stage of the design process at which representations of the design task, typically sketches or diagrams, are modified. The extended design process model maintains the basic activities of framing, moving and reflecting or evaluation characteristic of Schön’s (1983) design process model, and offers CA-based generative processes as optional design moves. Such CA-supported design moves additionally provide nested evaluation loops as each element (CA cell) with CA-based functions is capable of automated basic evaluation of numerical constraints. This type of evaluation primarily concerns those aspects of the design process that may be automated, while the overall interpretation and evaluation of results in the proposed approach to CAsupported design processes is left to the designer. While CA are still employed as generative mechanisms with potentially surprising results, this process allows the designer more immediate control in determining the direction of the design process. The conversational nature of the proposed model facilitates a closer integration of automated and manual steps of the process, resulting in a hybrid design process that extends previously suggested models of generative support for conceptual design. An advantage frequently attributed to generative algorithms in design is the possibility of exploring and representing entire solution spaces, from which potential solution can be selected. Solution spaces are generated from a range of initially defined parameters, which are varied and combined to produce arrays of potential design solutions. Boden (2004, see also Sections 2.3 and 2.3.1) describes such potential solution spaces to a design problem as ‘conceptual spaces’, within which the designer navigates by making a sequence of decisions until an appropriate result is obtained. In generative systems, such conceptual spaces are typically determined by a set of preset rules, facilitating comprehensive exploration and representation. Interactive generative design processes, in contrast, feature much less constrained conceptual spaces as the designer can choose to modify rule-driven generative processes beyond the scope of initially defined parameters. Eckert et al. (1999) describe interactive generative systems as powerful tools for human designers, which utilize the complementary abilities of both. Eckert et al. f) suggest that the strength of humans lies in the perceptual evaluation of designs, according to criteria that are difficult to implement in software as they cannot easily be described numerically. Similarly, the CA-based conceptual design process outlined here relies on the designer’s decisions and feedback during the design process. CAbased design support is primarily used for tasks that involve the processing of greater numbers of elements and linked through rule-based relationships. This hybrid, CAsupported conceptual design process is aimed to provide a broader range of possible design

72

responses to a design task than achievable in previous approaches to CA as generative design support. A further necessity when providing CA-based support to architectural design processes is the option of discarding previous design steps. Effective navigation in design solution spaces requires the possibility of back-tracking previous decisions and choosing an alternative decision from a previous stage. CA, however, are irreversible systems in the sense that given states do not allow reconstructing previous states. Conventional CA systems thus inhibit returning to previous development stages. Therefore, a CA system for dialogue-based exploration of solution spaces needs a record of its previous states. Such a record may track the steps within a CA design system only, or it may track both manual and automated design moves. Variations of back-tracking options are used in the series of software implementations described in Chapter 5. According to Schön (1983), an essential characteristic of design processes is their iterative nature, which involves the constant re-working of design proposals. This type of process does not follow a structured sequence of design steps since the outcome of design moves is rarely predictable. In developing generative design support for such processes, modular software support seems more suitable than more elaborate generative sequences. Such modular software support provides the designer with a range of options to choose from – or ignore and proceed with manual design moves, all based on immediate intuitive decisions as typically seen during the sketching process. In the proposed design process model, CA support may consist of a variety of CA options that can be customized and adjusted to suit the design context by setting a number of variables. Figure 21 illustrates schematically the relationship of automated and manual design steps within a conventional fully automated system on the one hand, and within an interactive, CA-supported design process on the other hand.

Figure 21: Schematic outlines of a design process supported by a fully automated system (left) and a dialogue-based iterative design process with modular script support (right)

73

The manual operations shown in the automated generative process (Figure 21, left) indicate post-processing and adaptations of the design outcomes of a fully automated generative system. Manual operations, however, do not affect the generative system during run-time. The generative process proposed in this stud allows for alternating automated and manual steps in the design process, as illustrated in Figure 21 (right). Within this process, the choice between manual or automated steps remains with the designer. Using generative CA systems for design tasks entails the integration of cellular systems with traditional CAAD environments. As Krawczyk (2002) observes, CA-generated form is likely to be used either in particular aspects or in particular stages of a design project, with the outcomes frequently modified during the design process on the basis of an architect’s assessment. Software implementations of CA-based design support software in this study were implemented in 3DStudio Max to allow simple transitions from CA-supported design to conventional 3D modelling. In summary, modifications to three aspects of conventional CA are suggested to support conceptual architectural design processes. First, CA-based processes are proposed as supporting exploratory conceptual design processes by providing automated processes based on local dynamics between elements and numeric evaluation. Such CA-based design support should allow for frequent feedback and modifications by the designer in analogy to conventional sketching. Finally, previous design steps should be retraceable to allow the designer to revert to earlier design proposals.

74

Chapter 5. Five Implementations This chapter reports the five software implementations that were developed over the course of this study and were applied in design studio or workshop contexts to explore CA as architectural design process support. From the extended CA model outlined in Chapter 4, this series of software implementations further develops the preliminary CA model in five design applications. From a focus on CA as form generators, the implementations progressed towards an understanding of CA as “automated diagrams” in the fifth and last software implementation. Each of the five sections in this chapter describes one software implementation in terms of initial aims, expected outcomes, its relationship with previous applications, the software implementation, and its results. Each section concludes with a critical reflection that compares outcomes against initial assumptions and the implications for the theoretical model and the next test implementation. The final summary tracks the development of both research focus and the insights resulting from this phase of research.

75

5.1 Cero9 Re-modelling 5.1.1 Introduction Similar to previous applications of CA to architectural design, CA were initially deployed primarily to primarily support the generation of intricate forms consisting of large numbers of similar elements. CA were thus thought to be particularly suited to support the generation of buildings in high-density environments, which often consist of large numbers of similar living units (Herr 2003). Moreover, high-density architecture typically involves tight constraints or rules that govern the layout of buildings. As in the “sun god city I” proposed by Watanabe (2002, see also Section 2.2.3), applications of CA-based design support were intended to support the generation of alternative building morphologies that could provide greater variety and efficiency than those designed by conventional means. In the Cero9 remodelling implementation cycle, the proposed extended CA model outlined in Chapter 4 was thus applied to the remodelling of an existing architectural project by the architects of Cero9. The architectural project chosen for remodelling comprises a group of buildings proposed as a high-density city block in northern Japan (figure 22). The competition entry chosen for remodelling was designed by the Spanish design team Cero9 in 2001. It proposes a high-density urban block for the city of Aomori, Japan, developing the given site as a high-density mixed use complex in form of an array of thin, 25-storey ‘micro-skyscrapers’.

Figure 22: High-density architecture for Aomori/Japan by Cero9

Architecturally, the design is based on a cellular understanding of building form where cells contain single living units and are easily identifiable visually, facilitating a rather straightforward, form-centred CA approach. For larger projects such as this one, Cero9 tend to use

76

a rationalised manual design process that aims at generating variety from simple rules, which are applied in successive design stages according to design constraints and project context. In the case of Cero9, this design process has arisen from the observation that in a design team, constraints and conditions of the design are often easier to agree on than final results (Diaz Moreno and Garcia Grinda 2004). The architects of Cero9 have described the rules used at intermediate design steps in a visual and diagrammatic rather than algorithmic way. Figure 23 illustrates the design process as a sequence of steps, using simple visual units to represent architectural elements such as building footprints, views or surrounding urban context. This indicates an emphasis on overall result rather than on strict adherence to mathematical constraints. Rules, in this case, are seen as useful only in as far as they contribute towards a viable architectural proposal and may be interpreted rather flexibly. Cero9 also describe the rules as producing results of an emergent nature, the outcome of which is judged more on coherence and architectural appropriateness than on maintaining of conventional forms (Diaz Moreno and Garcia Grinda 2004).

Figure 23: Visual description of rules used in the original manual design process

5.1.2 Initial assumptions CA can assist architectural design in the design of modular, high-density building types by generating alternatives within rule-based constraints set by the architect.

From a review of previous work in the field, this study initially took an approach that saw CA as form generators in the context of modular buildings in high-density environments.

77

These initial assumptions were published in form of an early position paper (Herr 2003) and in the context of a tangible interface project (Herr and Fischer 2004).

5.1.3 Aims and expected outcomes The remodelling of Cero9’s high-density project was chosen as its architectural approach to generate high-density architecture relies on a rule-based generative process. In terms of both design process and outcomes, this approach seemed close to the initially envisioned application of CA to generate modular, high-density building massing. Based on the extended CA model outlined in Chapter 4, this implementation aimed to develop a threedimensional CA system capable of generating a model of Cero9’s design proposal. The model was intended to resemble the selected architectural project in terms of form as well as in terms of its generative process. It was however expected that over the course of the implementation process, outcomes and insights beyond the scope of the initially proposed extended CA model might arise.

5.1.4 Implementation Over the course of four weeks, in November 2004, the author developed CA-based software to re-create the selected architectural project as a three-dimensional model in a generative process resembling the design process described by Cero9 (Diaz Moreno and Garcia Grinda 2004, see also visual process description in Section 5.1.1). Cero9’s approach to architectural design bears an affinity to the responsive generative design process outlined in Section 4.2 in that it relies on a sequence of design steps that are directed by the design team, but it also draws on a set of rational generative mechanisms that could potentially be automated. The process was implemented within a three-dimensional modelling software, AutodeskVIZ, with additional scripts providing a set of CA functions. Based on the extended CA model proposed in Chapter 4, these CA functions consist of rule-based processes that affect particular element types by changing their positions, types or geometries. As this software implementation was only intended to be used by the author, no graphical user interface was developed. Figure 24 shows both the three-dimensional model as well as the script code window during the remodelling process.

78

Figure 24: Three-dimensional model and scripting window during the remodelling process

To remodel Cero9’s design, aspects and stages in the design dealing with quantifiable constraints were first identified according to Cero9’s own diagrammatic description (see figure 24). To accommodate both generative and conventional design procedures allowing manual manipulation of intermediate results, the implemented CA functions may be used in phases, with intermittent stages of manual design interventions. CA support is given through a series of scripts that can be assigned to specific objects designated by the designer within the 3D modelling environment. Thus, a variety of cell behaviours can be assigned dynamically during the design process, such that elements within the modelling environment can change their behaviour over time. A further distinction to classical CA lies in the flexibility of cell properties – in this example, cell geometries and neighbourhood relationships may vary individually. In contrast to classical CA, where cells are uniform and cell states do not affect cell geometry, CA functions can enable cells to change their geometry in response to their states. At the end of a sequence of rule-based position finding within the site, square tower footprints for example change into rectangular units, the podiums of the high-rise towers that provide community spaces. To accommodate flexible cell geometries and changing behaviours during the design process, cell neighbourhoods are identified dynamically, depending on the cells and functions in operation. For back-tracking of previous CA stages, this implementation uses the standard “undo” function of AutodeskVIZ, which handles each script execution as one design step. The generative sequence in the CA-supported remodelling process begins with rearrangement of two-dimensional building footprints on the site, which grow into threedimensional buildings at a later stage. Following the design sequence described by Cero9 Diaz Moreno and Garcia Grinda 2004), CA functions of elements in the digital model were used for a variety of tasks: The arrangement of towers on site constrained by available views

79

and existing buildings surrounding the site, modifications of tower locations to accommodate tower inclinations, finding appropriate locations for commercial and community spaces connected to the towers, and the placement of local extensions to some of the living units (figure 25).

Figure 25: Sequence of design moves in CA-supported remodelling process

While generic CA functions and frequent manual design decisions result in a flexible design process, a number of variables had to be predefined in order for results to match Cero9’s design outcome. Thus, CA execution did not affect the basic cellular layout, which determines the characteristic tower footprints and the number of buildings on a site. Other variables as well as the assignment of rules to individual cells were however decided upon during human intervention between CA execution phases and resulted in a variety of possible final outcomes (figure 26). Elevated connections between individual towers, for example, were added manually at a later design stage, as they were in Cero9’s process.

5.1.5 Results The Cero9 remodelling explored the applicability of the extended CA model proposed in Chapter 4 in an architectural context. Aspects of the extended CA model that were found practical in this implementation include the object-based approach to cells, heterogeneous cell neighbourhoods, the modular approach to CA-based software support and the flexible assignment of rules to cells during the design process. By taking an object-based approach to cell modelling as proposed in Chapter 4, the number of required cells could be limited significantly compared to approaches that propose the modelling of form based on approximation with uniform cells and high resolutions (as described in Mitchell 1990). The 80

modular character of the generative cellular design support allowed the modification of results during the design process without the need to change the design tool, as it would be necessary in a self-contained, fully automated system. The rules and constraints used by Cero9 for the discussed project were not automated but guided a conventional design process. Automating generative procedures in remodelling Cero9's design allowed for the exploration of rule variations and different initial variable settings, which produced a variety of outcomes (figure 26).

Figure 26: Alternative cellular automata-generated versions of Cero9’s design

As figure 26 illustrates, alternative results could for example illustrate the effect of different building heights and inclinations on the overall result. In the remodelling process, lower tower heights and less inclination seemed to achieve better lighting conditions between the buildings. Varying the number of additional flat extensions as well as the number of connecting bridges generated markedly different visual characteristics of the final assembly of towers (see the two illustrations at the bottom of figure 26). Variants of an architectural design, such as those generated in this example implementation, may provide different 81

views on a design concept, and thus inform the design process. In this case, CA provided design support through automating rule-based processes, but did not completely determine the outcome of the design process. The generative functions implemented in this example operate mainly at the level of residential unit “cells”, but they could just as well be applied to similar problems on different levels of scale, depending on the modelling environment they are assigned to. The implementation process further generated unexpected results: In addition to the proposed extensions to conventional CA models, a number of further modifications to the proposed CA model were required in the remodelling of Cero9’s project. While initially, an object-based approach to cells was proposed, the remodelling of Cero9’s project implied the use of moving cells similar to von Neumann’s “kinematic automaton system” (Burks 1970, see also Section 2.3.2). Similar directions for the extension of conventional CA have been proposed by Batty et al. (1997), Torrens and O’Sullivan (2001) and Benenson and Torrens (2004). This further required the dynamic identification of cell neighbourhoods at every evaluation step. During the remodelling process, cell states could affect cell geometry, such that transition rules could change both internal cell states as well as external cell shapes. Throughout the remodelling process, cells multiplied but also differentiated increasingly from initially only one cell type (tower footprint unit) to generate the variety of element types in the architectural model, which for example include community spaces, living units, balconies and elevated connections between the towers. Outcomes from this research cycle were presented at the CAAD Futures 2005 conference in Vienna, Austria (Herr and Kvan 2005). A further developed CA model was presented in an Automation in Construction journal paper (Herr and Kvan 2007).

5.1.6 Discussion In the Cero9 remodelling, CA offered an effective generative method with an architectural project that involved some degree of repetition amongst larger numbers of formal elements. The extensions and adaptations of conventional CA systems for architectural purposes suggested in Chapter 4 could be applied in the CA-based generative modelling process, with the necessity for additional extensions arising during the design process. Such extensions include extended cell neighbourhoods beyond immediately adjacent cells, alternative state transition rules, potentially dynamic cells, varying cell geometries and the replacement of regular grid lattices with the more flexible spatial relationships of an object-based approach part of the extended CA model proposed in Chapter 4. Implementing CA-based design support as a modular system that allows for user intervention and manual modifications during run-time provided sufficient flexibility to

82

create a close resemblance to the original architectural project by Cero 9, in both the volumetric model as well as the generative sequence of the design process. Within the scope of the Cero9 remodelling, the integration of CA-based design process support as an optional design “move” has produced a responsive process that allows the designer to frequently reconsider his assumptions and direct the design process. It thus allows for the integration of CA’s capacity for bottom-up complexity generation and human designers’ top-down capacity to control overall development. In the remodelling process, CA were used for those tasks that may be described using rules, while human design interventions may deviate from consistent and predictable rule-based processes. In this way, extended CA as initially proposed in Chapter 4 could provide generative variety in architectural design outcomes while enabling the designer to modify and guide the overall design process. This implementation, however, was limited to the task of remodelling an existing architectural project. As such, the CA-based software implementation developed for this exercise was determined by, and limited to, a specific and rather well-defined context. The variations in outcomes achieved through varying parameters in the remodelling process shown in figure 26 suggest that CA-based design support could also be used to enable openended design processes in other design processes. As a generic concept, such CA-based software could further be reusable as procedural logic rather than as an architectural form, similar to the way Cero9 draw upon earlier design processes to inform future designs in different contexts. Based on the Cero9 remodelling, it was assumed that by supporting the generation of variety within design contexts comprising large numbers of elements, CA could also provide more generic design support for large high-density developments (Herr 2003).

5.1.7 Resulting questions The Cero9 remodelling indicated that the proposed extended CA model could provide a more efficient as well as more flexible approach to the modelling of architectural form than conventional CA in previous work in the field. The proposed integration of CA as optional design move within an otherwise conventional design process was further able to accommodate the flexibility between automated and manual design moves observed in the description of Cero9’s design process by the architects themselves. Nonetheless, the Cero9 remodelling was limited in terms of scope as it merely aimed to reproduce a given architectural design process with predefined outcomes. In using CA as design support two strategies are possible: either the rules can be defined, with outcomes of an open-ended nature. Or the intended outcomes can be defined first, with the rules established accordingly. CA are typically used in the first way, since

83

finding rules that lead to a predictable outcome still have to be found by experimentation or by evolutionary procedures. When developing CA-based support for open-ended architectural design processes, new questions arise. In how far can generic, re-usable functions be abstracted from the specific CA-based process of this implementation? Which functions could be useful to support open-ended design processes that aim at creating novelty? These questions were further explored in the following implementation cycle that involved postgraduate students working with a generic CA-based software implementation in the context of a design studio.

5.2 A studio test at The University of Hong Kong 5.2.1 Introduction After testing the proposed extended CA model in a rather specific setting – the remodelling of an existing architectural project by Cero9 – in the previous implementation, this implementation focused on providing CA-based design process support to a group of 23 postgraduate students at The University of Hong Kong in a design studio setting. Evaluation of the initial software implementation had indicated the potential utility of extended CA to remodel an existing architectural proposal, but was confined to the author as single user. This implementation cycle thus focused on how the software could support architectural students in their design work. The software was used for a one-week design exercise during the initial phase of a design studio at the beginning of the winter semester 2005. While in the Cero9 remodelling, the focus was on examining the applicability of the proposed extended CA model, this implementation concentrated on providing students with generic CA-based software to be used in open-ended, individual design processes. The studio project focused on the use of new CAD paradigms in design, in particular in urban design. The initial one-week exercise aimed to introduce students to thinking in terms of process instead of end result when designing. In an initial meeting, students were introduced to simple, paper-based CA exercises, in which students developed rules to transform simple symbols on paper. Figure 27 illustrates an example of a rule-based system of symbols that are transformed and multiplied according to simple rules. Students created a variety of symbols and rules, which mostly aimed at generating patterns in an additive way.

84

Figure 27: Paper-based CA exercise illustrating how simple rules operating on simple graphic symbols can lead to intricate patterns

Following these initial exercises, the CA-based script utility developed for this implementation was introduced. The design task given to students was to identify and further develop an aspect of a design exercise of the previous week (in which students had developed a conceptual design for an urban “island”) with a rule-based design approach. Using the CA-based software was recommended but not mandatory.

5.2.2 Revised proposition CA can assist architectural design in the exploration of new building typologies by providing architects with generative functions to create building volumes through the definition and execution of rules.

5.2.3 Aims and expected outcomes This implementation aimed to explore the questions raised by the previous software implementation: How could generic CA-based design process support be provided based on the specific design strategies used in the case of Cero9’s project? Which particular functions should be drawn out from the previous implementation? In contrast to the previous implementation, students were not expected to script but had to be provided with a way to access and control the CA-based functions provided in the software. Thus, an additional question arose of how to structure a graphical user interface to enable students to compose and use CA-based rules. As the software was intended as an optional design “move” within an otherwise conventional design or modelling process, a further question concerned the way students would combine conventional manual modelling and CA-based functions. Accordingly, the main focus of this research cycle was to collect data on the way students chose to apply the software in their individual design projects as well as students’ comments on the software interface. It was expected that students would aim to generate 85

architectural form by using the provided software, and in the process would encounter difficulties that could lead to insights on a theoretical level by suggesting changes to the initially proposed extended CA model. The students’ design work was assessed in a design critique at the end of the one-week exercise. Student comments as well as general observations were documented in form of field notes.

5.2.4 Implementation Similar to the Cero9 remodelling before, the CA-based design support software was implemented in MAXScript, as a utility for 3DStudioMAX. The utility includes a graphical interface to CA-based modeling functions that allows students to configure and use CAbased rules without being able to program (figure 28). The CA-based software implementation was intended to complement conventional three-dimensional modeling in 3DStudio MAX, which many of the students were already accustomed to. The CA-based functions can thus easily be accessed and used within a conventional design process. Using the software, students could create simple functions and neighbourhood relationships from simple menus. It further allowed students to add CA functions to a wide variety of objects within a 3D model in 3DStudioMAX.

Figure 28: Graphical user interface of the utility used in this implementation

Several generic functions were derived from the previous implementation, most of which relate to simple geometric operations, such as moving or rotation. Additional functions such as grow and replace relate more to the generative production of patterns, which potentially 86

generate surprising results. The following basic functions were drawn out from the Cero9 remodelling process:

o

change properties of cells

o

move

o

rotate

o

grow: add further cells

o

replace: replace one type of object with another

o

delete a particular object

Figure 28 shows the graphical user interface, which focused on creating a structure to configure CA rules in a simple manner. For this purpose, the interface was split into four Sections: a general Section to select scene objects as cells and configure cell neighbourhoods, and three expandable menus focusing on rule configuration, divided into “IF condition”, “THEN action” and “THEN details”. Once settings in all Sections are decided upon, the script can be executed for a number of iterations defined in the general parameters.

5.2.5 Results While all students developed rule-based generative systems, only about half of the students (10 of 23 students) decided to experiment with the provided software. Reasons for not using the software included unfamiliarity with 3DStudioMAX and a preference for conventional design means such as sketching. Another reason was perceived incompatibility of a chosen design approach with the formalism of the CA-based software structure: One of the students commented: “My island is about freedom. I did not know how to write rules about freedom”. While those students who decided to apply the software readily experimented with the use of rules and incorporated the forms generated by the software into their projects, some have questioned the disruption rule definitions caused in their thinking process as well as the lack of predictability in the generated outcomes. What was on the one hand perceived as an interesting new method also discouraged students who previously had used computers only in deterministic ways to illustrate previously developed ideas. Students tended to start with a conventional goal-driven approach, first deciding on the nature of the outcomes and then trying to implement rules in a way that would generate the intended results. This approach, however, typically limited the scope of students’ work, as in the case of Cheng Chun Leung, who described this way of working as a frustrating experience (Figure 29, far left).

87

Figure 29: Exploratory design results generated with CA-based design support: Student work by Cheng Chun Leung (far left), Hung Tat Yuen (left), Lai Fan Hei (right)

Those students who engaged in an exploratory mode of design experimentation were more successful and satisfied with their experience. They described their way of working as first experimenting with rules in an almost random way, and looking for “interesting patterns” to emerge. Once such patterns were identified, students focused on further developing those, as in the work of Yiu Tsz Yan, Kwan Cheuk Yu and Tam Ho Chuen , shown in figure 30. One student, Lai Fan Hei (figure 30, right) framed the two modes of designing as “top-down” and “bottom-up” approaches and worked on ways to combine the two in her urban scale design. This echoes O’Sullivan’s (2000, p. 3) view, who stresses that while “much of the emphasis in CA approaches (…) has been on the emergence of global structure from local events”, many urban phenomena “simply do not emerge solely from local interactions”.

Figure 30: Exploratory design results generated with CA-based design support: Student work by Yiu Tsz Yan (left), Kwan Cheuk Yu (middle) and Tam Ho Chuen (right)

Lai Fan Hei further commented that some rules are not easily translated into simple mathematical operations, and the input settings limit relationships between cells. Most

88

students, however, had expected more unexpected outcomes, typically in terms of intricate volumetric patterns. The CA-based software provided in this implementation required detailed settings to start each generative process and yielded comparatively little unexpected outcomes. As a consequence, the provided CA-based functions were criticised as not dynamic enough, and the functions provided in the CA-based implementation were perceived as too basic. Students expressed their wish for generative functions that would generate greater variety and unexpected outcomes to inspire the architectural design process. At the same time, some students asked for more control and predictability of the generated outcomes.

5.2.6 Discussion Based on the results of the previous software implementation, this research cycle aimed to provide students with more generic CA-based design support in the context of an architectural design studio. Though the scope of this research cycle was limited in terms of time and capabilities of the CA-based software implementation, the final design critique at the end of the week yielded a variety of results and student comments. Those students who decided to experiment with the software adjusted to the CA-supported design process by focusing on explorative processes rather than on pursuing initially determined outcomes. This second implementation indicated that CA could support students in the initial, exploratory design stages by providing them with generic generative, rule-based functions. It however also revealed shortcomings with respect to the too-detailed and time-consuming rule definitions required by the user interface to start the CA-based generative process, which students perceived as disruptive in their design process. Students adjusted to the emergent, “bottom-up” nature of the CA-supported design process by focusing increasingly on open-ended experimentation, and the “discovery” of useful or inspiring patterns, which were then developed further. Once students got used to this design approach, they expressed a desire for increased generative automation of CA-based functions to quickly generate surprising forms. Simultaneously, students requested increased control of the outcomes, which results in a contradiction: How can unpredictable results and control be reconciled? The work of Lai Fan Hei showed a way to resolve this conflict. She used the CA-based rules in systems that she perceived of a “bottom-up” nature, and conventional, “top-down” decisions for those design aspects that could not be easily formalized in this way. According to March (1996), “…rules liberate. They provide the language in which the designer speaks. They give the designer ‘style’. Freedom comes from following the rule. Bucking a rule is simply to follow another.” This liberation, though, seems to apply only to those contexts where

89

rules can be made sufficiently explicit to provide generative design support. In the case of the student who commented that she did not know how to make rules for freedom, which formed her main design concept, this liberation obviously did not occur. In the case of this test implementation, the majority of students however perceived rule-based generation of form as appropriate for design exploration with surprising outcomes. None of the students saw rules as a way to achieve a coherent “style”, though, as suggested by March (1996). The combination of rule-based generative procedures and directed design intentions subsequently became the focus of the following implementation cycle, a generative design workshop at National Cheng Kung University in Tainan, Taiwan. With the exception of Lai Fan Hei, students tended to limit their design processes to the capabilities of the software and did not use conventional modelling to complement and manipulate the generated results. The reason for this may be the limited duration of the studio exercise, such that students could not gain enough experience to decide on ways to combine both ways of working. While rule-based processes can be used to create variety, they may also be regarded as frameworks on a more abstract level. Ho Lung, a student who did not use the CA-based utility, presented CA as a framework: He compared the diversity that can be generated from simple rules to the personal preferences and interpretations by individual human beings. In this sense, rules may be employed in the design of processes instead of answers or results, for their potential to generate richness.

5.2.7 Resulting questions At the outset of this implementation, it was proposed that CA can assist architectural design in the exploration of new building typologies by providing architects with generative functions to create building volumes through the definition and execution of rules. For this purpose, the studio test aimed to provide students with generic CA-based software that allowed the configuration of rules without requiring programming skills. Students initially tended to experiment without a specific goal in mind, and proceeded to more detailed investigation once patterns of particular interest were encountered. Based on the outcomes of this implementation as well as student comments, the main question explored in the following implementation concerns how the demands for control as well as increased automation of processes can be achieved. Students recommended developing the graphical user interface further and relying less on detailed if/then/else semantics to configure rules. A further question relates to how CA-based software can provide outcomes of a more complex geometrical nature and yield unanticipated results.

90

5.3 Tainan generative design workshop 5.3.1 Introduction Results form the previous studio test indicated that students working with generative CAbased design support tended to focus on experimenting with the software without pursuing preconceived results. Student comments in the studio test mostly concerned the nature of the CA-based functions and rule composition, which were perceived as too detailed and disruptive to students’ design processes. Students instead suggested increasing the level of generative automation of CA-based functions, with less required parameter settings. In addition, it was assumed that increased automation and the generation of more complex – and ideally surprising – forms could yield potentially richer design outcomes. In April 2006, the opportunity arose to test a software implementation with graduate architecture students at the Department of Architecture of the National Cheng Kung University (NCKU) in Tainan, Taiwan over the course of five days. The design studio workshop titled Tofu Cubes and Soap Bubbles was conducted in collaboration with Thomas Fischer, who contributed additional generative design software to be tested during the workshop. Seventeen Masters and PhD level postgraduate students took part as members of five design groups. All students were experienced in using a variety of CAD tools. The workshop was seen as an opportunity to investigate whether generative design software could be generalized sufficiently in order to purposefully assist students in their conceptual design processes. While the previous studio test had pursued similar questions, the setting was rather informal and open-ended. The Tainan workshop was seen as an opportunity to examine this issue in a more formal framework. Two generative design support software implementations were tested during the workshop, one of which was the Tofu Automata Generator, the test implementation discussed in this section. The other was the Soap-Bubble Truss Co-Rationaliser, a tool for the generation of irregular space frames developed by Thomas Fischer. A further aim of the workshop was to observe how the two software implementations would be integrated in students’ design processes. As the Tofu Automata Generator was conceptualized as facilitating bottom-up design strategies and the Soap-Bubble Truss Co-Rationaliser was intended to encourage top-down design approaches (for a discussion of the two approaches, see Chapter 1), the initial assumption was that the students would use the two software implementations in a complementary fashion. Six weeks before the workshop, all students were given a list of ten introductory readings in the area of non-standard architecture and generative design. Students were given an overview of generative design approaches in a lecture on the evening of the first workshop day, followed by a question and answer session and an introduction to the tools in 91

a seminar-style setting. All groups were given the same, relatively open design brief, which asked for an extension to the NCKU campus to host additional space for the architecture department. A list of functions and specifications was given to the students to provide a framework for those who might find a vague design brief too challenging. Deviations from and re-interpretations of the brief were nevertheless encouraged according to the students’ interests and no more than preliminary, conceptual results were expected within the short time frame of the workshop. Students were free to utilize any resources and software they wished to use in addition to the Tofu Automata Generator and the Soap Bubble Truss CoRationaliser.

5.3.2 Aims and expected outcomes As a result of the previous studio test, the Tofu Automata Generator was less generic in scope. It focused on providing students with a selection of predefined functions to quickly generate surprising volumetric compositions of simple geometric elements. As a result of the generic objects in the previous implementation, this implementation was geared towards architectural interpretations of outcomes by allowing users to assign “materials” to elements, in addition to the configuration of generative functions. As the Soap Bubble Truss CoRationaliser also emphasized the formal aspects of space frame structures, it was expected that students would interpret the outcomes of the software as physical building forms. Corresponding to the setup of the workshop, generated forms were expected to be composed of concrete building mass and glazed space frame structures. A further point of interest in this workshop was how students combined different design strategies and tools to produce design proposals. To examine the question of whether generative design software can be purposefully passed from the context of their production to different contexts of application, three aspects were initially identified, in terms of which workshop outcomes were considered. The first aspect concerned the distinction of tools into top-down and bottom-up approaches as introduced in Chapter 1. The Tofu Automata Generator was initially regarded as bottom-up oriented and the Soap Bubble Truss Co-Rationaliser as top-down oriented. To assess whether this distinction had an effect on the use of the tools, the workshop participants were asked to rate (on a scale of 1 to 7) whether they used the tools primarily to realize ideas they had before they started using the tool (1) or to generate ideas through exploration and experimentation (7). A further aspect relevant for the support of design processes is that of how a joint creative effort is orchestrated within a group of designers. Kvan (2000) draws a distinction between close-coupled collaboration and loose-coupled co-operation of designers. He

92

argues: “A loose-coupled design process requires a very much different set of tools and conditions to be successful than a close-coupled one” (p. 415). Inverting this argument, it could be expected that there would be a distinct type of tool appropriate for each kind of collaboration. Both software implementations given to students were developed primarily for individual use and hence for processes of loosely-coupled design co-operation. Observations of the degree of which the implementations were used in loose or close coupling were intended to yield indications regarding the degree to which software developers’ intentions shape the mode of software application. For this purpose workshop participants were asked if they used the tools always individually, always working closely with group members or both. According to Glanville’s (1995) distinction of tools and media (as discussed in Section 2.2.1), computers can be used to execute instructions similarly to conventional tools such as hammers and bicycles. Used as a medium, they can lead the user to results that were neither intended nor expected by the toolmaker or the designer, and thus play an interactive role in the conceptual design process. To examine if and in what ways both tools might have acted as media during the workshop, design processes and results of the workshop were examined for results that were different from initial conceptions of the software developers. The workshop was further used to collect open-ended feedback on both functionality and interface of the Tofu Automata Generator. Student work was reviewed in the final design critique on the last day of the workshop. Throughout the workshop, field notes were taken to document observations on the students’ design processes. For the purpose of monitoring students’ use of the software, a framework was developed that allowed the tracking of students’ use of software functions. In addition, a questionnaire containing both multiple-choice and open-ended questions was used to collect data on several aspects: students’ perceptions of interacting with the software, distribution of tasks within design teams and feedback on software functionality. The full questionnaire as well as a report of student feedback can be found in Appendix 2.

5.3.3 Revised proposition CA can support architectural design in the exploration of new building typologies by providing architects with generative functions to create building volumes. Such rules should enable architects to quickly generate surprising results based on relatively few input variables.

93

5.3.4 Implementation Similar to previous software implementation in this study, the Tofu Automata Generator is a 3DStudio MAX script, accessible through the graphical user interface of a 3DStudio MAX utility. The script enables users to generate complex assemblies of white box shapes, hence the name of the software. The Tofu Automata Generator offers several functions aimed to generate form in a bottom-up way, with often unexpected results. The provided generative functions were different from the studio test before as the overall scope of the implementation was more specific. While functions were now capable of generating intricate three-dimensional forms relatively easily, several other aspects of the interface were simplified. The detailed configuration of rules based on an if-then-else structure of the previous implementation was reduced to an interface structure that required less parameters to operate functions. This was intended to reduce the time users needed to spend in defining variables in drop-down menus and numerically.

Figure 31: Tofu Automata Generator quick-start card handed out in the design workshop

The interface is structured in two main blocks (see Figure 31, see also Appendix 1 for a high-resolution version): The first block comprises the sections “define boxes as”, “work with” and “do what”. Two buttons, one for starting a generative sequence (“GO!”) and one 94

for reverting to an earlier step in the sequence (“STEP BACK”) separate the first from the second block of the interface, which provides several sections on parameter settings for previously selected functions. In the “define boxes as” section, box shapes can be defined as one of four materials: “matter”, “void”, “context” and “neutral”. The provision of “materials” was intended as a semantic framework that may be more intuitive to architectural students than the generic objects of the previous implementation by suggesting architectural qualities of generated geometry. The assignment of materials further enables selective application of functions to one element type. As the materials are displayed with different colours and transparencies in the working scene in 3DStudioMAX, they were also intended to facilitate quick visual overview of a scene’s contents. The following “work with” section of the graphical user interface enables users to choose which types of elements the chosen function should be applied to. This section also comprises the settings for an optional neighbourhood range, which is defined as all scene elements that intersect a numerically defined distance from the selected object. The “do what” section gives users a selection of eight predefined functions, “level”, “scale”, “attract”, “repel”, “delete”, “multiply”, “orient on surface”, and “delete intersecting”. These functions need only few additional parameter settings, which can be made in the “parameters” block of the user interface. “multiply” differs from other functions, which operate by modifying existing geometry, such as “scale” or “delete”. Working as a replacement system (as described by Peitgen et al. 1992), “multiply” allows fast generation of intricate patterns composed of box shapes, which then provide the basis for further geometric operations using the remaining functions. Similar to the previous software implementation, the Tofu Automata Generator was intended to permit for intermittent automated and manual design sequences.

Figure 32: Forms generated with the Tofu Automata Generator during the software development phase

95

5.3.5 Results Students’ design results were primarily assessed in tutorials and a final critique at the end of the workshop. The five groups’ design processes were observed at three different levels: field notes, data tracking and design results. Field notes were taken over the course of the workshops, in particular during tutorial interactions, focusing on events and observations that seemed interesting, unexpected or otherwise relevant. Particular attention was paid to the ways students used the software support, which often diverged from the software developers’ intentions. Students’ interactions with the software were tracked in terms of frequency and timing of function use. Before the final critique, a questionnaire was conducted with individual students. After the final critique all digital material produced by all groups during the workshop were collected. Figure 33 illustrates design outcomes of each of the five student groups. All groups designed, presented and discussed original designs on the final day of the workshop.

Figure 33: Samples of workshop results

Of the quantitative data collected during the workshop, only few results were relevant to the further development of this study, as they provided relatively little insight on the students’ use of the software compared to the qualitative observations captured in field notes during the workshop and in the final critique. For this reason, only selected results are discussed in the following. Further details on the data collected during the workshop can be found in Appendix 2. Fifteen participants used the Tofu Automata Generator and fifteen used the Soap Bubble Truss Co-Rationaliser. While the Tofu Automata Generator was intended to

96

facilitate bottom-up design strategies and the Soap Bubble Truss Co-Rationaliser to facilitate a top-down design approach, the participants rated their uses on a scale of 1 to 7 on average 5.1 in the case of the Tofu Automata Generator and 5.5 in the case of the Soap Bubble Truss Co-Rationaliser (1= ”I used the tool to realize ideas I had from the beginning of the workshop”, 7= ”I used it to explore and experiment”, questionnaire item 8). It seems that both software implementations were applied in predominantly bottom-up ways, the one that was thought of as top-down even more so than the one that was regarded as bottom-up. While the Tofu Automata Generator was regarded as supporting single-user dialogues best, thus favouring loosely-coupled design processes as described by Kvan (2000), only one user of the Tofu Automata Generator always used it by himself, four always used it working closely with group members and eight went back and forth between both modes. Measuring the frequency of function use within the Tofu Automata Generator was intended to capture the nature of students’ interaction with the software. As students frequently found ways to use the software in unintended ways, as discussed below, outcomes of this quantitative measuring can only be taken as indicators of the nature of students’ design processes. When comparing the frequency of function use within the Tofu Automata Generator as illustrated in Figure 34 below, “multiply”, “attract” and “repel” were used most. All of these functions are typically used to produce complex and surprising geometries. Contrary to initial expectations, functions that served to adjust and fine-tune such results, such as “level”, “scale” or “delete” were used significantly less.

Figure 34: Function use frequency in the Tofu Automata Generator

97

In the questionnaire (item 9), students were asked to rate the usefulness of each of the Tofu Automata Generator functions on a scale of 1 to 7 (1 = “Useless” to 7 = “Very useful”). Figure 35 below illustrates the ratings given by students. When comparing the results to the actual frequency of function use evident in the tracked interaction data shown in Figure 34 above, some divergence between students’ assessment and actual use are obvious. The function “multiply” is perceived as most useful, with other functions being rated with much less difference among each other than they were actually used. Comparing the perceived usefulness with actual function use seems to indicate students’ desire to create expressive results, with much less effort spent in adjusting them.

Figure 35: Perceived usefulness of functions in the Tofu Automata Generator

The answers given to questionnaire items 5 (Does you final Tofu Automata Generator outcome match your initial design ideas?) and 6 (Did using the Tofu Automata Generator inspire you and help to explore new design ideas?) indicate that while students were often surprised by the outcomes generated with the Tofu Automata Generator, these results were however not necessarily rated as very inspiring or essential in exploring new design ideas. There were at least four cases in which both Soap Bubble Truss Co-Rationaliser and the Tofu Automata Generator were used in ways unanticipated by the software developers (see Figure 36). Group 1 was inspired by forms generated with the Tofu Automata Generator, but then modeled a related form by other means. Group 5 was conceptually inspired by geometrical translations observed in the Tofu Automata Generator, and proceeded to design

98

an adaptive kinetic library system without applying either software. Group 2 used the Soap Bubble Truss Co-Rationaliser to generate an irregular canopy structure in conjunction with other CAD tools and used the Tofu Automata Generator to generate a model of the project’s site context instead of building form. Group 4 found previously ignored ways to obtain “inverted” shapes by exploiting extreme parametric relationships and interpreted the results as furniture and similar interior design elements. Students further requested ways to multiply soap bubble clusters generated with Soap Bubble Truss Co-Rationaliser in the Tofu Automata Generator, which could not be provided before the end of the workshop.

Figure 36: Examples of tool re-appropriation

Of the answers to questionnaire item 24, which asked students for general comments, several replies seem noteworthy. One student commented on his interest in making use of two generative systems and the site as complementary aspects of a design problem, from which to create rules. Similar to answers to questionnaire item 14, students made suggestions to incorporate more realistic materials and a greater diversity of shapes. One

99

student remarked that not all aspects of design can be described by simple shapes and rules, which echoes student comments received in the previous studio experiment. One student further suggested that the Tofu Automata Generator could be used as an analytic tool in the context of site layout planning.

5.3.6 Discussion As a result of the preceding two software implementations, the Tofu Automata Generator diverged further from conventional CA models in several aspects. In contrast to previous implementations in this study, and similar to conventional CA, the types of elements that could be associated with CA-based functions were limited to box shapes in this implementation. This reduction was primarily intended to focus students on generative processes of configurational rule application. The functions available in this software implementation, however, diverged from the previous if/then/else syntax of previous implementations, and required students to set fewer initial parameters in order to quickly generate intricate assemblies of simple shapes. Though neighbourhood definitions were made available as numerically defined “ranges”, functions did not require this setting. Consequently, students made little use of element neighbourhoods when using functions, choosing instead the easiest way to achieve outcomes quickly. The software was used primarily to generate complex assemblies of box shapes with the “multiply” function, thus resembling replacement systems (Peitgen et al. 1992) and L-Systems (as described by Prusinkiewicz and Lindenmayer 1990) more than conventional CA. Overall, students’ comments on the Tofu Automata Generator collected in the questionnaire related primarily to its functionality. This however contrasts with the nature of the final design results, however, which indicated that the conceptual design process seemed to progress in response, but outside of the scope of the software. As initially intended, the increased level of automation of functions incited students to utilize the software to engage in explorative design processes, thereby producing a variety of original design results. Other than initially intended, however, intricate forms generated with the software were often used as conceptual inspirations for further modifications that often resulted in students abandoning or misappropriating the software, as results shown in Figure 36 above illustrate. The misappropriation of the software, however, often fit the design approach of the students better than using the software in the intended way, and led to a variety of original and individual results. Overall, these observations suggested that the limited scope of the software to modelling building form gave students too little opportunity for realizing their ideas. While the “materials” provided in the Tofu Automata Generator were intended to suggest a semantic framework that would guide students in their design processes, students

100

used this only initially and often abandoned it to follow their individual ideas. In the questionnaire, students however rated the use of materials mostly as useful and easy to understand, indicating a positive response to the introduction of a semantic framework for architectural interpretation of three-dimensional compositions of volumes. Preceding the workshop, efforts have been made to create a more rigorous framework for process observation in order to obtain quantitative results in addition to qualitative results. The outcomes of the workshop however demonstrated that the scope of the initial framework for both data logging and questionnaires was too narrow to capture essential observations, which were mainly of a qualitative nature and derived from observations made over the course of the workshop. For this reason, the following two test implementations reverted to qualitative, open-ended data collection methods, mainly through field notes and student interviews. The main findings resulting from the workshop are counter-intuitive to the idea of passing generative design support purposefully from the context of their production to other contexts. Generative design support for conceptual design processes seems to present special challenges. Intentions of the software developer and the user are likely to differ, such that software tends to be used in unanticipated ways. How, then, can designers be provided with helpful generative design support? One possible approach to this dilemma may be to focus on the support of tasks that are sufficiently “pure”, closed-ended and tamed (Rittel and Webber 1984), similar to the way in which CAD packages support tasks of pure geometry. In this case, however, it could be argued that the computer simply executes instructions and thus acts merely as a tool and not as a medium in Glanville’s (1992 and 1994, see also Section 2.2.1) sense and hence does not support the conceptual design process itself. Two further strategies however emerged from the observations made during the workshop. First, the chances for providing generative design support in a directed manner may be increased when developers and users of design support software intended to support conceptual design processes “conspire”, i.e. operate within the same design context or project and share a similar view of the tasks at hand. In the extreme case, the sufficiently skilled designer would make her or his own software as described by Ceccato (1999). Secondly, software developers could find modes of generative design support in which tools are used as intended by their developers, yet support the systematic generation of new thoughts, ideas and understandings in the process of their use, possibly by exploiting ambiguity in conceptual representations in a way sketches have been described to do (see Gross and Do 1996). The second approach outlined above became increasingly important in the two following software implementations in this study. While resulting in outcomes of an unanticipated nature, insights derived from the workshop turned out to be a critical turning point of this study. From an emphasis on design outcomes, the study increasingly focused 101

on the conceptual design process. Results of the workshop were published in a conference paper at CAADRIA 2007 (Fischer and Herr 2007).

5.3.7 Resulting questions The Tofu Automata Generator was intended to support students in the generation of new building typologies by providing generative functions to quickly generate intricate and unanticipated building volumes based on relatively few input variables. While the Tofu Automata Generator enabled form-centred design processes, students tended to transcend the limits of the software by misappropriating it for their individual design aims. Predefined semantic frameworks, intended to suggest physical interpretation of generated forms, seemed to assist students in learning how to use the software, but did not affect the conceptual design process itself. Often, design concepts were based on forms or functions of the provided software, but these provided merely the inspiration for further design development outside of the software. The Tofu Automata Generator implementation thus raised several fundamental questions concerning the scope of CA-based design support. How could CA be applied to architectural design if the focus on form generation seems too limited to accommodate students’ conceptual design processes? How can CA-based design support allow students to introduce personal interpretations and thus support a wider scope of conceptual design development? These questions led to the following implementation, which turned from the generic focus of the previous two implementations to support a postgraduate student in her specific design project.

5.4 KCRC urban automata 5.4.1 Introduction With the limits of the previous focus on CA as generic form generators becoming clear in the evaluation of results of the Tainan workshop, the aim of providing generalizable conceptual design process support was superseded by a focus on providing conceptual design support for specific design processes instead. In addition, the quantitative approach to evaluation aimed for in the Tainan workshop had provided only very limited insight compared to the qualitative, open-ended data collected through participant observation over the course of the workshop. For this implementation cycle, the aim was to work as closely as possible to a specific design process, developing software directly and in constant feedback with a graduate architecture student. The KCRC urban automata implementation was developed to support an individual postgraduate student at The University of Hong Kong, Peggy Louie, in her work for an architectural design studio. Her project aimed to

102

present a proposal for a “new town” in Hong Kong, adjacent to a new KCRC railway station. Peggy approached the project by focusing on the three-dimensional relationships of functions within an urban grid, seeking to “create urban settlements with repeated but varied patterns” (Peggy Louie 24/04/2006, conversation with the author). To introduce variety, she focused on the purposeful generation of patterns, setting up rules to organize the distribution of functions in her urban model. In Peggy’s model, the city is subdivided into a Cartesian grid of basic units, each measuring 5m in length, 5m in width and 3m in height. These basic cellular units are assigned with one of 12 functions: “living”, “working”, “eating”, “entertainment”, “shopping”, “learning”, “recreation”, “relaxation”, “landscape”, “railway”, “station” and “void”. During the design process, functions are placed according to a set of rules determining local neighbourhoods, such as “the cell above a landscape cell must remain empty” or “if a living function is placed next to a working cell, replace living with landscape function”. Placing the functions according to the rules in several layers generated three-dimensional volumes that provided preliminary urban models for the “new town”. Initially, Peggy developed a set of rules and used these to manually generate threedimensional urban volumes in a paper-based sequence (figure 37). These drawings were later translated into AutoCAD and manually extruded into three-dimensional volumes.

Figure 37: Sequence of manual rule execution on paper before software implementation

The paper-based process, however, proved tedious and did not provide enough variants or feedback on the nature of the generated design proposals to support the design process Peggy was aiming at. In late April and early May 2006, CA-based software was developed by the author to enable Peggy to continue her project. In this implementation, CA-based design support was used to generate a complex arrangement of elements based on a set of rules, but also allowed for manual intervention during the generative process. In an initial interview, Peggy stated that she was primarily interested in the exploration of different proposals rather than the deterministic realization of initially defined forms. The role of the CA-based software in this project was to provide basic configurations of cells and functions

103

according to Peggy’s model, which were subject to manual adjustments by Peggy at every step of the generative sequence.

5.4.2 Aims and expected outcomes Peggy’s project was similar to previous CA-based software implementations in this study, in that it focused on the generation of volumetric urban models based on predefined rules. It however differed from the software provided in the Tainan generative design workshop (Section 5.3) as it focused primarily on configurations and relationships of elements rather than the resulting three-dimensional forms. Previous implementations in this study had focused on providing generic design process support, which required students to find ways to integrate generative design results into specific projects – as in the case of the Tainan generative design workshop (Section 5.3), in which students tended to misappropriate generic software for specific purposes. This implementation, in contrast, was developed in close collaboration with the student to support her specific design aims. Outcomes and observations during this implementation were expected to lead to insights into how CAbased design support could be helpful in this particular project. Further unexpected observations, as they occurred in previous implementations, were however also anticipated. Data was collected mainly in the form of field notes and Peggy’s design results. Peggy was interviewed at the start and end of the project.

5.4.3 Revised proposition CA can support architectural design in the exploration of new building types by providing rule-based functions to generate a variety of complex urban or architectural models.

5.4.4 Implementation Peggy’s design approach integrated both bottom-up generative placing of cells and functions according to predetermined rules as well as manual modifications during the generative process. The design process was organized in a sequence of steps, where each step consisted of the generation of one layer of cells in the three-dimensional urban model (see figure 39). Peggy preferred to structure the placing of cells in layers rather than in sections as she perceived this method better enabled her to keep track of plot ratios. The CA-based software was implemented with several fixed rules given by Peggy concerning the neighbourhood relationships between cells that remained unchanged in all generated variants. Unlike conventional CA, cells are placed in a sequence along rows within an initially defined circular area marking the limits of the “new town”, similar to Peggy’s previous paper-based design sequence illustrated in Figure 37 above. Rules and preferences, 104

predefined in the CA-based software, are then used to determine which functions are assigned to cells. The graphical user interface shown in figure 38 gives the user control over parameters that can vary between different "new town" proposals. The "ZONES AND GRID" settings determine the diameter of the initial circular cell pattern that becomes the ground floor of the urban model. The "DEFINE BOXES AS" section enables the user to manually re-assign different functions in the generated grid of cells if needed. The "GENERATE NEXT LAYER" function is used to create a new layer of cell candidates, which are then assigned functions in a next step with the "DIFFERENTIATE" button. To give an overview of the number of cells and functions in the urban model under construction, a "SUMMARY" can be generated.

Figure 38: Graphical user interface of the CA-based software implementation for the KCRC urban automata project

The parameters in the extended menu (figure 38, right) allow general settings at the start of the generative process. They predefine the overall number of cells that can be placed in the model as well as the percentages of this overall number allocated to different functions. To 105

determine plot ratios in a general way, the basic circular area of the urban model is subdivided into three concentric zones, which are used to control the number of vertically stacked cell layers allowed in the “levels for each zone” settings. In combination, these parameters enabled Peggy to create a variety of different starting conditions for her design process, which subsequently often included large extents of manual modifications. Figure 39 illustrates an example generative sequence of a three-dimensional “new town” model.

Figure 39: Sequence of generating an urban new town model in layers

5.4.5 Results The CA-based software became central to Peggy’s design process, as it provided her with a time-efficient generative process that also facilitated quick appraisal of results (figure 40). In her account, final results were achieved by a process that was equally shared between automated rule execution and subsequent manual adaptations. The results of the generative process were often perceived as surprising, with Peggy estimating that of 10 generated proposals, 3 would be surprising to her in some way. Peggy welcomed this extent of surprising results as inspiring impetus to her creative process. Even with the help of the software however, Peggy found it hard to keep control over the large number of cells in each project and the nature of local combinations of functions.

Figure 40: Excerpts from Peggy Louie’s presentation posters illustrating a variety of urban models, generated with emphasis on different functions

Peggy presented her work in the final design critique of her studio project to mixed comments from the reviewers (see Appendix 3 for Peggy’s presentation posters). On the one hand, reviewers appreciated her controlled and straightforward approach to the “new town” proposal. On the other hand, reviewers commented that the differences between functions

106

should have a more fundamental effect on the urban model, which was deemed rather simplistic. The circular urban model, with densities highest around the centre and the proposed KCRC station was further criticized as not innovative enough. Peggy’s emphasis on process resulted in urban models with an emergent quality, and enabled her to present not only one but a variety of proposals. The discussion on her work however mainly centred on the conceptual simplification of urban spaces that Peggy’s work was based on. In Peggy’s case, these reductions were necessary to allow for automation of cells in a homogeneous Cartesian grid but were interpreted differently by Peggy herself and the reviewers in the design critique. Peggy intended the generated shapes to be intermediate “starting points” for a further process of architectural interpretation that would focus on spatial qualities instead of the relationship and distribution of functions. In her presentation, however, Peggy presented some images that illustrated the generated forms as if they were final urban models (figure 41, see also Appendix 3). This form of presentation led reviewers to interpret the models as a “new town” consisting of stacked box volumes while Peggy had chosen boxes not to represent form but to provide neutral containers for functions.

Figure 41: Peggy’s conceptual urban model presented as urban form

After finishing the project, Peggy suggested future improvements to the software. Instead of simple boxes, the implementation should be able to combine three-dimensional shapes to introduce more variety. While Peggy emphasized that she saw homogeneous cells as a good starting point for distributing functions, she also suggested to allow replacement of certain cell types with other shapes at a later design stage. She also remarked that different element types and geometries could result in intersections, which she felt could be a positive impetus for further refining the urban model.

5.4.6 Discussion Outcomes and observations from the previous Tainan generative design workshop had challenged the assumption that CA-based software could support architectural design processes by providing generic form generating functions. This implementation cycle 107

focused instead on the support of an individual postgraduate student in her design work. Compared to the Tainan generative design workshop, this implementation featured a rigid Cartesian grid lattice similar to conventional CA. The implementation focused on the process of placing and assigning functions to cells in relation to a set of rules, with less emphasis on resulting form. It enabled Peggy to pursue her design project by automating rule-based sequences of the design process while allowing her to manually adapt intermediate outcomes. As such, this implementation seemed to confirm the utility of CAbased processes as optional design “move” as proposed in Chapter 4. In the case of this implementation, however, automation of the rule-based design process sequences based on abstract box shapes and grid lattices however also entailed a number of simplifications that were criticized by reviewers during the final critique of the studio as well as by Peggy herself. The criticisms revolved mainly around the choice of simple box shapes as basic units for the urban model, and the arrangement of the boxes in a rigid Cartesian grid. While Peggy’s intention was to generate diagrams of urban context to be further interpreted when translating them into form, the cube-based volumes of the graphical representation invited the misconception of the three-dimensional models as directly representing physical form. Peggy’s demand for a “replace” function that would selectively substitute boxes with a particular identity with different element types further establishes the diagrammatic nature of the visual representation. While elements may be exchanged for other elements of different shapes, meaning is primarily derived from the relationship of a particular element to its neighbours. The aspect of representation and interpretation of shapes generated with CA-based functions had not been specifically addressed in previous implementations in this study and presented one of the main outcomes of this implementation cycle. It opened up a new research direction that focused increasingly on the value of interpretation and diagrammatic representation of CA-based visual representations as conceptual design support. As a result, the following implementation cycle concentrated on aspects of interpretation and element relationships rather than on the generation or representation of form.

5.4.7 Resulting questions While previous implementations had focused on providing generic CA-based functions for the generation of physical building form, the KCRC Urban Automata implementation focused instead on the support of an individual postgraduate student in her design work. Based on the results of this implementation, a further possibility for CA-based design support emerged. The generated forms were not intended to represent physical building form, but concentrated on more abstract ways of representing urban models. The KCRC

108

Urban Automata results primarily concerned the three-dimensional relationship of functions within an urban context. To produce physical form, these diagrammatic models required an additional step of architectural interpretation. The capacity of CA-based design support to integrate diagrammatic representations for conceptual design processes presented an essential new insight in this study. Accordingly, the following implementation focused on further developing these aspects: How could diagrams and CA-based rules be integrated in a more generic way to support conceptual architectural design processes?

5.5 Algogram 5.5.1 Introduction In response to the shift of focus that had resulted from evaluation of field notes as well as design critics’ feedback over the course of the previous KCRC urban automata implementation cycle, this implementation primarily addressed aspects of representation and interpretation as central to the aim of supporting conceptual design processes. The software implementation developed for this implementation cycle was named Algogram, as it combined CA-based generative algorithms and aspects of conceptual diagrams as they are commonly used in architectural design. As discussed in Sections 2.2.3 and 2.2.4, conceptual diagrams tend to emphasize relationships of elements rather than form, which relates to a similar emphasis in CA systems. When introducing CA as design process support, CA may thus be used to provide designers with rule-based diagrammatic representations to aid in the early, conceptual design stages. Algogram provides design support for the conceptual design of architectural programmes. It has been developed as a design aid that explores the potential of linking generative design, diagrams and cognitive research, resulting in the concept of “automated diagrams”. In the context of this study, the term “automated” describes the ability of CAbased processes to respond to configurational changes in diagrammatic representations without requiring continuous input from an operator. As discussed in Sections 2.2.3 and 2.2.4, ambiguity of representations and open-ended interpretation by the designer are recognized as central to early, conceptual design. Ambiguity, however, is a property attributed by the perceiving individual and indicates a lack or indeterminacy of codes for interpretation. For this reason, ambiguity is strongly context dependent. In this implementation cycle, the role of the computer is primarily to provide automated representations –automated diagrams – that support thinking and reflection in terms of relationships. Supporting design processes through automated diagrams does not necessarily imply the generation of static diagrams, but describes the process of working with diagrammatic representations that are able to respond to modifications based on rule-based 109

relationships of elements within the diagram. Algogram aims to give designers an opportunity to work with generative CA-based processes while avoiding determining outcomes in terms of form too early in the design process. It provides a generic way of representing architectural functions and their relationships, which is related to both bubble diagrams - not so much in their functional, but in their generative capacity as described by Emmons (2006), and Venn diagrams (for a discussion of both diagram types, see Section 2.2.4). Both diagram types are well-known and facilitate quick and visual understanding of the graphic representations used in the software. Automated diagrams are not limited to representing physical shape but potentially allow for multiple interpretations and mappings. In this implementation, they are used to support idea development during the early design process, when concept framing and reframing are more important than thinking about detailed building form (see Goel 1995, p. 193 ff). Two aspects are central to the concept of automated diagrams: First, abstract and somewhat ambiguous diagrammatic representations can suggest issues and perspectives for consideration without imposing solutions (Gaver et al. 2003, p. 240). Second, the automated component of such diagrams may be used to give such diagrammatic representations the capability to actively respond to configurational changes initiated by the designer. In this approach, the computer is not utilized merely as a tool to execute predetermined and deterministic commands but as medium in the sense of Glanville (1992, see also Section 2.2.1). Algogram was specifically developed for an undergraduate design studio at The University of Hong Kong in October 2006. The architectural approach taken in the studio project - and implemented in Algogram - seeks to evade the limits of prescriptive typologies developed from the modernist motto of “form follows function”, exemplified by the examples given in AJ Metric or Neufert books. Following these examples likely results in buildings based on preconceptions, which hampers innovation and prevents re-interpretation of architectural programmes. Instead of solving design problems as quickly as possible, students were encouraged to re-think the initial problem statement, with the intention to lead students to re-frame the given problem. During the design studio, Algogram was used by a group of nine second year undergraduate students, who had only little experience in using CAAD software. The purpose of this implementation cycle was to investigate two aspects of using Algogram in the conceptual design stages: first, how students integrated the software into their individual design processes, and second, how this affected students’ design results. The studio comprised several other student groups as well, who did not use Algogram. The project brief for the studio called for the design of a school for a given site in Hong Kong, with particular consideration of urban and landscape context. The students were introduced to Algogram 110

and 3DStudio MAX during the early, conceptual design phase, which lasted for about two weeks. At this point, most students switched to traditional sketching and drawing tools for developing both programme and physical form of their buildings in greater detail. After the concept development phase, students were interviewed for their experiences during the design process as well as for their opinions on the usefulness of the software and suggestions for improvements.

5.5.2 Aims and expected outcomes Algogram was intended to support students in their conceptual design processes by providing visual representations that encouraged individual interpretations. For this reason, visual representations in Algogram limit graphic elements to simple spheres. Abstract spheres were intended to provide representations without definite encodings or predefined interpretations, such that students would be required to attach individual interpretations. Spheres were chosen over the box shapes used in the previous implementation, as boxes were too easily understood as depicting physical building form. The choice of spheres as basic elements was further expected to emphasize the relationships among individual spheres. In this implementation, rules were again custom-configured in an if/then/else structure. The expectation for this implementation was that students would use Algogram to support their conceptual design processes in several ways. First, the representations provided by Algogram were intended to extend students’ conceptual design stage in order to allow a more thorough exploration of ideas and to prevent premature decisions. In terms of design process, this extended period of conceptual diagramming was aimed at encouraging the initial framing and re-framing of design problems instead of solving a problem as quickly as possible. In terms of architectural design approach, this strategy aimed to increase students’ awareness of interactions between functions and their role in conceptualizing new and context-specific architectural typologies. The expected outcome in the studio test was for students to engage in explorative design processes, negotiating between definitions of element relationships through rules on the one hand and individual interpretation of ambiguous graphical representations on the other hand. Data on the studio test was collected in form of student results, field notes, samples from other second year students who did not use Algogram, interview feedback as well as student sketches produced during the studio.

111

5.5.3 Revised Proposition CA can support architectural design in the conceptual design stages by providing architects with automated diagrams: graphic representations that consist of abstract and simple elements that encourage individual interpretations and whose relationships are defined by rules.

While the revised proposition outlined above is of a more general scope, the development of Algogram focused specifically on architectural functions. This aim was derived in part from the subject of the design studio, which centred around the integration of a school building and its urban context. Algogram was developed to avoid the separate consideration of form and function, and instead aimed to support students to think at a more abstract, conceptual level in order to integrate both aspects into coherent design concepts.

5.5.4 Implementation Similar to the four previous software implementations, Algogram was implemented as a scripted utility for 3DStudioMAX (Figure 42) as an alternative to manual modeling. Architectural functions are represented as spheres instead of cubes or squares to avoid premature visualizing of diagrams as possible building forms. Spheres relate more to diagrammatic representations of functions already known to students, such as bubble or Venn diagrams, while box shapes could easily be interpreted as physical building form. Representations in Algogram were intended to be somewhat ambiguous, such that students would be encouraged to reinterpret the diagram while developing their design concepts. The diagrammatic representations can be manipulated either manually or by establishing automated relationships between elements by defining rules. Rules in Algogram are used to numerically control relative positions of spheres and their intersections in three dimensions. Within the framework of the diagram, meaning is established by adding user-defined text labels and colours to generic spheres. To translate representations into architectural form, users need to interpret the resulting diagrams, which remain at a relatively abstract level to encourage individual design solutions.

112

Figure 42: Algogram user interface

Algogram diagrams are composed from initially few and simple functions, which are gradually differentiated throughout the initial design stages. This differentiation affects sizes, labels and colours of the spheres in diagrams as well as their relative positions. Algogram is intended to encourage students to think about buildings within their context by considering both in terms of interconnected functions. In the design studio setting, this approach seeks to guide students to find individual answers of how their school designs contribute to their context and community as part of their urban setting. Algogram further builds on the concept that architectural programmes are rarely stable and often need to be changed or reconfigured throughout the design process. The software supports experimentation with combinations of functions that may co-exist and develop in unusual ways to create different and often unpredictable results. To heighten students’ awareness of the potential of interactions between functions, we introduced the term “hybrid”. Hybrids in this context are opportunities for creating spaces that can be adapted for different uses and allow space to be reinterpreted for different functions. This strategy further avoids the separation of function and form or the prioritizing of one over the other, instead encouraging inclusive thinking. Such spaces are not typically found in traditional architectural programmes and can be generated by adjoining architectural functions that create unconventional synergy. In this way, a typical hybrid may for example be created by two overlapping spheres labeled “performance” and “water”. In diagrams produced with Algogram (“algograms”), hybrids 113

are a source of ambiguity intended to stimulate individual interpretation by the students, both during the conceptual design stages and also when translating into architectural form at a later stage in the design process. The three main components of the user interface are graphical representation functions, analysis functions and rules. To compose an “algogram”, users start by drawing spheres, which are then assigned colors from a predefined selection in the “assign colours & edit labels” window. Colors can be labeled with customizable names, usually indicating architectural programme items. Once assigned with colors, diagrams consisting of spheres can be analyzed for their properties such as composition, sphere volumes or distance between spheres. Diagrams can also be decomposed and presented as a chart overview with the “analysis” option (Figure 43, left). Spheres can further be displayed with different degrees of transparencies, depending on the number of intersections with other spheres (Figure 43, right).

Figure 43: Visual analysis of Algogram diagram with overview chart (left) and different transparencies according to sphere intersections (right)

If spheres intersect, hybrids can be generated automatically. Hybrids are expressed as newly created spheres located in the centre of the overlap of two spheres. They are of mixed colours, according to the two original overlapping spheres. Sphere positions and properties can be manipulated either manually or with the help of custom configurable rules, which enable users to transform spheres in size or position according to their neighbours. Rules can be configured by choosing from a set of basic selections following an if / then logic, with additional, more detailed parameters. The “if” condition refers to intersections of particular sphere types, while the “then” instruction offers geometrical transformations such as move or scale, deleting of spheres or the change of sphere labels into other labels. 114

5.5.5 Results Students responded well to the software and readily developed their concepts using the abstract representations in Algogram, even without prior CAAD knowledge. As Algogram provides only abstract sphere geometries, students had to conceptualize their school in terms of programme, without considering form (see Figure 44).

Figure 44: Algograms by Finnie Yu (left), Ho Wing Ho (middle), and Claire Fu (right)

Design outcomes of student projects in the group using Algogram were slightly different in nature than results from other student groups in the same studio project. This is likely an effect of the particular design approach encouraged, with an extended conceptual design phase and further enforced by the use of Algogram. Since student results tend to be shaped by the varying teaching styles and preferences of design tutors, however, this assessment of student work from groups working with or without Algogram is merely indicative. It is based on samples of student outcomes from three other groups as well as field notes from these groups’ design critiques.

Figure 45: School design by Abby Chan: bubble diagram and final building plan

Students in the group using Algogram were encouraged to examine possibilities contained within the building programme and explored a variety of links between building programme 115

and the surrounding urban context. Design proposals from other groups, in contrast, tended to separate functions rather than considering their potential interactions within a building, as the school designs by Abby Chan and Dennis Fung illustrate (Figure 45 and 46). Students instead focused either on developing unconventional exterior building form or creating clear and efficient building plans. Reviewers of other groups’ work often criticized the lack of reflection of urban context, which students tended to consider only in terms of composition, with functional aspects frequently ignored.

Figure 46: School design by Lui Kam Fung, designed without using Algogram

The focus on functions in the student group that used Algogram seems to have encouraged students to integrate their design concepts more closely with surrounding urban and landscape context, with many diagrams emphasizing sphere labels such as water, hill, planting, public or private. Most students in the group using Algogram had strong individual design concepts that came out of a reconsideration of conventional building programmes. Students subsequently used these programme-oriented concepts to generate unique and site specific building typologies, as the dancing school of Athena Lee demonstrates (Figure 47). In contrast to previous applications of CA to architectural design, which often employ CA as self-contained system to generate physical building form, Algogram could accommodate architectural programmes within their urban context. It thus encouraged students to consider the relationship of buildings and their context, which led to innovative ways to integrate both.

116

Figure 47: Dancing school by Athena Lee, conceptual diagrams and final building plans

When switching to other design tools and media to develop building form, most students used the latest stages of their algograms to guide their form development processes (figure 48). In many cases, buildings closely resemble the three-dimensional concept diagrams in terms of composition, not however in terms of building form. It appears that after the conceptual diagramming phase, concepts were regarded as sufficiently fixed, and students focused mainly on the translation of diagrams into form. In the interviews, all students described using the software as generally helpful for their design processes, while the reasons given varied. Algograms were seen as useful in finding and organizing relationships between functions within a building programme. They were also described as reminders of design potential, especially when considering and interpreting hybrids.

117

Figure 48: Translation of algograms into building form by Finnie Yu

The simplicity of the graphical representation was also perceived as helpful, since it allowed for conceptual clarity in the beginning of the design process. Most students appreciated the hybrids as source of inspiration, often describing it as the most important feature of Algogram. For this reason, the visual notation of Algogram was often used in conventional paper-based sketches, and continued to be used for both design development and explanation to tutors and critics well after students had stopped using the software (see figure 49).

Figure 49: Studies of function overlaps by Adrian Lo using the Algogram notation

It seems that students were happy with the ambiguity of hybrids when interpreting entire diagrams, but when hybrids were separated from their context, such as in the analysis chart overview, students perceived them as confusing. Sphere sizes in Algogram can be interpreted in several ways. Initially, students were introduced to sphere sizes as indicators of physical volumes allocated to a particular function. As their design progressed, however, students increasingly developed their own understandings. Many students switched to an interpretation that saw sphere sizes as a sign of importance and relative sphere distances as indicator of mutual relevance of functions in a building programme. Students also reported on frequently using both types of interpretation in the same diagram. Of the analysis functions, the chart overview was described as especially useful, as it allows a visual overview of the number and type of spheres contained within a diagram. The transparency option, while considered useful, was not used frequently. The rules function received mixed comments: While some students regarded rules as very important, especially in the early diagramming stages, most students considered the 118

interface for rule configuration in Algogram too restrictive and exact. They suggested providing rules that could be used in more intuitive ways in the early design stages. The most frequently mentioned drawback to the use of rules, however, was that similar to rules in classic CA systems, rules in Algogram affected all spheres of the same type in the same way. After an initial diagramming stage, in which only one or few spheres of a given type exist at the same time, algograms quickly become more differentiated as relationships between architectural functions are further developed. In a more differentiated diagram, however, uniform rules do not apply any more. In the final design critique, the majority of students explained their design process as well as their concepts using algograms in their presentations, with additional conceptual diagrams used in translating diagrams into building form. Students often used vocabulary introduced through Algogram to explain their design concepts. Similarly, student sketch books often showed hand-drawn diagrams using circles and labels similar to those in the software. In some cases, students reverted back to this notation even later in the design process when revising their design schemes at a fundamental level. Students typically described algograms as helpful in the three-dimensional development of their schemes, and as more appropriate to concept development than bubble diagrams. The latter were thought of as appropriate for functional planning issues where architectural programme elements are considered in terms of numbers rather than spatial qualities. Algogram helped students to develop a better understanding of the role of architecture within its urban context: projects developed with Algogram typically transcended building programmes but sought the integration of buildings and their urban context, which was the aim of the studio project. According to the interviews, none of the students felt limited by the software in pursuing individual design ideas. Most positive comments on Algogram relate to its potential to provide students with representations of their design concepts while at the same time giving enough room for individual interpretations. During the final design critique, it became apparent that the same properties of algograms that are perceived useful by students during their design processes can result in ambiguous and vague elements in presentations that other students, tutors or critics not familiar with the particular design project find difficult to follow. Algogram teaches students to recognize the value of ambiguity in design representations during the design process, but also requires students to consciously reduce ambiguity in presentation materials intended to communicate the design to others.

5.5.6 Discussion Further developing the abstract and conceptual aspects of the KCRC application, Algogram was intended to support students in their conceptual design processes by providing visual

119

representations that encourage individual interpretations. As a result, the term automated diagrams was used to describe the nature of the approach to CA as conceptual design support. The studio test aimed at collecting open-ended qualitative feedback on how the software integrated with the students’ design processes and aims. Abstract, diagrammatic and ambiguous representations were found to be helpful in the early design stages, as they encouraged students to develop multiple individual interpretations and allow for an extended process of framing and re-framing design problems. This led to a prolonged conceptual development stage and prevented a premature transition to the level of physical building shape. Students using Algogram developed building typologies that emphasized the mutual relationship of functions within the building as well as relationships between the building and its site context. The choice of spheres as visual representations was motivated by the need to avoid the premature interpretation of conceptual diagrams into physical building form. Comments obtained from student interviews indicate that students embraced ambiguity resulting from abstracted representations in Algogram diagrams to develop a variety of individual interpretations. Sphere sizes in Algogram can be interpreted in a variety of ways: as physical volumes or as importance attributed to a particular function. Students also reported frequent use of mixed representations, interpreting sphere sizes in some cases as representing physical size, in some cases as representing importance and in yet other cases in yet other ways - all within the same “algogram”. In this sense, ambiguity resulting from students’ interpretations of algograms encourages and supports individual construction of meaning and design thinking, and provides design support closely related to that of conventional paper-based diagrams. In the interviews, students commented positively on their experience with using abstract sphere representations. It seems that during the initial conceptual design stages concepts were sufficiently abstract to be embodied in algograms, but students remarked that once the design process progressed, they felt that it would be useful to integrate more information, for example by adding images to spheres, or by replacing spheres with other, more representational shapes. These needs, however, were voiced at a design stage when basic conceptual design decisions were already made and students’ attention shifted from concepts to building form – a design stage when diagrams gradually give way to sketches differentiating building form (as discussed in Sections 2.2.3 and 2.2.4). While aiding students’ design processes in this way, the level of abstraction in even relatively simple configurations of spheres rendered outcome presentations to outsiders surprisingly challenging. This indicates that students used Algogram in their individual thinking processes rather than as communicative devices, and conforms with Dogan and Nersessian’s (2002) description of conceptual diagrams as discussed in Section 2.2.4. This role of 120

algograms is further confirmed by the observation that students used visual and verbal representations adopted from Algogram in their sketch books when thinking about their designs. In some cases, students reverted to Algogram-like notations when they had already progressed to a rather form-oriented design stage, but were reconsidering design decisions at a more fundamental level. The architectural aim of using Algogram in the design studio was to extended students’ conceptual design phase and encourage students to explore and reconsider the interactions between functions in a building. Judging from results and process observations during the design studio, Algogram had a positive impact on both aspects of students’ design projects. While previous implementations in this study emphasized the generation of form, Algogram was developed with a focus on design process. In contrast to earlier assumptions, CA-based software was considered as design support by relying on the dynamics it could provide to graphical representations. The role of the specific representation format was limited to encouraging students’ ability to interpret and associate freely. Students were initially expected to engage in explorative design processes, negotiating between definitions of element relationships through rules on the one hand and individual interpretation of ambiguous graphical representations on the other hand. Results obtained from the studio test however demonstrate that the generative capacity of algograms stemmed primarily from the visual representations used in Algogram, in particular the hybrids. In comparison to the utility of abstract and partly ambiguous visual representations, CA-based rules as implemented in Algogram seem to be marginalized, in particular past the initial diagramming stages. The student interviews yield two reasons for this under-use of rules. First, rule sets were perceived as helpful in the early setup of conceptual diagrams, but students criticized uniform rules as inadequate for more differentiated diagrams produced later in the design process. Second, rule configuration was perceived as too disruptive to the students’ design processes. They instead preferred intuitive manipulation of geometry and avoided numeric parameter settings. Students commented that rules should be implemented to be used in a more intuitive way, in particular without manual setting of parameters in numeric form, as this interrupts the design process. This criticism echoes Schön’s (1988) description of rules in design as largely implicit, diverse, contextually dependent and subject to exceptions and modifications. Designers seem to be unlikely to accept formal rule definitions in if/then/else semantics as offered in Algogram. This leads to a question for further research: How can rules be integrated into visual representations in a somewhat less precise and more intuitively controllable way, such that relationships between elements can be manipulated without requiring detailed definitions or numerical input? An open question also remains on how initially uniform rule sets can become more local and specific during

121

the generative design process to allow for processes of differentiation in automated diagrams. Overall, Algogram supported students not only in developing individual design solutions, but also in exploring architectural typologies beyond their initial preconceptions. Students embraced the open-ended aspects of the software, in particular the ambiguity of hybrids as well as individual interpretation of sphere sizes and positions in abstract graphic representations. In comparison to the previous software implementations, students working with Algogram focused more on concept development than building form. The step of translating conceptual diagrams into form, however, appeared to be of considerable difficulty to the undergraduate students. In the development of Algogram, it was attempted to clear visual representations of meaning as far as possible in order to elicit interpretations, but the software remains based on an implicit structure that is likely to influence the attribution of meaning by the users of the software. In this way, Algogram is not entirely generic but is likely to relate to specific problem areas in architecture – in this case, to conceptual programme design.

5.5.7 Resulting questions The studio application of Algogram was perceived as helpful by the students using the software during their conceptual design processes. As the last implementation in this study, implications and questions resulting from Algogram are discussed in further detail in Chapter 6. These relate primarily to evaluation criteria regarding students’ perception of software utility and their experiences in applying the software in their design processes.

5.6 Summary: From form generators to automated diagrams From an initial focus on supporting design with CA-based form generators, software implementations in this study increasingly developed to embrace representations of a diagrammatic nature. In the first implementation, the Cero9 remodelling, CA were regarded as a method to provide design support for the generation of form, in particular for tasks involving some degree of repetition among larger numbers of elements. The focus of this implementation was on the capacity of the proposed extended CA model to capture forms and cell relationships that were different from conventional CA. Results of the remodelling of an existing architectural project supported the initially proposed CA-supported design process, which integrated CA-based design sequences with manual user modifications over the course of the design process. The implementation, however, was limited to the remodelling of an existing architectural project, and was thus confined to a specific and rather well-defined context. While the remodelling process yielded positive outcomes, the 122

question for the following implementation concerned the question of how generic CA-based design support could be provided to enable open-ended design processes with unanticipated results. In the next implementation cycle, postgraduate students were provided with generic CA-based design support and used it in their work for a design studio. While students used the CA-based software to engage in open-ended experimental design processes, they focused on the generation of complex and unexpected shapes. Instead of attempting to realize initially conceived form, students mostly concentrated on the discovery of useful or inspiring patterns, which were then developed further. Though students produced a variety of promising design results, they also criticized the too-detailed and time-consuming rule definitions required by the user interface. At the end of the one-week studio exercise, students requested functions that could generate complex assemblies of shapes in unanticipated ways more efficiently. At the same time, students however requested increased control of the outcomes than was possible with the generic if/then/else syntax for rule composition provided in the user interface. These student comments informed the development of the following software implementation, which was tested by postgraduate students in a generative design workshop at National Cheng Kung University, Tainan, Taiwan. As a result of the two previous implementations, the CA-based design support diverged further from conventional CA in that it featured predefined functions controlled through user-defined parameters rather than explicit rule definition. The functionality of the software thus bears much similarity to replacement systems or L-systems. Students responded positively to the introduction of a semantic framework in the form of “materials” instead of abstract cell IDs as in conventional CA, which facilitated the architectural interpretation of generated results. While students initially used the software to generate forms as intended, the main finding in this implementation was that such forms were often used as conceptual inspirations for further modifications, which often resulted in students abandoning or misappropriating the software. These observations suggested that the software was too limited in scope in that merely focusing on the generation of form gave students too little opportunity for realizing their individual design ideas. With this finding, the next two implementations in this study focused increasingly on diagrammatic representations and interpretation as central to conceptual design, and the design process was gradually emphasized over its formal outcomes. From the generic aims of the two previous implementations, the KCRC urban automata implementation concentrated on the support of an individual postgraduate student. The software developed for her design project focused on the generation of a variety of design proposals for a “new town”. CA-based design support was used to automatically 123

generate proposals of urban models according to a set of rules initially defined by the student. This design approach entailed several simplifications in order to apply rule-based generative processes, such that urban models were composed of box shaped units within rigid Cartesian grids. While the student had intended these models as diagrams of urban functions and their three-dimensional relationships, to be re-interpreted architecturally to derive urban form, the models were too easily misinterpreted as representing physical form. Similar to the results of the Tainan workshop before, this implementation further emphasized the relevance of interpretation of visual representations during the conceptual design process. The following and last implementation in this study thus focused on integrating CA-based functions with visual representations of a diagrammatic nature. Algogram, the last software implementation in this study, was developed to support undergraduate students in the conceptual design phase of an architectural design studio. The software focused on the design of architectural programmes and was intended to encourage students to consider alternative relationships of functions within architectural programmes. It provided students with automated diagrams: abstract and ambiguous visual representations to encourage individual interpretations and additional rules to allow for rulebased relationships between elements of the visual representation. Students were able to develop a broad range of individual and innovative design proposals and commented positively on their experience with using the software. As intended, the extended conceptual design phase led to well-integrated design proposals and frequently to the invention of new building typologies. Both abstract diagrammatic representations and a focus on design process seem to have contributed positively to students’ design processes and outcomes. Compared to the utility of the visual representations employed, however, CA-based rules as implemented in the software were marginalized, in particular past the initial design stages. While the diagrammatic component of the proposed automated diagrams was applied rather successfully in this studio project, the automated component was under-used. Although students were interested in using rules in their design process, they also commented that rules should be configured in a less precise and more intuitive way in order to be used during the conceptual design stages.

124

Chapter 6. Discussion This chapter re-examines the initially proposed extended CA model in the light of observations and insights derived from the five software implementations summarized in Section 5.6. The discussion contrasts the focus on form which dominated previous applications of CA to architectural design with the emphasis on individual re-interpretation of visual representations and a focus on element relationships that emerged over the course of this study. The resulting new perspective on CA as architectural design support proposes CA-based automated diagrams to support conceptual architectural design processes. Following a brief summary of the research approach and process in Section 6.1, the new perspective on supporting designing and CA as design support that were developed in this study are outlined in Sections 6.2 and 6.3. These sections further link back the outcomes of this study to previous work as well as initial assumptions on the potential of CA-based design support in conceptual architectural design. The concept of automated diagrams, as introduced in Section 5.5, is discussed in relation to literature on sketches and diagrams as architectural design support in Section 6.4. This new view is contrasted with initial assumptions that focused on the use of CA to generate representations of physical building form. The implications and limitations of this work are discussed in Section 6.5 and 6.6, whereas Section 6.7 presents contributions to the field. 6.8 concludes with an outlook on future work in the context of this study.

125

6.1 Summary: The research process An initial literature review of approaches to apply CA to architectural design in Section 2.3.3 identified several shortcomings of previous work in the field. Applications of CA to architectural design tend to employ CA as a method to generate intricate patterns composed of simple shapes (Chase 2005, p. 692). While they are typically applied in the early, conceptual design stages, CA-based design approaches are rarely linked to related areas of inquiry that focus on conceptual design support, as for example research on computers and creativity, as discussed in Section 2.3, and research on the role of conventional sketching in conceptual design reviewed in Sections 2.2.3 and 2.2.4. Instead, CA tend to be considered as generative mechanism to produce representations of physical architectural form. Furthermore, previous work in the field consists of a limited number of specific projects and lacks a common conceptual framework. This study aims to explore a wider variety of applications of CA to architectural design, focusing on the early, conceptual design stages, and seeks to contribute an extended CA model as a basis for further research. Based on the literature review, this study set out to explore the question: How can CA support the conceptual stages of the architectural design process? From this main research question, two sub-questions were derived:

1) How can conventional CA models be adapted to architectural design? 2) In what ways would such adapted CA fit into the conceptual design process?

An initial proposition proposed that modifications of conventional CA were necessary in order to apply conventional CA to conceptual architectural design processes. From this proposition, an extended CA model was developed in Chapter 4 that concentrated on two aspects: It proposed extensions to conventional CA models required for modelling architectural forms and contexts, and it outlined an extension of Schön’s model of the design process that integrates CA as optional design “moves” within a cyclical, reflective conceptual design process. In order to further develop the initially proposed extended CA model, an explorative research process was initiated that employed action research as the method of inquiry. As this study aimed to investigate new approaches to CA as conceptual design support through a cyclic, open-ended research process, action research was adopted as research method. To this end, a series of five implementation cycles was carried out, each of which consisted of a proposition that guided the development and application of CA-based software. These software implementations were subsequently applied by architectural students in design workshop and studio settings. In this process, software was regarded as means for exploring 126

a particular design approach. It was not the aim of this study to produce and optimize a particular design tool, but to investigate CA-based design support in different roles in the design process. In order to develop an approach to CA-based support for the conceptual stage of architectural design, this study sought primarily qualitative and open-ended feedback from the five implementation cycles. Insight gained from the implementations led to the gradual development of an approach to CA that emphasized the role of diagrammatic representations and individual interpretations over the initial focus on representational form. This new perspective on CA took shape in the fourth and in particular in the fifth implementation cycle, the development and application of Algogram. As a result of the previous implementations, Algogram had been developed to a level where it could support a group of nine undergraduate students in their individual design work during the conceptual stages of a studio project. Following the studio application of Algogram, the series of implementation cycles was concluded at a point when further developments would have focused increasingly on applications that are specific to given architectural design projects. More specific explorations are seen as necessary and are put forward as opportunities for future research.

6.2 Reconsidering support for designing Over the course of this study, the research focus changed from one on design outcomes to one on design processes. Along with this change, the author’s underlying understanding of the nature of designing transformed. Initially, I understood designing as an instrumental process to produce results in which software support plays the role of a technological amplifier. In the process of developing understanding based on observations of applied design processes, this view however seemed too limited to give an account of the dynamics of designing. Observations made during and outcomes of the third implementation cycle, the Tainan generative design workshop reported in Section 5.3, indicate that designers tend to develop their own understanding of design challenges and along with it, an understanding of how software support fits into their design processes. These understandings were observed to be typically unique to individual students and different from the software developers’ intentions. Observations made during the fourth implementation cycle, the KCRC urban automata project reported in Section 5.4, further support the view that designing is not so much concerned with thinking in terms of “objective” geometric form but rather with personal and subjective interpretations of (computer-supported) representations. This insight led the author to reconsider implications of Schön’s conversational model of the design process (as discussed in Section 2.1.3 and 4.2): Not only can designing be described in

127

terms of a process that is dialogical in nature, but the role or functioning of materials used to support this dialogue seems to be attributed by individuals through subjective interpretation. Subjective interpretation, or construction of meaning, lies at the heart of constructivist theory, which forms the basis of Glanville’s (1999) as well as Schön’s (1983, 1985) theories of designing. Schön’s interest in and perspective on practitioners’ activities as individual construction of understanding, according to (Kinsella 2006), have constructivist underpinnings and are based on Goodman’s (1978) constructivist description of individual “world-making”. According to this view, reflections on designing are appropriately based on a constructivist epistemology instead of a positivist epistemology as it underlies conventional science. While these arguments were known at the start of this study, their implications did not become obvious to the author until observing and reflecting on the third and fourth action research cycles, resulting in a further distancing from positivist views on design research. The constructivist view emphasises individual construction of meaning, which casts a new light on computer support for conceptual design processes. When developing software applications for this purpose, differences between digital encodings and human ways of constructing meaning from such encodings need to be acknowledged. Digital computers require clearly defined, unambiguous and constant encodings, whereas human understanding involves interpretation, which tolerates and even necessitates ambiguous or multiple encodings, context dependency, personal associations and other factors that are neither constant nor predictable. According to Goel (1995), these differences are the reasons for the inability of conventional cognitive theory – which he terms the “computational theory of mind” – to account for design processes. Goel further argues that Goodman’s (1968) theory of notationality is a more appropriate description of the processes of individuation and interpretation that underlie human thinking. Using architectural design processes as example, Goel (1995) illustrates the use of ill-structured and ambiguous representations to support design thinking. When supporting conceptual design processes with computers, it thus cannot be the task of computers to contain, construct, process or display meaning. The most computer support for designing can provide is a basis for human construction of meaning. Algogram, the software developed in the concluding implementation cycle of this study, is designed to amplify design processes in analogy to the way paper and pencil amplify design processes. Algogram further contributes an automated component to diagrammatic representations, which potentially engages designers in dynamic processes the outcomes of which can be surprising to the designer. By providing students with abstracted and potentially ambiguous graphical representations, Algogram supports designers in the modelling of conceptual ideas concerning the distribution and relationships of functions. The perception of ambiguity and 128

the possible attribution of meaning in this context are subject to the individual designer’s sensitivity: Ambiguity is not a property that can be determined objectively, as it does not reside within representations themselves. This however presents a challenge to the development of software support: If ambiguity is not in the representations, how can software provoke or support its perception? In the case of Algogram, ambiguity was permitted by from overlapping encodings. In order to develop a new understanding of an architectural programme item labelled simultaneously as “water” and “performance”, for example, a new understanding needs to be constructed by the designer that may lead to new insights or ideas. The following sections illustrate the resulting perspective on CA as architectural design support in greater detail.

6.3 A new perspective on CA as architectural design support Student comments and insights derived from the observation of students’ design processes over the course of five implementation cycles underlined the benefits of addressing the conceptual design process itself rather than considering merely its outcomes. Software implementations developed over the course of the study increasingly provided students with CA-based software to assist in the development of design concepts. While this study had aimed to support conceptual design processes from the beginning, it was initially assumed that limitations in applications of conventional CA models to architectural design were mainly due to restrictions in representing forms other than compositions of simple elements within rigid lattice grids. For this reason, the preliminary extended CA model as well as the first three software implementations aimed to provide students with CA models with extended capacities to represent form (as discussed in detail in Section 4.1). Outcomes from the software implementations and observations made during their applications however increasingly suggested a different focus. While CA-based design support that focuses on the generation of form can assist designers in the exploration of intricate two- and threedimensional patterns, conceptual design processes tend to exceed such limitations. As the results of the generative design workshop in Tainan illustrated, outlined in Section 5.3, students tended to utilize the software in unanticipated ways. Though results generated with the CA-based software were often taken as inspirational starting points, students’ conceptual design processes mostly transcended form-focused applications of the software. It was thus concluded that in order to support conceptual design processes, CAbased design support could provide more opportunities for designers to contribute aspects relevant to their individual creative processes. The fourth implementation cycle, the KCRC urban automata project, demonstrated how this aim could be achieved. The urban models generated by Peggy Louie were intended as diagrams of functions and their relationships

129

within a three-dimensional urban space: To derive physical urban or architectural form from such diagrams, further architectural interpretation was required. Incidentally, Peggy Louie’s diagrams of urban form resemble the “sun god city I” proposed by Watanabe (2002, see also Section 2.2.3), though his proposal used rules describing lighting conditions to generate forms. In contrast to Peggy Louie, however, Watanabe presents the generated shapes as possible building form. The outcomes of this implementation cycle illustrated the potential of integrating CA-based design support with representations of a diagrammatic nature instead of representing physical form. Both the literature review and software implementations emphasized that conceptual design processes involve interpretation and constant modification of design constraints, and resist premature commitment to form. While the extensions to conventional CA proposed in the preliminary model were still considered a useful basis for a new approach to CA as conceptual design support, visual representations were now cast in a different role. For the following software implementation, Algogram, the diagrammatic nature of visual representations was further accentuated by adopting attributes of sketches and diagrams, conventional ways to support conceptual architectural design processes that were discussed in Sections 2.2.3 and 2.2.4. As proposed by Gaver et al. (2003, p. 240), abstract and somewhat ambiguous diagrammatic representations can suggest issues and perspectives for consideration without imposing solutions or suggesting specific interpretations. By employing sphere-based diagrammatic representations, Algogram enabled students to develop individual interpretations of algograms. It led students to consider form and function from not separate from each other but as interrelated factors in the design of a building, and opened up possibilities to consider the relationships of buildings and their urban context from a fresh perspective. While building on visual representations closely related to conventional bubble diagrams, algograms are more adaptable, allowing the playful merging of functions rather than encouraging their separation. Algogram encouraged students to continuously re-interpret the outcomes of the software, which led to individual and innovative design results that did not rely as much on precedents as design proposals in parallel student groups in the studio. By employing diagrammatic representations during the conceptual design process, designers avoid premature commitment, leaving decisions open while ideas are still vague and under constant reconsideration (Dorst 2003, p. 52). Accordingly, Algogram served to prolong students’ conceptual design phase during the architectural design studio, such that concepts could mature before being translated into building form. In the absence of objective criteria for decision making in design, the aim of this strategy is to maximise the number of available options while the design proposal is gradually taking shape. This reflects what von Foerster (2003, p. 282) calls the “constructivist ethical imperative”: “I shall act always so as to increase the total number of choices” (von Foerster 2003, p. 282). 130

Similarly, Rittel (1984, p. 324) discusses second-generation design methods noting: “One of the arts of the second generation is actually postponement of the formal decision in order to enhance the process of forming judgments.” As described in Section 2.2.3, previous applications of CA to architectural design have proposed alternative mapping strategies of CA-generated form, as for example Frazer (1995), Coates et al. (1997) and Anzalone and Clarke (2004). Such mappings were however not explicitly related to conceptual design development but rather to the process of choosing between and fine-tuning possible forms. The initial extended CA model proposed the integration of CA-based design support into Schön’s (1983) model of the design process as optional design “move” (see Section 4.2). Results and observations from the applications of CA-based software implementations however suggest that CA-based design support in form of optional design “moves” is likely to affect the design activities of framing and reflection that together with design “moves” constitute the conceptual design process (as discussed in Section 2.1.3). Initially, this study considered design “moves” in isolation from framing and reflection, aiming to provide extended capacities of CA to visually represent architectural form. Over the course of the five implementation cycles, it was however learned that the purpose of providing CA-based design “moves” is to positively affect both reflection and re-framing in the conceptual development of design ideas. With its emphasis on students’ perceptions and interpretations, the fifth implementation cycle focused on the designer’s reflecting activity, acknowledging the different roles of software and designer within the computer-supported design process. While the computer can present rule-based modifications of form, it is the designer who relates such forms to his perception of the design task and generates his individual interpretation. This shift has analogies to the importance attributed to “different ways of seeing” as described by Schön and Wiggins (1992, see also Section 2.1.3). The approach taken in the fifth software implementation, Algogram, thus seeks to evoke continuous reinterpretation of outcomes of the software by employing abstract and potentially ambiguous diagrammatic representations. When assessing the outcomes of student applications of this implementation, it was found that students’ conceptual design processes tended to be more thorough than that of other student groups in the same design studio. At the same time, students were able to articulate and to reflect upon the strategies and considerations using their design proposals.

6.4 Automated diagrams As a result of the change in focus from representing building form to diagrammatic visual representations over the course of this study, CA-based design support was implemented in

131

the form of automated diagrams in Algogram, the fifth software implementation. Consequently, the focus of CA application shifted from later to earlier stages of the design process. Diagrammatic visual representations were intended to provide conceptual design support while avoiding a premature emphasis on physical form, while CA-based design support was proposed as an automated component to such diagrammatic representations. In this context, the term “automated” describes the ability of CA-based processes to respond to configurational changes in diagrammatic representations without requiring continuous input from the user. CA-based automated diagrams thus support conceptual design processes by directly responding to modifications based on rule-based relationships of elements within the diagram. By integrating diagrammatic representations and user-configured rule-based generative processes, automated diagrams may lead to results that were neither expected nor intended by either the software developer or the designer using the software. In this sense, automated diagrams are an attempt to transcend the limitations of using computers to execute instructions in a deterministic way. Instead, automated diagrams aim to dynamically respond to a designer’s input throughout the design process, which potentially leads to unanticipated outcomes and new ideas. This approach to CA-based conceptual design support instead aims to provide designers with a medium in the sense of Glanville (1992, see also Section 2.2.1). As a medium, “we let the computer take control, make decisions and carry out actions, on its own terms, that we would find hard to do.” (ibid., p. 16). This study primarily adopts two aspects suggested by Glanville (ibid., pp. 10 ff) in order to use the computer as a medium. It employs generative algorithmic design processes, and it builds on re-interpretation, a form of “abuse” in that re-interpretation makes it possible to transcend the scope intended for visual representations. Previous work in the area of using computers to support conceptual design by digital means, as discussed in Section 2.2.4.3, has focused on ways to recognize, interpret and store freehand sketches, as in the electronic cocktail napkin developed by Gross and Do (Gross 1996, Gross and Do 1996). The approach developed in this study differs from such approaches in several ways. First, three-dimensional diagrams consisting of abstract elements are substituted for conventional two-dimensional freehand sketches. Second, automated diagrams are intended to be used as a dialogue of automated generative sequences and manual modifications by the designer. Third, automated diagrams involve designers in a conversational process, in which CA-based functions execute basic predetermined rules, but the outcomes require further interpretation by the designer to become meaningful. This process allows the designer to reinterpret the outcomes in various ways throughout the design process and permits unanticipated results characteristic of conceptual design processes. Interpretation by the designer is recognized as a vital step in the development of design concepts, as the visual representations in themselves do not carry 132

meaning. Meaningful interpretations can only be generated by the designer, who establishes relationships between representations and a specific design task. Involving the designer instead of the computer to interpret diagrammatic representations further addresses the often tacit nature of design knowledge and design rules (Schön 1988), which are difficult if impossible to make explicit. This problem was encountered in four of the five implementations in this study, with students frequently commenting on the usefulness of rules on the one hand, but the problem of precise (for example numerical) rule configurations that tended to disrupt the conceptual design process on the other hand. Comments of students working with Algogram suggested that rules should be configured and used in more intuitive ways than they were implemented in Algogram.

6.5 Implications Outcomes of this study suggest that CA-based conceptual design support as developed and investigated in this study is more closely related to conventional sketches and diagrams than to conventional CAD systems. Supporting conceptual design processes requires openness in terms of possible results and possible interpretations that are difficult to achieve when predetermined semantic frameworks are implied that restrict re-interpretation of results. While student comments received in the generative design workshop in Tainan indicate that semantic frameworks are perceived as helpful when learning to use and initially, applying software, semantic frameworks did not affect the unpredictable nature of students’ design processes. The scope of predetermined semantic frameworks was transcended in almost all design outcomes of the workshop. Conceptual design processes are concerned with exploration and eliciting of new ideas. They are not bound to the exploration of possible forms but also involve intangible aspects of a design problem that are related to personal values and meaning within a given context. As such, they tend to defy the assumptions implied by software developers providing digital conceptual design support, as has been observed in the second and third implementation cycles in this study. This study responded to this problem by embracing individual interpretations, introducing abstract, diagrammatic representations to CA-based design support. While this strategy was successful in Algogram, the fifth software implementation, it was also observed that the approach taken with Algogram nevertheless presents students with a predetermined semantic framework, though a rather abstract one. Algogram supports the conceptual design of architectural programmes, but is unlikely to be of much use when applied to design problems such as façade design. The sphere-based diagrammatic representations and “hybrids” provided by Algogram are easily mapped to

133

three-dimensional configurations of functions and their potential interactions, but much less straightforward when attempting to map such elements to aspects of façades. These observations illustrate the limited possibilities of providing designers with generic digital conceptual design support. As was concluded from the outcomes of the generative design workshop in Tainan (Fischer and Herr 2007), supporting conceptual design processes with generative software may be possible in two ways: Designers and toolmakers could “conspire”, sharing the same context and collaborating with each other on a specific design project. As a second option, software could be employed that is sufficiently abstract, such that it does not restrict unanticipated associations and idea development, which is likely to occur. The fourth and fifth implementation cycles in this study each adopted one of these approaches. The KCRC urban automata project featured designer and software developer in close collaboration during the development of the CA-based software, while Algogram provided a group of students with abstract and ambiguous diagrammatic representations. Both approaches led to appropriate design outcomes. It is yet to be determined to what extent relatively generic conceptual design support such as Algogram can be generalized and applied outside of the particular studio it was developed for may be subject to further examination in future work. The abstract, sphere-based diagrammatic representations employed in Algogram were predominantly function-based. Algograms served to explore possible relationships and configurations of functions within building programmes. Students frequently started out with diagrams of a rather abstract and general interpretation. Over the course of their design processes, however, students often differentiated these diagrams, which were then interpreted with increasing physical form connotations. For this reason, translations of diagrams into building form at a later design stage still bear many similarities to the configurations of functions of the original algograms. In this translation process, some students combined function-based algograms with additional, form-based diagrams. These form-based diagrams were typically two-dimensional drawings on paper, and were presented alongside algograms when describing the process of translating outcomes of Algogram into building form. Both types of diagrams seem to have complemented each other in students’ conceptual design processes, which indicates a potential for further research on ways to integrate diagrams of different kinds for computer support of conceptual design processes. Visual representations to support design processes are assumed to change throughout the design process, accompanying a transition from an emphasis on ideas and concepts to a focus on physical form (Dorst 2004). Based on this assumption, Gross and Do (2001, p. 146) suggest that diagrams increase in detail at later design stages and gradually become representational sketches. In this study, it was however observed that 134

representations do not necessarily change together with every change in their interpretation. The same sphere-based diagrams in Algogram were used to represent abstract design concepts such as “observation” or “secret” at early design stages and were often interpreted with much more physical connotations such as “water” or “gathering” at later stages of the same conceptual design process. This observation results in a question for further research: In which way do visual representations and their interpretations affect each other throughout the design process? This study presents an approach to CA-based design support in form of automated diagrams. To this end, CA-based, rule-driven generative processes are combined with abstract and ambiguous diagrammatic visual representations. As discussed in Section 6.4, diagrammatic visual representations were central to Algogram, and allowed students to pursue individual conceptual design processes. In contrast to the perceived utility of the visual representations, however, the CA-based rules were often perceived as disruptive to the design processes, and students commented that rules should be configured and used in a more intuitive way than that provided in Algogram. In this study, it was initially assumed that CA-based rules would consist of the definition of simple relationships between neighbouring geometric elements. Such relationships were thought of as state-based conditions and instructions within an if/then/else logic, relating to logic states, geometric properties or spatial positions of elements. The test implementations however indicated that the nature of element relationships reflected upon by students tended to exceed the scope of such rules. During the studio test of the second implementation, a student for example remarked: “My island is about freedom. I did not know how to write rules about freedom”. This comment suggests that there may be fundamental limits to the application of rule-based design approaches. Contrary to March’s (1996) position, rules may not always have a “liberating” effect on conceptual design processes. It seems that rules are not only often tacit or implicit, as suggested by Schön (1988, see Section 6.4), but may prove incompatible with certain design aims or approaches. This study responded to this observation by presenting a variety of approaches to make the use of rules easier and more intuitive in subsequent software implementations. The main focus in developing alternative ways to use rules however remained on the user interface for rule configuration. When reconsidering outcomes of this study, the way in which rules are configured may not be the only reason for this deficiency. Another reason may be the diverging ways of thinking required for rule composition and when using visual representations in software such as Algogram. Abstract and diagrammatic representations encourage vague and diverging thoughts, whereas formal rule definition requires logical and numerical decisions. This change of thinking mode seems to be the primary source for the disruption reported by students. This problem, however, affected primarily those 135

implementations that aimed at rather generic applicability. In the KCRC urban automata project, rules could be defined more easily since the scope of the project was already identified and the meaning of elements as well as their relationships could be defined clearly.

6.6 Limitations Action research, the method of inquiry chosen to accommodate the open-ended, explorative nature of this study, implies that outcomes of this study are necessarily limited to the specific contexts of the software implementations and applications. The approach to CAbased generative design support presented in this study was developed over the course of five implementation cycles and may not be applicable with similar results outside of these specific contexts. Each implementation cycle was typically limited to a duration of one to three weeks, with one to 23 student participants. It was the aim of this study to develop a new approach to CA as conceptual design support, which emphasized qualitative over quantitative results. Furthermore, software developed for each of the implementation cycles served mainly to explore design approaches in the context of this study and has not been tested, optimized or made available beyond the scope of the respective implementation cycles. The limited durations of the implementation cycles further imply that students had little time to develop mastery in the provided software. With increasing mastery of a tool, the modes of its use change and adapt over time and it is acknowledged that the periods of applying the software may not have been long enough for this adaptation to become effective, such that different results may be obtained in studies of a longer duration. During the application of CA-based software in this study, the author has continuously been involved, providing tutorials on the use of the software and further developing software. Changes in the scope of applications could thus often be met with changes in the software. For cases where this close collaboration is not possible, or the software developer is absent, software development and application may thus be subject to further limitations.

6.7 Contributions The contributions offered by this study can be summarized at three levels:

1) Generative computer-aided design: An extended CA model for the application of CA to conceptual architectural design is presented, combining research in the areas of generative design, sketches and diagrams and design theory. Outcomes of this study suggest that (semi)automated diagrammatic visual representations can support 136

conceptual design processes with an openness difficult to achieve in previous, formcentred approaches to CA in architectural design. This approach to generative conceptual design support resulted in the concept of automated diagrams as described in Section 6.4. This thesis further presents a model for the integration of CA-based design support into the architectural design process as “reflection in action” as described by Schön (1983). An integration of manual and automated design “moves” in a loosely structured sequence is proposed to avoid the limitations of some previous approaches, which often featured self-contained, fully automated systems.

2) Methods of inquiry in design research: In order to develop a new approach to CA as conceptual architectural design support, this thesis adopted action research as a method of inquiry. In the context of this thesis, action research served as a framework for a research process that not only involved a significant amount of applied design, but can itself be described as a design process in that it aimed to develop a new CA-based design approach. While the potential of action research in the context of design has been recognized (see Section 3.1), this approach is not widely known yet and deserves further development and discussion, to which this thesis may contribute.

3) Software development and education: Over the course of this study, five software implementations have been produced, four of which were applied by students in design studio and workshop settings. While the implementations differ in scope, some have shown potential for further development and for future applications, in particular the fifth implementation, Algogram. Students participating in this study had an opportunity to explore new design approaches. As it was acknowledged in many positive comments received in student interviews, this has enriched students’ learning experiences. Two implementations, the KCRC urban automata and Algogram, supported architecture students to realize innovative design ideas in the context of grade-bearing studio projects.

6.8 Future research Contrary to initial assumptions that had motivated this study, the applicability of CA to architectural design is not so much based on the capability of CA to represent physical building form. Instead, outcomes of this study suggest that the potential of CA seems to lie in their capability to combine aspects of procedural logic, spatial relationships and

137

diagrammatic visual representations. Based on this new perspective, the following aspects may be explored in future work:

1) The aim of this thesis was to develop a generic model for the application of CA to conceptual architectural design. As has been observed in Section 6.4, future work may explore the applicability and limitations of this generic model to more specific design contexts and applications.

2) One of the questions that could not be fully examined in this study is if, and how, generic, diagrammatic visual representations can fully be reconciled with the use of rules in conventional CA. As discussed in Section 6.4 above, students working with generic CA-based design support requested more intuitive and less disruptive ways to work with rules. This results in the general question of which types of element relationships designers would want to assign at the conceptual design stage. Such rules may possibly include vague and open-ended definitions of relationships, which transcended the scope of formal rules as employed within this study that was focused primarily on formal (geometric and numeric) relationships in clearly defined conditional procedures.

3) When translating abstract, function-oriented “algograms” into form, some students used additional, form-oriented diagrams to guide the development of building form. As mentioned in Section 6.4, future work may explore ways to integrate both types of diagrams within conceptual design support software.

4) This study concentrated on the integration of CA-based design support into Schön’s design process model to support optional automated design “moves”. As was noted in Section 6.4, some limitations of this focus have been recognized, and further examination of the mutual influence of moving, framing and evaluation activities may provide further insight into the integration of generative design processes and dynamic diagrammatic representations.

5) Conceptual generative design support may be further explored with a more general level in developing automated diagrams based on generative mechanisms beyond CA, and in a variety of in different contexts.

6) As briefly discussed in Section 6.4, rule-based computer aided design may not be reconcilable with all design intentions. Rule-based design approaches may enable 138

design exploration in some cases, whereas in other cases, it is perceived as restricting freedom of design exploration. The general role and applicability of rules in design processes merits further examination in future work.

7) As discussed in Section 6.4, design processes are understood to focus initially on ideas and concepts and emphasizing form at later stages, and it has been assumed that visual representations employed to support conceptual design processes are subject to similar changes. Observations derived from this study however suggest that representations do not change with every change in design focus, and seem to be more constant than their interpretations. This view contrasts with the description of visual representations proposed by Gross and Do (2001, p. 146), and may be further explored in future studies.

139

Appendix 1. Action research, applied ethnography and grounded theory: a discussion I. Applied research methods for design Research methods are driven by research questions as well as underlying theory. In architectural research, methods are chosen depending on the focus of the investigation, which often leads researchers to adopt methods from other fields such as cognitive science or physics. Applied design typically requires approaches to research that embrace its openended nature, which defies controlled experimental settings. Similar circumstances have led researchers from the social sciences to acknowledge the possibility of letting theory, research methods and the situation under investigation evolve together. Hesse-Biber and Leavy (2006, p. xii) describe how new methods are developed in social research to capture the nature of new problems: “Emergent methods are conscious of the link between epistemology (a view on how knowledge is constructed), methodology (the theoretical question[s] that informs our research and how it is carried out), and method (the specific tools used to carry out research).”… “We can think of these methods as hybrid in the sense that they often borrow and adapt methods from their own disciplines or can cross disciplinary boundaries to create new tools and concepts or refashion tools or concepts that exist in order to answer complex and often novel questions.”

Emergent methods as described by Hesse-Biber and Leavy are typically developed within a specific context. In this respect, design researchers face a similar situation. Applied design directly involves the researcher and is characteristically context-dependent. The unique nature of design problems (Rittel and Webber 1973) implies that assumptions about a situation cannot be verified without actually enacting them. Furthermore, the nature of design process outcomes often cannot be predicted. Undertaking research that involves applied design processes requires methodologies that are flexible enough to accommodate the possibility of insights of an unanticipated nature. Variables preconceived for measurements may change over the course of design processes in order to capture unanticipated results. A further issue in applied design research is that the researcher typically takes on an active role which may, either partly or entirely, determine the outcomes. Pedgley (2007) discusses these challenges to research through design (as introduced in Section 3.1) and suggests several criteria that candidate research methods must be able to accommodate (ibid., p. 470). Four approaches to applied designing match the requirements Pedgley sets out: Project report, participant observation, action research and the design diary. As the focus in this study is on design processes of others, action research as well as participant observation seemed the most appropriate choices. As a result, three qualitative research methods were examined more closely: grounded theory, applied 140

ethnography and action research. Action research is the approach that was finally chosen for this study and is discussed at length in Chapter 3. This appendix presents some more background discussion to substantiate this choice, relating action research to applied ethnography and grounded theory to illustrate the advantages of using action research in this study.

III. A brief discussion Applied ethnography, grounded theory and action research are qualitative research methods and feature the researcher as an active participant in the situation under investigation. All three aim at deriving insight from observations made in practice rather than in experimental settings in which processes are isolated from their context. Research outcomes of these methods are typically descriptions of patterns and correlations in contexts that typically do not allow for easy measurement of variables. Applied ethnography and grounded theory focus on theory development through observation, whereas action research is motivated by the desire to improve a situation by changing it. As such, action research is intended to have both “action” outcomes, i.e. changes in a situation, and research outcomes. Each of the three research methods starts with an encounter with a “found” situation that is usually complex and changing (as in grounded theory, see Glaser and Strauss 1967) or involves the researcher actively (as in applied ethnography, see Ball and Ormerod 2000). From observing or engaging with such situations, explanations and more general principles are developed to describe the situation under investigation. This move from description of specific cases to more general statements enables theory to be generated directly from observational data. The nature of the initial “found” situation typically differs among action research, grounded theory and applied ethnography, essentially depending on different degrees of involvement of the researcher. Grounded theory aims at describing a situation without prior goals or assumptions. Thus, the researcher, while involved, does not aim to change any processes that he is involved in. His main goal is to describe and analyse, thus his main activity is typically conducting interviews or taking field notes of his observations (for a detailed discussion, see Strauss and Corbin 1997 and Glaser 1998). In contrast to this rather neutral involvement, applied ethnography as proposed by Ball and Ormerod (2000) allows for initial hypotheses to be brought in and a more directed process of investigation. Action research actively seeks to achieve changes in a situation deemed deficient in the beginning, and the result of this change is at least as important as any theoretical insights (Argyris et al. 1985, p. ix). In both applied ethnography and action research the observer participates in a situation that he studies simultaneously. Usually, processes with many participants are studied, such as classes, organisations, design teams etc., which is different from individual design explorations. 141

All three approaches described above have a characteristic openness for theory development during the research process, where an observing researcher can always add to or modify preliminary assumptions or hypotheses until they fit the situation adequately. The reliance on a subjective observer however results in a different view on conventional science’s emphasis on generalisability of research outcomes as a benchmark of their validity. In grounded theory, the validity of research results depends on the skill of the researcher and his ability to carry out a rigorous data collection and coding process. In applied ethnography as found in design research, Ball and Ormerod (2000) emphasize the difficulty of obtaining objective data, in part since there might be financial interests from a client commissioning the study. To solve this problem, Ball and Ormerod (2000) suggest a method of methodological triangulation, where evidence is provided by convergent results across different research methodologies. In action research, rigour takes on a two-fold perspective: while plans to change a situation might be rather subjective and based on individual experience, action research results can be directly measured either quantitatively or qualitatively from the changes brought about in the situation under investigation. In addition, repeating the cycles of action research is seen as a way to increase validity of successful intervention strategies (Dick 1999). Action research is clearly the most pragmatic of the three approaches, working immediately within a situation and purposefully changing it in a process jointly determined by all participants. Successful research from a viewpoint of action research is typically research that can produce a successful outcome, and data is generally collected and analysed with this aim in mind. This viewpoint implies openness to unexpected insights and malleability of research approach, which became one of the main reasons for applying action research in this study.

142

Appendix 2. Tainan generative design workshop data I. Reference card front and back The reference card was handed out at the beginning of the workshop and gives short introductions and explanations to the Tofu Automata Generator software functions and their modes of use.

Figure 50: Tofu Automata Generator reference card (front) 143

Figure 51: Tofu Automata Generator reference card (front)

144

II. Questionnaire The full questionnaire comprises 27 questions, of which questions 1-14 and question 27 relate to the Tofu Automata Generator. This section lists the results of the data collection.

Question 1: Did you use the Tofu Automata Generator during the workshop? 15 students answered this question with “Yes”. 2 students answered this question with “No”. Of these two, only one student gave a reason: “Because this Tofu Atomata I think is some like shape grammar we played before. Second, we're more interested in Bubble Co-Rationaliser.”

Question 2: Did you use the Tofu Automata Generator by yourself or working closely with other group members? 1 student answered this question with “Always by myself”. 4 students answered this question with “Always working closely with other group members”. 9 students answered this question with “Sometimes by myself, sometimes working closely with other group members”. 3 students gave no answer to this question.

Question 3: Please describe your reasons for your answer to question 2.

Reasons given for the answer “Always by myself”: 1. “We separate different pats of our work. Everyone has his own system to develop.”

Reasons given for the answer “Always working closely with other group members”: 1. “Because I do not have a lot of skills in using 3DStudio Max. But I'm curious about the software's effecting work. It looks so different that you even don't know what it will become.” 2. “We always discuss on how to do and use and it's very good.” 3. “First time to use. I always need to exchange more experiences with each other.” 4. “Sometimes used at home and sometimes used at school. We discuss together and develop everyone’s' ideas.”

Reasons given for the answer “Sometimes by myself, sometimes working closely with other group members”: 145

1.

“At some times, different variance cause the result, so i discuss with my group member. But if the situation that have much factors, I do myself.”

2. “Sometimes when we discuss, we will use the Tofu together. And sometimes I will operate the Tofu by myself because I want to try the ability or setting of Tofu.” 3. “We need discussion about design or the function of software.” 4. “At first I worked with my group members to know how to use the Tofu Automata Generator. After that, for finishing our design on time, we used the Soap-Bubble Co-Rationaliser.” 5. “Need some discussion.” 6. “I have some skills in 3D Studio MAX and someone always asks me about 3DMAX.” 7. “Because sometimes I am busy in other things, and sometimes other group members are busy.” 8. “Because sometimes used at school, sometimes at home.” 9.

“In the lab we try to understand the process of generating forms and logic together, and we try to generate different forms by each other.”

Question 4: Did you start by developing your ideas on paper before using the Tofu Automata Generator on paper or did you use the software from the beginning? 2 students answered this question with “I used paper to develop my initial ideas”. 5 students answered this question with “I used paper to develop my initial ideas, working closely with other group members”. 6 students answered this question with “I did not use paper sketching. I used the Tofu Automata Generator from the beginning”.

Question 5: Does you final Tofu Automata Generator outcome match your initial design ideas? This question was answered on a scale of 1 = “Not at all” to 7 = “Completely”. 13 students answered this question. The average answer value was 2.92, with a standard derivation of 1.64.

Question 6: Did using the Tofu Automata Generator inspire you and help to explore new design ideas? This question was answered on a scale of 1 = “Not at all” to 7 = “Always”. The average answer value was 4.31, with a standard derivation of 2.13.

146

Question 7: Did using the Tofu Automata Generator give you surprising results? This question was answered on a scale of 1 = “Not at all” to 7 = “Always”. The average answer value was 4.615, with a standard derivation of 1.82.

Did you incorporate surprising results into your design? This question was answered on a scale of 1 = “None at all” to 7 = “All of them”. The average answer value was 3.384, with a standard derivation of 1.15.

Question 8: Did you use the Tofu Automata Generator to …? This question was answered on a scale of 1 = “to realize ideas I had since the beginning of the workshop” to 7 = “to explore and experiment”. Two clusters of answers can be observed from the answers to this question: one around the value “3” (3 students gave “3”, 1 student gave “4”), and one around the value “6” (5 students gave “6”, 3 students gave “7”).

Question 9: How useful did you find each of the functions of the Tofu Automata Generator? This question was answered on a scale of 1 = “Useless” to 7 = “Very useful”, separated by function. The following table illustrates the aggregate values for each question, further distinguished by colours indicating group membership.

Figure 52: Perceived Usefulness of Tofu Automata Generator functions 147

Question 10: Did you miss additional functions in the Tofu Automata Generator that would have been helpful to you? If yes, please describe. No new functions were suggested.

Question 11: Would you have liked to create your own additional functions in the Tofu Automata Generator? If yes, please describe. 5 students answered this question: 1. “I liked to create some functions, such like twist or bend etc.” 2. “Transformation of the box. We can use it to generate more shapes we want.” 3. “Maybe not only the box system, can use the curve line to Multiply or other functions.” 4. “The Tofu software has the potential ability to become an analysis system to plan the layout.” 5. “Yes. Maybe it should have a "mix" function, which can combine different functions.”

Question 12: Did you find the four material types (Matter, Void, Context, Neutral) useful? This question was answered on a scale of 1 = “Useless” to 7 = “Very useful”. Two clusters of answers can be observed from the answers to this question: one around the value “3” (3 students gave “3”, 2 student gave “2”), and one around the value “6” (5 students gave “6”, 2 students gave “5” and 1 student gave “7”).

Question 13: Did you find the four material types (Matter, Void, Context, Neutral) easy to understand? This question was answered on a scale of 1 = “Very hard to understand” to 7 = “Very easy to understand”. Two clusters of answers can be observed from the answers to this question: a small cluster around the value “2” (3 students), and one around the value “6” (3 students gave “6”, 3 students gave “5” and 3 student gave “7”).

Question 14: Would you have liked to create your own material types in the Tofu Automata Generator? If yes, please describe. 4 students gave suggestions: 148

1. “Yes, maybe more realistic material (weight, time?)...” 2. “I think the material types of Tofu are very useful and enough! If we create too many functions, we may get confused.” 3. “More material can help me to define complex system that I would like to make.” 4. “No, I feel the Tofu has enough varieties that I need more time to understand and try for a longer time.”

Question 24: Would you like to make a general comment regarding Generative Design, the software tools used in this workshop or the workshop as a whole? 11 students gave suggestions: 1. “Actually, I like architecture as simple as possible. But I think the Generative Design is helpful for constructing, because the whole development is based on a simple unit (like Tofu or Bubble) and it is much easy to control.” 2. “In the workshop, we try to define the scale meaning and how to match two systems and the site. And then we used that to create the rules is interested.” 3. “I don't think Generative Design can design because there are many space elements can't in to computer, like nature. So the generative Design is a very good "tool".” 4. “Yes, the software tools are really interesting and inspiring! Of course, it's good to think about generative Design. That's a nice experiment to discuss about Design during the workshop. It's pretty good!” 5. “I like the Soap-Bubble tool because of it's a nice form and magic spaces producer.” 6. “Of course, the digital tool is interesting. The workshop is pretty good.” 7. “Maybe you can add some functions to create more organic shapes like (spirals, loops, curves).” 8. “Yes, I'd like to use for original form development. To filler until the used ones, and helps me to program new ideas in real uses.” 9. “I think the designer using the software tools for Generative Design must have very powerful skill for the software. Otherwise they must test the software again and again to experience is the result what the designer wants.” 10. “In general, we will use Tofu software to develop some unexpected forms in Generative Design. But I think the Tofu software can be used to be a useful analytic system. It can test the ability of layout based on different contexts in the site planning.” 11. “It's very useful to student and the agenda is in normal speed. If could, maybe we can have several workshops like this one and help us improve our vision and make a different trainings.” 149

IV. Data tracking

Figure 53: Frequency of use for each function of the Tofu Automata Generator

150

Appendix 3. KCRC urban automata presentation posters This appendix comprises 4 posters used by Peggy Louie in her final design critique to present her project. They were originally printed in A2 format.

Figure 54: Peggy Louie: KCRC Urban Automata Presentation I 151

Figure 55: Peggy Louie: KCRC Urban Automata Presentation II

152

Figure 56: Peggy Louie: KCRC Urban Automata Presentation III

153

Figure 57: Peggy Louie: KCRC Urban Automata Presentation IV

154

References: A Alexander, C.: 1971, The state of the art in design methods, DMG Newsletter, 5(3), 3-7. Alexander, C.: 1963, The determination of components for an Indian village, in J.C. Jones and D. Thornley (eds, Conference on Design Methods, Pergamon, Oxford. Allen, S.: Diagrams Matter, ANY: Diagram Work: Data Mechanics for a Topological Age, Volume 23, December 1998. Anzalone, P. and Clarke, C.: 2004, The Siren's Call, in P. Beesley, N. Cheng and R.S. Williamson (eds), Fabrication: examining the digital practice of architecture: Proceedings of the 2004 AIA/ACADIA Fabrication Conference, Toronto, Ontario, University of Waterloo School of Architecture Press, 325-335. Anzalone, P. and Clarke, C.: 2003, Architectural Applications of Complex Adaptive Systems, in K. Klinger (ed), Connecting >> Crossroads of Digital Discourse. Proceedings of the 2003 Annual Conference of the Association for Computer Aided Design in Architecture, Ball State University, Indianapolis, 324-335 Archer, L.B.: 1981, A View of the Nature of Design Research, in R. Jacques and J.A. Powell (eds), Design:Science: Methods, Westbury House, Guildford, UK. Archer, B.: 1984, Systematic methods for designers, in N. Cross (ed) Developments in design methodology, Wiley, Chichester, 57-82. Architectural Review, January 2006. Argyris, C., Putnam, R. and McClain Smith, D.: 1985, Action science: concepts, methods, and skills for research and intervention, Jossey-Bass, San Francisco. Asimow, M.: 1962, Introduction to Design, Prentice-Hall, Englewood Cliffs, New Jersey.

B Bailey, R.: 2000, The Intelligent Sketch: Developing a Conceptual Model for a Digital Design Assistant, Eternity, Infinity and Virtuality in Architecture: Proceedings of the 22nd Annual Conference of the Association for Computer-Aided Design in Architecture, Washington D.C. 19-22 October 2000, 137-145. Ball, L.J. and Ormerod, T.C.: 2000, Applying ethnography in the analysis and support of expertise in engineering design, Design Studies 21 (4), 403-421. Batty, M., Couclelis, H., and Eichen, M.: 1997, Special issue: urban systems as cellular automata, Environment and Planning B: Planning and design 24(2), 159-164. Batty, M. and Xie, Y.: 1994, From cells to cities, Environment and Planning B: Planning and Design 21(5), 31-48. Batty, M. and Torrens, P.M.: 2001, Modeling complexity: the limits to prediction, CASA Working Paper 36, Centre for Advanced Spatial Analysis, University College London. Benenson, I. and Torrens, P.M.: 2004, Geosimulation: Modelling Urban Environments, John Wiley & Sons, London. Benjamin, A.E.: 2000, Architectural philosophy, Athlone Press, London; New Brunswick, N.J. Boden, M.A.: 2004, The creative mind: myths and mechanisms, 2nd edn, Routledge, London; New York. Bentley, P.J. and Corne, D.W.: 2002, Creative evolutionary systems, Morgan Kaufmann, San Francisco. van Berkel, B. and Bos, C.: Diagrams – interactive instruments in operation, ANY: Diagram Work: Data Mechanics for a Topological Age, Volume 23, December 1998. Blundell Jones, P.: The rights of wrong-angles, Architectural Research Quarterly 10(3/4), 181-182. Buchanan, R.: 1995, Wicked problems in design thinking, in V. Margolin and R. Buchanan (eds), The idea of design, MIT Press, Cambridge, MA., 3-20. Burks, A.W.: 1970, Von Neumann's Self-Reproducing Automata, in A.W. Burks (ed.), Essays on Cellular Automata, University of Illinois Press, Urbana, 3-64. Burks, A.W. (ed): 1970, Essays on Cellular Automata, University of Illinois Press, Chicago. Burry, M.: The exception that proves the rule, Architectural Research Quarterly 10(3/4), 182-184.

C Carrara, G.: 1991, Computational Framework for Supporting Creative Architectural Design, in Y.E. Kalay, Evaluating and predicting design performance, Wiley, New York.

155

Ceccato, C.: 1999, Microgenesis. The architect as toolmaker: Computer-based generative design tools and methods, in C. Soddu (ed), Proceedings of the Generative Art 1998 International Conference, Politecnico di Milano University. Chase, S.C.: 1998, User Interaction Models for Grammar Based Design Systems, International Journal of Design Computing 1. Chase, S.: 2005, Generative design tools for novice designers: Issues for selection, Automation in Construction 14(6), 689-698. Coates, P., Healy, N., Lamb, C. and Voon, W.L.: 1996, The Use of Cellular Automata to Explore Bottom-Up Architectonic Rules, presented at Eurographics UK Chapter 14th Annual Conference held at Imperial College London, UK. Coates, P. and Miranda, P.: 2000, Swarm modelling. The use of Swarm Intelligence to generate architectural form, in C. Soddu (ed), The Proceedings of the Third International Conference on Generative Art 2000, Generative Design Lab, DiAP, Politechnico di Milano University, Milan, Italy. Couclelis, H.: 1997, From cellular automata to urban models: new principles for model development and implementation, Environment and Planning B 24(2), 165-174. Coyne, R.: 2005, Wicked problems revisited, Design Studies 26(1), 5-17. Creswell, J.W.: 2003, Research design: qualitative, quantitative, and mixed methods approaches, 3rd edn, Sage Publications, Thousand Oaks, Calif. Cross, N.: 1977, The automated architect, Pion, London. Cross, N. (ed): 1984, Developments in design methodology, John Wiley & Sons, Chichester. Cross, N.: 1993, A history of design methodology, in M. d. Vries, N. Cross, D. P. Grant and North Atlantic Treaty Organization, Scientific Affairs Division (eds.), Design methodology and relationships with science, Kluwer Academic Publishers, Dordrecht, 14-27. Cross, N.: 2001, Can a Machine Design?, Design Issues 17(4), 44-50. Cross, N.: 2006, Forty Years of Design Research, Design Studies 28(1), 1-4.

D Dave, B.: 1993, CDT: A Computer-Assisted Diagramming Tools, in Flemming and Wyk (eds), CAAD Futures ’93, Elsevier Science Publishers, 91-109. Deleuze, G. and Guattari, F.: 1987, A thousand plateaus: capitalism and schizophrenia, Athlone Press, London. Diaz Moreno, C. and Garcia Grinda, E.: 2004, Soft Metropolitanism [Apartments in MicroSkyscrapers], in F. Marquez Cecilia and R. Levene (eds), El Croquis 118: Cero 9, Abalos & Herreros, No.Mad, Madrid, Spain, 140-1147. Dick, B.: 1999, What is action research?, [Online article], viewed on 12 March 2007, http://www.scu.edu.au/schools/gcm/ar/whatisar.html Dick, B.: 1999, Sources of rigour in action research: addressing the issues of trustworthiness and credibility, [Online article], viewed on 27 February 2007, . Dick, B.: 2000, A beginner's guide to action research [Online article], viewed on 27 February 2007, . Do, E. Y.-L.: 1995, What's in a diagram that a computer should understand, in M. Tan and R. The, CAAD Futures '95: The Global Design Studio, Sixth International Conference on Computer Aided Architectural Design Futures, National University of Singapore, Singapore, 469-482. Do, E.Y.-L.: 1997, Computability of Design Diagrams - an Empirical Study of Diagram Conventions in Design, in R. Junge (ed), CAAD Futures 97, Kluwer, Munich, 171-176. Do, E.Y.-L. 2005, Design sketches and sketch design tools, Knowledge-Based Systems 18(8), 383405. Do, E. and Gross, M.D.: 1997, Inferring Design Intentions from Sketches, in Y.L. Liu and J.Y. Tsou. (eds), Proceedings, Computer Aided Design Research in Asia (CAADRIA '97), Hu's Publishing, Taipei, 217-227. Do, E.Y.-L. and Gross, M.D.: 2001, Thinking with Diagrams in Architectural Design, Artificial Intelligence Review 15(1-2), 135-149. Dogan, F., and Nersessian, N.: 2002, Conceptual diagrams: representing ideas in design, in M. Hegarty, B. Meyer and N.H. Narayanan (eds), Diagrammatic representation and inference, Springer, Berlin, 353-355. Dominick, P.G., Demel, J.T., Lawbaugh, W.M., Freuler, R.J., Kinzel, G.L. and Fromm, E.: 2001, Tools and tactics of Design, John Wiley & Sons, New York. Dorst, K. and Dijkhuis, J.: 1995, Comparing paradigms for describing design activity, Design Studies 16(2), 261-274. 156

Dorst, K.: 2003, Understanding Design, BIS, Amsterdam. Dorst, K.: 2004, On the Problem of Design Problems - problem solving and design expertise, Journal of Design Research 4(2). Downton, P.: 2003, Design Research, RMIT University Press, Melbourne. Duarte, J.P.: 2004, The virtual architect, in C. Soddu (ed), The Proceedings of the Seventh International Conference on Generative Art 2004, Generative Design Lab, DiAP, Politechnico di Milano University, Milan, Italy. Dunster, D.: 2006, Design Essence, Architectural Review, January 2006, 28-31.

E Eastman, C.M.: 1969, Cognitive processes and ill-defined problems: a case study from design, in D.E. Walker and L.M. Norton (eds) Joint International conference on Artificial Intelligence (Washington, D.C.) Eastman, C.M. (ed): 1975, Spatial synthesis in computer-aided building design, Applied Science, London. Eckert, C.M., Kelly, I. and Stacey, M.K.: 1999, Interactive generative systems for conceptual design: An empirical perspective, Artificial Intelligence for Engineering Design, Analysis and Manufacturing 13(4), 303-320. Edwards, A.W.F.: 2004, Cogwheels of the Mind: the story of Venn diagrams, Johns Hopkins University Press, Baltimore and London, 2004. Eisenman, P.: 1999, Diagram diaries, Universe Publishing, New York. Elliott, A.M.: 2002, Computational Support for Sketching and Image Sorting During the Early Phase of Architectural Design, PhD thesis, University of California, Berkeley. Emmons, P.: 2006, Embodying networks: bubble diagrams and the image of modern organicism, The Journal of Architecture 11(4), 441-461.

F Finch, P.: The language of architecture, Architectural Review, January 2006, 17. Fischer, T. and Herr, C. M.: 2001, Teaching Generative Design, in C. Soddu (ed), The Proceedings of the Fourth International Conference on Generative Art 2001, Generative Design Lab, DiAP, Politechnico di Milano University, Milan, Italy. Fischer, T. and Herr, C.M.: 2004, Identity crisis and high-speed urbanism: Form and morphogenetic process as generators of design identity, in C. Soddu (ed), Proceedings of the AsiaLink Seminar De Identitale (pre-print), Rome, Italy, 109-116. Fischer, T. and Herr, C.M.: 2007, The Designer as Toolbreaker? Probing Tool Use in Applied Generative Design, in G. Yu, Q. Zhou and W. Dong (eds), CAADRIA 2007. The Proceedings of The Twelfth International Conference on Computer-Aided Architectural Design Research in Asia, School of Architecture, Southeast University and School of Architecture Nanjing University, Nanjing, China, 2007, 381-389. Fish, J.C: 1996, How Sketches Work - A Cognitive Theory for Improved System Design, PhD thesis, Loughborough University of Technology. von Foerster, H.: 2003, Understanding understanding: essays on cybernetics and cognition, Springer, New York. Fraser, I. and Henmi, R.: 1994, Envisioning Architecture: an analysis of drawing, Van Nostrand Reinhold, New York. Frayling, C.: 1993, Research in Art and Design, Royal College of Art - Research Papers, 1(1). Frazer, J.H.: 1995, An Evolutionary Architecture, Architectural Association, London.

G Gadamer, H-G.: 1986, The relevance of the beautiful and other essays, Cambridge University Press, Cambridge. Galle, P. and Kovacs, L.B.: 1992, Introspective observations of sketch design, Design Studies 13(3), 229-272. Gao S.: 2006, A comparative study of problem framing in multiple settings, PhD thesis, The University of Hong Kong, Hong Kong. Gardner, M.: 1970, The Fantastic Combinations of John Conway's New Solitaire Game of "Life", Scientific American 223(4), 120-123. Gaver, W.W., Beaver, J. and Benford, S.: 2003, Ambiguity as a resource for design, Proceedings of the Conference on Human Factors in Computing Systems, 5-10 April 2003, Fort Lauderdale, FL. ACM Press, New York, 233-240. 157

Gibson, J.J.: 1977, The theory of affordances, in R.E. Shaw and J. Bransford (eds), Perceiving, Acting, and Knowing, Lawrence Erlbaum Associates, Hillsdale, NJ. Glanville, R.: 1995, Architecture and computing: a medium approach, in L. Kalisperis and B. Kolarevic, (eds), Computing in Design: enabling, Capturing and Sharing Ideas—ACADIA ’95, University of Washington, Seattle, 5-20. Glanville, R.: 1999, Researching Design and Designing Research, Design Issues 15(2), 80-91. Glaser, B.G. and Strauss, A.L.: 1968, The discovery of grounded theory: strategies for qualitative research, Weidenfeld and Nicolson, London. Glaser, B.G.: 1998, Doing grounded theory: issues and discussions, Sociology Press, Mill Valley, Ca. Glock, F.: 2003, Design Tools and Framing Practices, Computer Supported Cooperative Work 12(2), 221-239. Goel, V: 1995, Sketches of Thought, MIT Press, Cambridge, Mass. Goel, V.: 1999, Cognitive roles of ill-structured representations in preliminary design, in J.S. Gero and B. Tversky (eds), Visual and spacial reasoning in design, MIT, Cambridge, KCDCC, University of Sydney, Australia, 131-144. Goldschmidt, G.: 1991, The Dialectics of Sketching, Creativity Research Journal 4(2), 123-134. Goldschmidt, G.: 1995, The designer as a team of one, Design Studies 16(2), 189-209. Goldschmidt, G.: 2004, Design representation: private process, public image, in G. Goldschmidt and W.L. Porter (eds), Design Representation, Springer, London, 203-217. Goldschmidt, G: 2006, The Backtalk of Self-Generated Sketches, Design Issues 19(1), 72-88. Goldschmidt, G. and Porter, W.: 2000, Editorial, Design Studies, 21(5), 433-436. Gombrich, E. H.: 1982, The image and the eye: further studies in the psychology of pictorial representation, Phaidon Press, Oxford. Goodman, N.: 1968, Languages of art: an approach to a theory of symbols, Bobbs-Merrill, Indianapolis. Goodman, N.: 1978, Ways of worldmaking, Harvester Press, Hassocks, UK. Greenwood, D.J. and Levin, M.: 1998, Introduction to action research: social research for social change, Sage Publications, Thousand Oaks, Calif. Groat, L. and Wang, D.: 2002, Architectural Research Methods, John Wiley & Sons, New York. Gross, M.D.: 1996, The electronic cocktail napkin: a computational environment for working with design diagrams, Design Studies 17(1), 53-69. Gross, M.D. and Do, E.Y.-L.: 1996, Ambiguous Intentions: a Paper-like Interface for Creative Design, in Proceedings of the 9th annual ACM symposium on User interface software and technology 1996, Seattle Washington, USA, 183-192.

H Hardingham, S. (ed): 2003, Cedric Price: opera, Wiley-Academy, Chichester. Hatchuel, A.: 2002, Towards Design Theory and expandable rationality: The unfinished program of Herbert Simon, Journal of Management and Governance 5(3-4). Hegselmann, R.: 1996, Cellular automata in the social sciences: perspectives, restrictions and artefacts, in R. Hegselmann, U. Mueller and K.G. Troitzsch (eds), Modelling and simulation in the social sciences from the philosophy of science point of view, Kluwer, Dordrecht, 209-234. Herbert, D.M.: 1988, Study drawings in architectural design: their properties as a graphic medium, Journal of Architectural Education 41(2), 26-38. Herr, C.M.: 2003, Challenging Cookie-Cutter Architecture using Cellular Automata, in C. Soddu (ed), The Proceedings of the 6th Conference and Exhibition on Generative Art 2003. Generative Design Lab, DiAP, Politechnico di Milano University, Italy, 72-81. Herr, C.M. and Fischer, T.: 2004, Using Hardware Cellular Automata to simulate Use in Adaptive Architecture, in: H.S. Lee and J.W. Choi: Proceedings of the Ninth CAADRIA Conference. Institute of Millenium Environmental Design and Research, Yonsei University Press, Korea, 815-828. Herr, C.M. and Kvan, T.: 2005, Using Cellular Automata to Generate High-Density Building Form, in B. Martens, and A. Brown (eds), Computer Aided Architectural Design Futures 2005. The Proceedings of The Eleventh International Conference on CAAD Futures. Springer Verlag, Dordrecht, 249-258. Herr, C.M., Fischer, T., Wang, H.F. and Wei, R.: 2005, Demand-Driven Generative Design of Sustainable Housing for China, in Tsou J.Y. et al. (eds), Proceedings of the Fifth China Urban Housing Conference, Vol. 2. China Architecture and Building Press, Hong Kong, 703-710. Herr, C.M. and Kvan, T.: 2007, Adapting cellular automata to support the architectural design process, Automation in Construction 16(1), 61-69.

158

Fischer, T. and Herr, C.M.: 2007, The Designer as Toolbreaker? Probing Tool Use in Applied Generative Design, in G. Yu, Q. Zhou and W. Dong (eds), CAADRIA 2007. The Proceedings of The Twelfth International Conference on Computer-Aided Architectural Design Research in Asia, School of Architecture, Southeast University and School of Architecture Nanjing University, Nanjing, China, 2007, 381-389. Herr, C.M. and Karakiewicz, J.: 2007, Algogram: automated diagrams for an architectural design studio, CAAD Futures 2007 [The Proceedings of The Twelvth International Conference on CAAD Futures] Sydney (Australia), July 11-13 2007, forthcoming. Hersey, G. and Freedman, R.: 1992, Possible Palladian villas, MIT Press, Cambridge, Massachusetts. Hesse-Biber, S.N. and Leavy, P. (eds): 2006, Emergent Methods in Social Research, Sage Publications, Thousand Oaks, Calif. Hopkins, D.: 2002, A teacher's guide to classroom research, 3rd end, Open University Press, Buckingham, U.K.

I Ilachinski, A. 2001, Cellular Automata: A Discrete Universe, World Scientific, Singapore; River Edge, N.J. Ishii, H., Underkoffler, J., Chak, D., Piper, B., Ben-Joseph, E., Yeung, L. and Kanji, Z.: 2002, Augmented Urban Planning Workbench: Overlaying Drawings, Physical Models and Digital Simulation, in Proceedings of Conference on IEEE and ACM International Symposium on Mixed and Augmented Reality (ISMAR '02). Itami, J.: 1994, Simulating spatial dynamics: cellular automata theory, Landscape and Urban Planning 30, 27-47. Ito, T.: 1996, Diagram Architecture, El Croquis 77(1), 18-24.

J Jones, J.C.: 1963, A method of systematic design, in J.C. Jones and D. Thornley (eds, Conference on Design Methods, Pergamon, Oxford. Jones, J.C. and Thornley, D. (eds): 1963, Conference on Design Methods, Pergamon, Oxford. Jones, J.C.: 1984, How My Thoughts about Design Methods have Changed During the Years, in N. Cross (ed) Developments in design methodology, Wiley, Chichester, 329-335.

K Kamps, T.: 1999, Diagram design: a constructive theory, Springer, Berlin; New York. Kemmis, S. and McTaggart, R. (eds): 1988, The action research planner, 3rd edn, Deakin University, Victoria, Australia. Kinsella, E.A.: 2006, Constructivist underpinnings in Donald Schön's theory of reflective practice: echoes of Nelson Goodman, Reflective Practice 7(3), 277-286. König, R. and Bauriedel, C.: 2005, Computer-generated City Structures, in C. Soddu (ed), Proceedings of the 7th Generative Art Conference 2004, Generative Design Lab, DiAP, Politectnico di Milano University, Milano, Italy. Project documentation also available online at: , viewed on 9 March 2007. Koutamanis, A.: 2000, Redirecting design generation in architecture, in International Conference on Generative Art 2000, Generative Design Lab, Milan, Italy. Koutamanis, A.: 2003, Autonomous mechanisms in architectural design systems, in Martijn and J. Verbeke (eds.), Local values in a networked design world – added value of computer aided architectural design, DUP Science - Delft University Press, Stellingwerff. Koutamanis, A.: 2006a, Digital Sketching: Means and Ends, in CAADRIA 2006 - Proceedings of the 11th International Conference on Computer Aided Architectural Design Research in Asia, Kumamoto (Japan) March 30th - April 2nd 2006, 277-286. Koutamanis, A.: 2006b, Recognizing architectural representations, Communicating Space(s): 24th eCAADe Conference Proceedings, Volos (Greece) 6-9 September 2006, 384-391. Krawcyk, R.: 2002, Architectural Interpretation of Cellular Automata, in: C. Soddu (ed), The 5th International Conference on Generative Art 2002, Generative Design Lab, DiAP, Politectnico di Milano University, Milano, Italy, 7.1-7.8. Kvan, T.: 2000, Collaborative design: what is it? Automation in Construction 9(4), 409-415.

L 159

Laing, R.D., Phillipson, H. and Lee, A.R.: 1966, Interpersonal Perception: A Theory and a Method of Research, Tavistock, London. de Landa, M.: 2002, Deleuze and the Use of the Genetic Algorithm, in A. Rahim (ed), Contemporary Techniques in Architecture, London, 9-12. Landay, J.A. and Myers, B.A.: 2001, Sketching interfaces: toward more human interface design, Computer 34(3), 56-64. Laurel, B. (ed): 2003, Design research: methods and perspectives, MIT Press, Cambridge, Mass. Lawson, B.: 1997, How designers think: the design process demystified, 3rd edn, Elsevier/Architectural Press, Oxford. Lawson, B.: 2004a, What Designers Know, Elsevier/Architectural Press, Oxford. Lawson, B.: 2004b, Schemata, Gambits and Precedent: Some Factors in Design Expertise, Design Studies 25(5), 443-457. Leclercq, P.P.: 2001, Programming and Assisted Sketching, Graphic and Parametric Integration in Architectural Design, Proceedings of the Ninth International Conference on Computer Aided Architectural Design Futures, Eindhoven, 8-11 July 2001, 15-31.

M March, L.: 1996, Rulebound unruliness, Environment and Planning B: Planning and Design 23(4), 391-399. McCullough, M.: 1996, Abstracting craft: the practiced digital hand, MIT Press, Cambridge, Mass. McCullough, M., Mitchell, W.J. and Purcell, P.: 1990, The Electronic design studio: architectural knowledge and media in the computer era, MIT Press, Cambridge, Mass. McLuhan, M.: 1994, Understanding media: the extensions of man, MIT Press, Cambridge, Mass. McMahon, T.: 1999, Is reflective practice synonymous with action research?, Educational Action Research 7(1), 163-169. Mitchell, W.J.: 1990, The Logic of Architecture: Design, Computation, and Cognition, MIT Press, Cambridge, Mass. Moore (ed), Emerging Methods in Environmental Design and Planning, MIT Press, Cambs, MA. MVRDV: 1999, Metacity/Datatown, 010 Publishers, Rotterdam.

N Negroponte, N.: 1970, The architecture machine, MIT Press, Cambridge, Mass. Negroponte, N.: 1975, Soft architecture machines, MIT Press, Cambridge, Mass. Negroponte, N. (ed): 1975a, Reflections on computer aids to design and architecture, Petrochelli/Charter, New York. Negroponte, N. and Groisser, L.G.: 1970, URBAN5: A machine that discusses urban design, in G.T. Neiman, B., Gross, M.D and Do, E.Y-L.: 1999, Sketches and Their Functions in Early Design - A Retrospective Analysis of a Pavilion House, in Design Representation: proceedings of 4th Design Thinking Research Symposium 1999, MIT, Cambridge, MA, August 23-25, 1999, 255-266. von Neumann, J.: 1966, Theory of Self-Reproducing Automata, A. Burks (ed), University of Illinois Press, Urbana, IL. Newell, A., Shaw, J.C. and Simon, H.A.: 1962, The processes of creative thinking, in H. E. Gruber (ed), Contemporary approaches to creative thinking: a symposium held at the University of Colorado, Atherton Press, New York. Newell, A. and Simon, H.A.: 1972, Human problem solving, Prentice-Hall, Englewood Cliffs, N.J. Norman, D. A.: 1993, Things that make us smart: defending human attributes in the age of the machine, Addison-Wesley, Reading, Mass. Norman, D.: 1999, Affordance, Conventions and Design, Interactions 6(3), 38-43.

O O'Sullivan, D.: 2000, Cellular Models of Urban Systems, CASA Working Paper 22, Centre for Advanced Spatial Analysis, University College London. O'Sullivan, D. 2001a. Graph-cellular automata: a generalised discrete urban and regional model. Environment and Planning B: Planning & Design 28(5), 687-705. O'Sullivan, D.: 2001b, Exploring spatial process dynamics using irregular cellular automaton models, Geographical Analysis 33(1), 1-18. Oxman, R.: 2002, The thinking eye: visual re-cognition in design emergence, in Design Studies 23(2), 135-164.

160

P Pai, H.: 2002, The portfolio and the diagram architecture, discourse, and modernity in America, MIT Press, Cambridge, Mass. Parthenios, P.: 2005, Conceptual design tools for architects, DDes Dissertation, Harvard Design School. Pask, G.: 1969, The Architectural Relevance of Cybernetics, Architectual Design 7(6), 494-496. Pask, G.: 1975, The cybernetics of human learning and performance: a guide to theory and research, Hutchinson, London. Park S.H. and Gero, J.S.: 2000, Categorisation of shapes using shape features, in J.S. Gero (ed), Artificial Intelligence in Design (AID’00), Kluwer Academic Publishers, Dordrecht. Pedgley, O.: 2007, Capturing and analysing own design activity, Design Studies 28(5), pp. 463-483. Peitgen, H.-O., Jürgens, H. and Saupe, D.: 1992, Fractals for the classroom, Springer-Verlag, New York. Phillips, A.: 2006, Lines of Inquiry, Architectural Review, January 2006, 68-73. Polaniy, M.: 1967, The tacit dimension, Routledge & K. Paul, London. Polanyi, M.: 2003, Personal Knowledge: Towards a Post-critical Philosophy, Taylor & Francis, London. Prusinkiewicz, P. and Lindenmayer, A.: 1990, The Algorithmic Beauty of Plants, Springer Verlag, New York Purcell, A. T. and Gero, J. S.: 1998, Drawings and the design process: a review of protocol studies in design and other disciplines and related research in cognitive psychology, Design Studies, 19(4), 389430.

R Rittel, H. and Webber, M.: 1973, Dilemmas in a General Theory of Planning, Policy Sciences 4, 155169. Rittel, H.: 1984, Second-generation Design Methods, in N. Cross (ed), Developments in design methodology, John Wiley & Sons, Chichester. Rittel, H. and Webber, M.: 1984, Planning problems are wicked problems, in N. Cross (ed), Developments in Design Methodology, Wiley & Sons, Chinchester, 135-144. Robbins, E. and Cullinan, E.: 1994, Why architects draw, MIT Press, Cambridge, Mass. Robinson, J. and Robertson, C.: 2001, The LivePaper system: augmenting paper on an enhanced tabletop, Computers & Graphics 25, 731-743. Rowe, P.G.: 1987, Design Thinking, MIT Press, Cambridge, Mass.

S Scheurer, F.: 2005, Turning the design process downside-up, in B. Martens and A. Brown (eds), Computer Aided Architectural Design Futures 2005, Springer, Dordrecht, 269-278. Schmitt, G.: 1993, Architectura et machine: Computer-aided architectural design und virtuelle Architektur, Vierweg, Braunschweig. Schön, D.A.: 1983, The reflective practitioner: how professionals think in action, Basic Books, New York. Schön, D.A.: 1985, The Design Studio: an exploration of its traditions and potentials, RIBA Publications Ltd., London. Schön, D.A.: 1988, Designing: Rules, types and worlds, Design Studies 9(3), 133-43. Schön, D. A. and Wiggins, G.: 1992, Kinds of seeing and their functions in designing, Design Studies 13(2), 135-156. Schrandt, R. and Ulam, S.: 1970, On Recursively Defined Geometrical Objects and Patterns of Growth, in A. Burks (ed), Essays on Cellular Automata, University of Illinois Press, Urbana, 232-243. Sejima, K. and Nishizawa, R.: 2000, Park Café, El Croquis 99(1), 122. Simon, H.A.: 1981, The sciences of the artificial, 2nd edn, MIT Press, Cambridge, Mass. Sobek, D.K. II and Patel, D.: 2005, Representations in circuit design: a test of Goel's theory of notationality, Proceedings of the 2005 International Conference on Education and Technology, Calgary, Canada. Soufi, B. and Edmonds, E.: 1996, The cognitive basis of emergence: implications for design support, Design Studies 17(4), 451-463. Stapleton, A.: 2005, Research as Design - Design as Research, DIGRA 2005, 17-20 June 2005, Vancouver. Steadman, J.P.: 1976, Graph-theoretic representation of architectural arrangement, in L.J. March (ed), The architecture of form, Cambridge University Press, Cambridge. 161

Steadman, J.P.: 1983, Architectural Morphology, Pion, London. Steadman, J.P.: 2006, Why are most buildings rectangular?, Architectural Research Quarterly 10(2), 119-130. Steele, J.: 2001, Architecture and Computers: action and reaction in the digital design revolution, Watson-Guptill Publications, New York. Stewart, I.: 1992, Another Fine Math You've Got Me Into, W.H. Freeman, New York. Stiny, G.: 1975, Pictorial and formal aspects of shape and shape grammars, Birkhaeuser, Basel. Stiny, G.: 1980, Introduction to shape and shape grammars, Environment and planning B 7, 343-351. Stiny, G., and March, L.: 1981, Design Machines, Environment and Planning B: Planning & Design 8(3), 254-255. Stiny, G. and Mitchell, W.J.: 1978, The Palladian grammar, Environment and Planning B, 5-18. Strauss, A. and Corbin, J. (eds): 1997, Grounded theory in practice, Sage Publications, Thousand Oaks, Calif. Suwa, M., and Tversky, B.: 1996, What architects see in their sketches: Implications for Design Tools, Vancouver, 1996. Swann, C.: 2002, Action Research and the Practice of Design, Design Issues 18(1), 49-61.

T Testa, P., O'Reilly, U-M., Weiser, D. and Ross, I.: 2001, Emergent Design: a crosscutting research program and design curriculum integrating architecture and artificial intelligence, Environment and Planning B: Planning & Design 28(4), 481-498. Toffoli, T. and Margolus, N.: 1987, Cellular Automata Machines, MIT, Cambridge, Mass. Torrens, P.M. and O’Sullivan, D.: 2001, Cellular automata and urban simulation: where do we go from here?, Environment and Planning B, 28(2), 163-168.

U Ulam, S.: 1952, Random processes and transformations, in Proceedings of the International Congress of Mathematicians, volume 2, American Mathematical Society, Providence, Rhode Island, 264-275.

V Venn, J.: 1880, On the Diagrammatic and Mechanical Representation of Propositions and Reasonings, The London, Edinburgh, and Dublin Philosophical Magazine and Journal of Science 9(59), 1-18. Vidler, A.: 2000, Diagrams of Diagrams: Architectural Abstraction and Modern Representation, Representations 72, 1-20.

W Watanabe, M.S.: 2002, Induction design: a method for evolutionary design. Birkhäuser, Basel. Whitin, P. and Whitin, D.: 2000, Math Is Language Too: Talking and Writing in the Mathematics Classroom, NCTE, Urbana, IL. von Wodtke, M.: 2000, Design with digital tools: using new media creatively, McGraw-Hill, New York. Wolfram, S.: 1984, Universality and complexity in cellular automata, Physica D 10, 1-35. Woolley, M.: The Thoughtful Mark Maker: representational design skills in the post-information age, in G. Goldschmidt and W.L. Porter (eds), Design Representation, Springer, London, 185-201.

Y Yakeley, M.: 2000, Digitally mediated design: using computer programming to develop a personal design process, PhD thesis, MIT. Yeh, A.G. and Li, X.: 2002, A cellular automata model to simulate development density for urban planning, Environment and Planning B 29(3) 431-450.

Z Zhang, J.: 1997, The nature of external representations in problem solving, Cognitive Science 21(2), 179-217. Zuber-Skerritt, O.: 1992, Professional development in higher education: a theoretical framework for action research, Kogan Page, London.

162