Rethinking Prototyping

Robert Aish

Autodesk, London, United Kingdom

Design computation is understood to mean the direct application of computational concepts and operations to the formulation and resolution of design problems. In this approach, the designer, architect or engineer, etc. - directly or indirectly - writes a computer programme whose execution generates the design configuration and geometry. This can be contrasted to other non-computational forms of design, where the final resulting configuration and geometry are manually constructed by the designer or draftsman potentially with the assistance of an interactive computer graphics application. In this manual approach there is no representation of the design logic or intent which is independent of the geometry created.

In computational design, the designer must not only think about the result that he wishes to achieve but also the exact sequence of operations or intermediate constructive elements that when executed will achieve the desired outcome.

Design computation is an example of an investment-reward process. It is generally agreed that if the designer can make the initial investment in such a generative programme, then it will be subsequently much easier to explore alternative design options simply by changing the value of the driver variables, watching and evaluating alternative designs being generated. The challenge is to create a computation environment which can provide a gentle learning curve for designers with little or no prior computational experience to start this investment-reward process. Such a system must both provide the designer with immediate practical results, the reward, and at the same time encourage him to take risks and explore new unfamiliar concepts and techniques, the investment.

1.3 What Are the Characteristics of Computational Tools That Are Appropriate for Design?

To create a successful design-computation system, which can be an appropriate learning environment, we have to address the process by which designers express design logic both either explicitly or implicitly as executable code and the characteristic of the tools or languages, which might be used. For example, how do the characteristic of the tools and languages relate to the skills or interests of the designer?

In the main, conventional computer programming or scripting languages, such as Python, Java, C# and VB are based on imperative programming. “Imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way that imperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform”[1].

There are many successful examples of imperative languages being used in design computation, but for the designer with no prior computational experience these languages often present an abstraction barrier. “The abstraction barrier is determined by the minimum number of new abstractions that must be mastered before using the system” [2]. Applying this to learning and using an imperative language, and we can see that the number of abstraction that have to understood and operationalized is quite daunting for designer, as the novice programmer.

The question remains, how can we offer tools to the designer that avoids this initial abstraction barrier? The long-term objective is not to encourage the designer to completely avoid imperative programming. Indeed this type of programing has considerable applicability and value to design computation and the abstraction barrier is not insurmountable. The approach proposed here is to gradually introduce this and other advance computing concepts via a less arduous route and at the appropriate moment when the designer has recognised the limitations of other more easily learnt approaches.

In response to the limited success of text based imperative language in design, a completely different approach to computation, called dataflow programming, has emerge. “Dataflow programming is a programming paradigm that models a program as a directed graph of the data flowing between operations, thus implementing dataflow principles and architecture”[3].

Typically, graph nodes represent operations, including the data resulting from these operations, and the arcs of the graph represent the flow of data, including the implied dependencies, between nodes. Applications such as MAX-MSP [4], GenerativeComponents [5] and Rhino Grasshopper [6] are examples of a dataflow approach to design computation.

A particular advantage of dataflow programming is that the underlying graph can be represented visually and this provides an intuitive users interface for end-users with little or no programming experience. Indeed, the success of these applications is mainly due to the way in which designers, as novice end-user programmers, have been able to express design logic without having to acquire knowledge of conventional programing syntax. Quite possibly, the designers using these dataflow applications do not even consider this to be programming.

There are two criticisms of graph based data flow applications. The first criticism is that the human use of such dataflow systems does not scale to complex problems. Of course the graph technology can deal with thousands of nodes. But a design computation application is an example of a man-machine system and the art of designing a successful man-machine system is to match the characteristics and representation of the machine component to the capabilities of the man. It is the human capacity to comprehend the graph which is the limiting factor. Therefore, what starts off as a useful explanatory tool with five to 20 graph nodes becomes unfathomable with 100 nodes. As the underlying problem increases in complexity, the graph system appears to add visual complexity non-linearly rather than to continue to provide clarity. Essentially an initial advantage of the visual graph representation eventually becomes a limitation.

Most of the data flow applications allow custom nodes to be implemented using existing high-level languages such as Python or C#. This enables the dataflow system to access external libraries and also allows the designer to implement functionality using imperative programming. This approach is particularly useful where the design logic being implemented might not be suited to data flow programming. However, a second criticism of these applications is that the gap in level of skills required between using a graph-node user interface and using high-level imperative languages is often too extreme for the novice programmers to overcome (Fig. 1).

Fig. 1 Existing dataflow applications provide an initial ease of use for novice users with simple graph-node models, but do not scale to complex problems. Essentially, there is no continuous learning curve between dataflow diagramming and programming in conventional high-level imperative languages.

The intention in the development of DesignScript is to address these two issues by providing a single, continuous and gentler learning curve between data flow diagramming and more complex forms of design computation (Fig. 2).

This learning curve represents a potential progression in skills on the part of designer, his use and understanding of progressively more powerful computational concepts and techniques. Underlying this is also the idea that the designer will be progressing from an exploratory style of programming to more formal software engineering methods, potentially leading to the development of re-usable class libraries.