Design Ecosystems: Customising the Architectural Design Environment with Software Plug-ins

Introduction

D

esign environments are undergoing a perceptible shift in authorship. Advances in scripting interfaces are empowering architects to create parts of their own design environments. The boundaries between end user and developer are falling down around a network of designers sharing their creations as part of an emerging design ecosystem.

While computer-aided design (CAD) software has included scripting interfaces for many years, and there have been select individuals who have used this functionality to develop digital tools, the number of designers now using these scripting interfaces is increasing. What they are using it for, as well as how they are using it, are also changing. It is no longer only the CAD specialist writing scripts to increase efficiency or manage construction data, but also the designer creating geometry and finding form through sketching with code [1].

Through the introduction of better-performing scripting capabilities in CAD software, designers have been able to quickly generate large amounts of geometry using relatively simple scripts. For example, the Visual Basic for Applications (VBA) scripting interface included with Bentley Systems’ MicroStation v8 in 2001 was vastly superior to the Basic scripting interface included with v7 (1998). These generative or analytical algorithms can be shared, either through computer code or through packaging the script with an easy-to-understand interface. Through a combination of using common geometric elements, and outputting data to simple formats such as text files or spreadsheets, these computational techniques allow a diverse range of design software, analysis techniques and fabrication methods to be linked.

Beyond the scripting interface, some designers are finding further potential to shape the design environment itself. A number of designers have been developing ‘plug-ins’ that function as core parts of existing CAD platforms. The process of development is similar to the computer-programming techniques of scripting, but unlike scripts these plug-ins are packaged as small pieces of software and themselves become part of the design environment. Each plug-in emerges to address a specific problem or opportunity that an architect has identified in their work, thus widening the digital design environment around the desires of the individual designer.

Not only are more and more architects computer programming, writing scripts and creating plug-ins, but these are increasingly being shared via the Internet, conferences and workshops [2]. This marks the formation of a new design ecosystem, one under constant evolution and catalysed by sharing at a scale never before seen, that is simultaneously a community of architects and a collection of related algorithmic concepts. This design ecosystem is probably growing in a CAD environment near you.

The Cathedral and the Bazaar

One way of structuring a CAD environment is to have it do everything: a single self-contained application that can take a design from massing to construction drawings, from positioning doors to producing schedules, from creating geometry to composing visualisations. By integrating all of these components, each part can make assumptions and guarantees about how the rest operate, saving the designer the indignity of converting CAD files into different data formats (if this is even possible) and from having to purchase many different standalone softwares. This monolithic process is the holy grail of project lifecycle management (PLM) and, arguably, its brethren building information modelling (BIM).

The self-contained design environments set up to support these monolithic processes belong to a software category that Eric Raymond calls ‘cathedrals’ – large applications crafted by a highly talented group working together in isolation [3].
Raymond contrasts the cathedral with the ‘bazaar’ – a marketplace in which the collective action of individuals contributes to the larger community. For architects, the dichotomy exposes the fact that for many decades design environments have almost exclusively consisted of cathedrals.

Breaking the norm, Robert McNeel & Associates’ Grasshopper® is a bustling bazaar-type environment. Grasshopper is a graphical programming environment that runs within Rhinoceros® CAD software, where architects visually link together components that are conceived of, and created by, other architects rather than by a team of software engineers. Even McNeel’s sole developer on the project, David Rutten, has an architectural background rather than a formal computer science education. While Rutten controls the core, he is joined by a community of architects who freely share the plug-ins that make up Grasshopper.

Animals in the Jungle

This section of the issue features the plug-ins: Galapagos, Kangaroo, Firefly, WeaverBird, GECO™ and Pachyderm Accoustical Simulation. Unlike the teams of specialist developers working on monolithic CAD applications, the creators of these Grasshopper plug-ins work alone or in pairs, and they are all end users. Significantly, their plug-ins are motivated by specific problems they have encountered in their own architectural practice. They also share their work, for free, through the sizeable online community. This ‘bazaar-esque’ community serves to shape the design ecosystem by implicitly encouraging or discouraging particular plug-ins. A traditional hierarchical structure does not apply since popularity is based on usability and functionality rather than on limitations of access, cost or compatibility. There is such a market for these plug-ins that one wonders whether, in future, they will be sold more formally as apps.

The focus of each plug-in on a particular niche problem follows what Doug McIlroy has termed the Unix philosophy of programming: to ‘write programs that do one thing and do it well. Write programs to work together’ [4]. It is the ‘working
together’ that distinguishes the Grasshopper environment, for all the plug-ins within it can freely exchange data with one another. For instance, WeaverBird can panel a structure designed in Kangaroo without the designer manually converting the data, and without the authors of either plug-in needing to coordinate with each other. This is in large part due to the Grasshopper application programming interface (API) developed by David Rutten, which formalises the exchange of data around simple collections of basic geometric primitives. This ‘geometric- content-based’ data exchange is in opposition to BIM’s ‘assigned- attribute-based’ data structures [5], and is a simplification that enables plug-ins to easily work together.

There is a diverse range in what the plug-ins do, but each facilitates a translation of some kind. GECO and Firefly serve as translators between Grasshopper and other sources of data; GECO connects to the Autodesk® Ecotect® environmental analysis package, while Firefly sends and receives data from the Arduino microcontroller platform. The remaining plug-ins all translate research into accessible components. For instance, WeaverBird takes work done by computer scientist Edwin Catmull and others, and packages it for designers unfamiliar with the mathematics. As such, knowledge normally locked away in esoteric research is made accessible to the point where a designer can use it without needing to necessarily understand what he or she is designing with. Sherry Turkle describes this as ‘Macintosh Transparency’ (transparent because nothing gets in the way), which she places in opposition to ‘Modernist Transparency’ (transparent because you can see how everything works) [6]. In Turkle’s view, Macintosh Transparency risks producing designers who are ‘drunk with code’, designers so enamoured with the results that they fail to see that the plug-in translates a far more nuanced concept [7].

Beyond Toolmaking: The Architect’s Role

Architects are expert coordinators: of building projects, of different disciplines and building trades, and of bringing together the multitude of parameters and constraints that define the boundaries of a project. While there are inherent dangers in not knowing what lies within a black-box piece of code, it is part of the definition of the architect not to know everything, but to know enough; they alone understand the overall concept and hold together the project. As architects adopt the coordination of code in addition to the coordination of design and construction, their role diversifies.

The coordination and creation of the design environment is itself becoming the domain of the designer. These are environments orchestrated by architects from core components created by architects, environments continually changing in dialogue not only with the project, but also with particular stages of it [8]. In this sense, these continually evolving design environments are unlike any static design tool, and unlike any design environment architects have previously encountered.

It is this evolution of the design environment that provokes the designer’s new role. For the environment to adapt easily, the designer must ensure the relationships between components are flexible enough to accommodate unexpected changes. If the designer fails to do so, writes Mark Burry, ‘there is no solution other than to completely disassemble the model and restart’ [9]. When such a moment of inflexibility occurs, in the best case it causes an unexpected delay to the project while the relationships are reorganised. However, in the worst case the designer is dissuaded from making the change and ends up with a design that was not so much created in their design environment as it was for the limitations of that environment. To avoid these difficulties, architects must take on a role of actively maintaining flexible relationships between components within the design environment.

The role of the architect as the creator of generative scripts or developer of plug-ins goes beyond the creation of conventional digital 3-D models. It also goes beyond that of tool-maker, as creation, modification and coordination of the design environment becomes an integrated part of the design product. The design environment of which the architect is now part-author must be flexible and have the ability to accommodate change, and this represents a significant shift in authorship away from isolated teams of highly talented programmers towards end users collaboratively shaping their own environment.

Notes

1. Mark Burry, Scripting Cultures: Architectural Design and Programming, John Wiley & Sons (Chichester), 2011.
2. Rob Woodbury, ‘Design Flow and Tool Flux’, in Brady Peters and Terri Peters (eds), Inside Smartgeometry: Expanding the Architectural Possibilities of Computational Design, John Wiley & Sons (Chichester), 2013.
3. Eric Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly Media (California), 1999.
4. Peter Salus, A Quarter Century of Unix, Addison-Wesley (Boston, MA), 1994, p 52.
5. Andre Chaszar, ‘Navigating Complex Models in Collaborative Work for Integrated (and Sustainable) Design’, in Pierre Leclercq, Ann Heylighen and Geneviève Martin (eds), Proceedings of the 14th International Conference on Computer Aided Architectural Design Futures, Les Éditions de l’Université de Liège (Liege), 2011, p 625.
6. Sherry Turkle, Simulation and its Discontents, MIT Press (Cambridge, MA), 2009, p 44.
7. Ibid, p 7.
8. See Daniel Davis, Jane Burry and Mark Burry, ‘Understanding Visual Scripts: Improving Collaboration Through Modular Programming’, International Journal of Architectural Computing, Vol 9, No 4, 2011, p 372; and Brady Peters and Hugh Whitehead, ‘Geometry, Form and Complexity’, in David Littlefield (ed), Spacecraft, RIBA (London) 2008.
9. Mark Burry, ‘Parametric Design and the Sagrada Família’, Architectural Research Quarterly, Vol 1, No 4, July 1996, p 78.