between worlds:

tensions and opportunities of research in computer-aided architectural design

extended abstract – remarks for GCADS symposium at Carnegie Mellon University, July 11-14 2004; Ellen Yi-Luen Do and Mark D. Gross

Our field, computer aided architectural design is in many ways “between worlds.” This makes for a sometimes confusing landscape. To become an expert, a student in computer-aided architectural design must master (at least) two core competencies: design and computing. These two are widely, even wildly, different in culture and ways of knowing. Despite some tensions that arise from this odd juxtaposition, this area of research offers tremendous opportunities that bridge the worlds of design and computation.

Knowing design, knowing computing

In the business of “knowing design”, we can identify several ways of knowing. We might call them the way of the practicing designer, the way of the cognitive scientist, and the way of the design theorist. The practicing designer brings to the discipline a first-hand understanding of the task and domain for which there is no substitute, but also (at least in many cases) a set of prejudices and beliefs that run counter to the effort to build computational methods and models. The cognitive scientist studies the efforts of designers, both individually and in groups, and analyzes processes of design as carried out by human beings. The design theorist investigates the principles of design, irrespective of human cognitive capacities or predilections. Each of these quite radically divergent approaches contributes to our understanding of design.

In the business of “knowing computing,” there is also much to know; although here the diversity entails different domains of computing. We might divide the territory into knowing hardware, knowing software, and knowing about the interface of computing with people. Although computing machines exist as mathematical entities apart from any hardware implementation, in practice it is useful to understand what is going on inside the box; and knowledge of hardware is likely to continue to be useful as pervasive computing becomes increasingly important. Knowing software and being able to build software artifacts to demonstrate ideas, has been a key feature of computer aided design research since the earliest days. The knowledge needed has grown tremendously. One might be expected to know something about programming languages and algorithms, databases and operating systems, and technologies that have been used in artificial intelligence research such as production rules, genetic algorithms, constraints, and case based reasoning. Finally, in the realm of human-computer interaction, one studies both the methodologies of usability engineering, empirical results such as Fitt’s law, and a tremendous range of work from computer-supported collaboration to toolkits for building tangible user interfaces.

Tensions in computer aided design research

Researchers in computational design are much between worlds. When we’ve mastered an array of diverse expertise, research in CAAD gives rise to a strange set of tensions, even dichotomies.

•On one hand, we work (for the most part) in schools of architecture, where expertise remains defiantly implicit. The culture of architecture (and that of other allied arts) insists that design follows no rules; and that design expertise cannot be subjected to scrutiny. On the other hand the effort to build tools demands that we make design expertise explicit.

•On one hand, our architectural colleagues often see us as rationalists who seek to “reduce” design to a science. On the other hand, our computer science colleagues often see us as artists and would engage us in questions of aesthetics.

•On one hand, professional students demand training in CAD software, and (quite reasonably, pragmatically) have little interest in developing future systems. On the other hand we seek to replace, rather than celebrate, these impoverished tools. There’s an inherent tradeoff between the degree of innovation in a computational design system and the degree of polish and practicability. Embedding experimental modules within existing CAD packages is a strategy to sidestep this tradeoff but this has its own difficulties.

•As computationally oriented researchers in design, we do belong to wider communities, most importantly the community of researchers who study design (whether empirically or computationally) in other fields, for example in industrial, mechanical, civil engineering. Yet due to the disciplinary division of universities, we often fail to realize the benefits belonging to this community of colleagues who are doing similar work in other domains.

These tensions have many implications for how we conduct research, and even what research we conduct. Implications include academic concerns of tenure and promotion, the balance of teaching and research, the ways of supporting research with funding, and opportunities for research to have real-world effects.

Opportunities in computer-aided design research

If there are tensions and challenges, there are also opportunities in computational design research. The past decades have seen many advances in computer hardware and software. Many problems that rested only on computing technologies have been solved. For example, visualization and animation of proposed built environment, once an area of research in computer aided design, is not only a solved problem, it’s a commercial product. Yet there is much still to do. We might organize the opportunities in several categories:

•fundamental advances in tools for designing

•applications of basic design research to specific architectural tasks

• tools and processes for computer aided manufacturing

•design of the computationally mediated built environment

The first, advances in tools for designing, is the traditional domain of our field. It entails a tremendous breadth of tasks and techniques. For example, topics under this category include structuring design knowledge computationally (from issue based information systems to semantic nets to building product models); synchronous and asynchronous collaboration (from shared 3-D models to annotation); fundamental research in [generative] geometry; human computer interaction techniques for making computational design tools more accessible.

The second, applications to architectural tasks, covers a wide range of ways in which “core” research can be brought to bear on problems that face architectural researchers and practitioners. Historically, energy and daylighting have been areas in which computer simulations are used to support design decision-making. Today we have the computational speed and power to make quite good energy calculations quickly. What is needed is to integrate these simulations into the tools that designers use, so that architects can better take advantage of the information. Likewise, computational tools for simulating the movement of people within buildings and in the streets and plazas are becoming quite sophisticated, and these tools can be better integrated into the architect’s working environment. Another example is the knowledge bases of design information for decision making, for example online indexed case libraries of designs. None of these technologies are new, but the time has come to make them more accessible to working architects.

The third area of opportunity deals with computer aided manufacturing, which recently has drawn much attention in the community of professional architecture practice. Research in this area explores the kinds of design tools that could help architects make good use of rapid prototyping and direct manufacturing.

The fourth area of opportunity, design of computationally mediated environments, recognizes the coming impacts of pervasive computing, tangible user interaction, and so on. The architectural implications of integrating computational processes into the materials and spaces of the built environment are far too important to be left entirely to engineers and technicians.

Where it all comes together: the built environment

What all these diverse activities and opportunities have in common is a core concern with the built environment. Some deal with the computationally based tools for designing it. Some deal with the computationally driven machinery for making it. Some deal with the ways that computation is becoming part of the built environment itself. And ultimately, we must judge the work we do by whether it leads to the ability to build better built environments.