Capturing Design
What he showed in this experiment was that the kinds of problem designers were likely to identify and solve were to some extent dependent on the kinds of representations they used.
Bryan Lawson (Lawson 1999, citing Eastman 1970)
To a man with a hammer, everything looks like a nail.
Mark Twain
Designers use their minds to define and solve complex problems containing many elements, more than their limited short-term human memory can easily retain. To augment their memory, they create external representations, objects such as notes, sketches, drawings, or physical models. While these external representations are often thought of as being the design, each captures only aspects of it. In this way the designer is able to grapple with complex configurations and pay attention to different elements of the design without losing track of information while their attention is elsewhere. Representations have additional value when they can be used as the foundation for computational evaluation or analysis of the design proposal, or as communication tools by which to convey design intent to clients, contractors, or other interested parties.
During the process of creating a representation, a semantic payload, or meaning, is attached to or embedded in the design artifact, a process that may be awkward and frustrating or fluid and effortless, depending on the fit between the designer’s goals and skills and the characteristics of the medium. At a later time the designer can retrieve their ideas or concepts about the project, organizing principles, etc. by viewing the representation. Recorded meanings may be explicit (words or dimensional drawings) or associative (diagrams or words that evoke a particular memory).
Individual representations are also members of a class of similar artifacts, referred to with collective nouns such as plans or sections. As the epigraph indicates, the particular representation is not a neutral repository for information; the choice of representation and subsequent problem solving are linked.
Historically, drawings have been the dominant representational form in architecture. Sketches done quickly as part of early design exploration may indicate only important features of the site context, or basic relationships between project parts. Subsequent schematic drawings may give those relationships spatial form and approximate geometry, but these will be redrawn during design development with greater care for relations, scale, and spatial sizes. While each of these may be a “drawing,” they serve differing cognitive roles, involve different levels of geometric precision, and draw on increasingly deeper reservoirs of project knowledge. It seems unlikely that a single tool would be suitable to all of them.
By augmenting our short-term memory, external representations allow us to engage complex problems, but each is created to address a particular set of issues, and is thus incomplete—just one of a (potential) set of related representations. It is not the only way a particular meaning might be conveyed, and it requires some skilled interpretation. It is a rendering of the designer’s intent, created within the cultural context of the design office, expressing their style. It is incomplete in any of several ways, perhaps showing only part of the building, or focusing on the spatial layout but not the structure, etc.
Many alternative representations exist and are, in some sense, equivalent and interchangeable. This makes conversion between representations, and coordination of multiple representations, important tasks. Traditional design workflows locate the designer at the center of the resulting confederated representation, responsible for interpreting and checking information against the central design intent. This gives the designer great power over the final product, but requires significant time and expense and hinders implementation of digital processes. Since the vast majority of design work is now done digitally, it seems desirable to shift this responsibility by creating a single central digital representation (e.g., a BIM) from which others can be constructed or extracted as needed. Establishing such a representation and working out appropriate ways for all industry participants to create, interact with, and refine them is one of the core challenges of design computing, and faces a number of hurdles.
This chapter looks at representations in terms of their relationship to the cognitive task, underlying primitives, organizing relationships between parts, compactness, convertibility, expressive range or power, and level of abstraction. Good representations can be examined, or queried, to find out things we didn’t know before. They may be shared with others, edited or extended, stored and recalled later. Good representations facilitate design by presenting appropriate abstractions and tools for different phases of design, making it easy to make changes at a level consistent with the design’s evolution. A good representation communicates clearly to others, while inappropriate ones confuse discussion; but few, if any, representations are appropriate to all designs or all aspects of a design.
Representation and Cognition
Why do we use representations? The usual answer is that the limitations of human memory make it hard to keep track of all the details. Working memory is generally limited to 7–10 items of information. Recording information in written or drawn form preserves it. It also allows hierarchies containing related information “chunks” to be developed and manipulated. In this way, representations help us organize the cognitive task, linking our present and future selves.
Every representation is created by expressing an internal mental model in the vocabulary of the representational medium. A painter may imagine colors that don’t exist, but can’t paint with them. At the same time, knowledge of color theory and a supply of primary colors may enable them to create colors not yet available in the paint box. Awareness of the vocabulary and knowledge about how to stretch it to fit current needs are parts of the process. The painting emerges through an exchange of information between the painter’s head, the canvas, and the paint box.
Of course, if the goal of design is Simon’s “action aimed at changing existing situations into preferred ones,” strapping on a tool-belt may seem more direct. It is, but it might not be the most efficient way to make change happen; where you can speak to a few people directly, an email expressing the same ideas can go to thousands. Where you can pick up a few boards, your mouse can indirectly move mountains. That’s because representations can be used to communicate to others, leveraging our time and energy.
Efficient action is nice, but correct action is even better; remember the old advice to “measure twice, cut once.” The design process uses representations to estimate the consequences of proposed changes before they happen, avoiding mistakes, cost, and injury. Representations must offer the means to preview, or simulate, consequences.
In the end, the rationale for expressing a building in any form except the finished product must identify power over the design as one of the main motivations. Designers create external representations to overcome limits of human cognition, in order to test and refine the proposal, and in order to clarify and communicate design intent. When changes are easily implemented and easily reversed—as when rearranging furniture in a room—we might simply make a change and see if we like the result. In such a situation, the design representation (the furniture layout in the room) is identical to the design problem. There is no abstraction involved; we can immediately evaluate the result visually, though we may have to guess about other aspects—such as how it will look in different seasons, or how well it will work during a party.
When it is not easy to implement or reverse a change, we often employ an external representation, such as a drawing or model, to help us design. As indicated in the epigraphs, the particular external representation chosen (whether digital or not) is important because it influences workflow, productivity, information management, and design cognition.
Representation and Analytical Power
As described in Chapter 2, computational tools combine a representation or model (information) with algorithms (processes) that change or act on the representation. Representations are static, while processes are dynamic. The two are tightly coupled, a bit like nouns and verbs in written language. As with language, effective human expression and communication requires control of both the representation and the algorithm, and they can range from the nuanced and elegant to the crude and obtuse.
Consider, for example, the way most of us were taught to compute sums on multi-digit numbers:
The traditional algorithm for computing the sum goes something like this (given that we have memorized single-digit sums): start in the 1s place; add 4 + 6 for 10. As 10 requires two digits and we only have room for one, record the 0 in the 1s place of the result and carry the 1 over into the 10s place. Next, 2 + 1 + 1 (the carry-over) for 4 in the 10s place, with no carry-over. Now add 0 + 5 = 5 in the 100s place. Only the first number has an explicit value in the 1000s place, but there is an implicit 0 in the second number, so add 1 + 0 = 1 for the 1000s place. Final result: 1540.
Interestingly, this algorithm works equally well if the numbers are expressed in base two (binary numbers):
10000000000 + 01000000100 = 11000000100
However, it does not work well if the numbers are expressed as Roman numerals, where the order of characters in the representation is more important than their position:
The same quantitative meaning exists in each case, but the chosen representation influences what you can do with it and how easily; different representations require different algorithms.
A more graphical example arises in the context of subdividing large areas into smaller ones. In a landownership application you might consider each piece of property to be a polygon. This is the way the landowner tends to think of it—in terms of the boundary of their property. However, the different edges of a property boundary are shared with each of the neighbors. If each boundary is stored separately as a distinct polygon, problems may arise. For example, it is hard to guarantee that there aren’t slivers of overlapping or unassigned property since the boundaries are duplicated and stored in different places. Further, if someone decides to give their neighbor a 10 foot (3 m) easement, the information needs to be stored in two places in the database, and updating it means finding the two boundary polygons. Fortunately, the winged edge data structure commonly used in geographic information systems is ideally suited to keeping track of boundaries such as this, and can be used to rapidly identify the unique boundary polygon of each property while being certain that all land is accounted for and there are no overlaps.
High- and Low-Level Primitives
Every digital representation is created from a vocabulary of fundamental parts, or primitives, each with certain qualities or attributes. These are designed into the software, represented via patterns of bits in memory. They are also what distinguish between BIM, CAD, and paint programs. These primitives are stored in a data structure that establishes simple or complex relationships among the parts, including lists, graphs, and hierarchies.
An application might use high-level primitives (e.g., “rectangle”), or it may employ low-level primitives (e.g., “line”) to accomplish the same visual effect. User interfaces may mask the distinction by providing a tool that appears to draw a rectangle, but actually creates four lines in the drawing database. It may seem like a trivial distinction, but it dramatically changes what the user can do with the representation. The opposite sides of a rectangle remain parallel while a collection of lines need not, so a rectangle cannot be made into an arbitrary parallelogram. A rectangle is a closed shape while four lines need not be, so a rectangle can have a fill-pattern as an attribute, while the collection of lines may not.
Representation and Embedded Knowledge
The information in a digital representation, the data and its organization, is purposeful. There are specific ideas of how it can and will be used in a productive workflow. Every program is built around a particular representation, combining knowledge and process. The representation can encode disciplinary knowledge about the problem the software is meant to address, while the software’s algorithms encode process knowledge.
Figure 8.1 illustrates this by comparing two representations that produce the same graphic figure—a rectangle. The left-hand representation embeds knowledge in the data by naming the primitive (RECT) and uses knowledge about rectangles to parameterize the figure using the coordinates of two diagonally opposite corners. The right-hand side shows an alternative representation constructed of four LINE primitives, each defined in terms of its endpoint coordinates. It is straightforward to extract and draw the four edges of a rectangle as lines, if needed, as shown in the lower left portion of the figure. The four lines, on the other hand, are not required by the rules of geometry to form a rectangle, but they might. The knowledge (RECT or not) missing from the representation can be created by using process to determine whether the lines satisfy the geometry conditions shown on the lower right. For this reason a rectangle is said to be a higher-order primitive than a line. The knowledge embedded in a system’s representation can be seen as guiding the user to appropriate choices (Clayton 2014) and aiding productivity by reducing attention required to complete the task. It might also be seen as coercive or overly restrictive, depending on how well the representation fits with the designer’s cognitive model, and how the user interface is implemented.
Figure 8.1 Alternative representations may look similar, but behave differently when edited.
It seems that as representations become more focused and incorporate more specific disciplinary knowledge, their expressive range narrows, but they become more powerful and efficient within that disciplinary envelope. Simple low-level representations, such as those embedded in basic paint and draw programs, require greater cognitive involvement on the part of the designer, but offer a wider expressive range. If this observation holds, it may be that as we seek to embed more information in a unified building model, our interactions with it will become ever more ponderous and labored.
This may explain the simultaneous expansion of interest in BIM tools, whose highly developed representations may both empower and uncomfortably constrain design exploration, and scripting, in which the designer, using simpler manipulations of lower-level primitives, gains expressive freedom that might not otherwise be available. The cognitive engagement that accompanies such work also echoes the theory of desirable difficulty which has shown that students taking pen and paper notes in lecture classes reword content and develop deeper understandings than those with laptops, who tend to produce verbatim transcripts (Mueller and Oppenheimer 2014).
Representation, Affordances, and Task
Consider how your spreadsheet differs from your word processor. They both store text and numbers. You can position the insertion point in either one, and begin typing text. You can select sections of text and make them bold or italic. Both programs will add headers and footers to your pages. But your spreadsheet does not (happily) do word-wrap, so you must pay attention to line length and use the enter key to start a new line when needed. Changes during editing—insertion or deletion—will force you to re-flow the contents of your paragraph. Now, think about building a budget in your word processor. It will let you define tables, select cells and type category names and numbers, align columns, and even do simple math on the numbers, but it won’t change the number of digits after the decimal point in a column of numbers, and it won’t do complex calculations. The word processor and the spreadsheet share certain features, including elemental data types and simple formatting, but the relationships they enforce between the parts are different—they present different affordances to the user. They each offer good representations for their primary tasks, but rather weak representations for the other task, which is probably why both applications remain distinct tools on our desktops.
Now consider the relatively simple task of cropping a raster image. A high-end application such as Adobe Photoshop can do this easily, but a new user may find it difficult to locate the appropriate tool amid the many options available in the interface.
It is necessary to match task, representation, user interface, and cognitive state of the user in order to produce a positive experience. Doing so with a single tool that spans from the fuzziness of early design to the precision of detailed design is likely to be a challenge. The field of user experience design (UxD) has emerged, in part, to address this challenge.
Common Representations and their Problems
Chapter 5 described the state-of-the-art as regards commercial CAD and BIM systems, but if you ask a designer what they’re doing with their notebook and pen or pencil/stylus, you’re likely to get an answer with words like “concepts” and “sketching ideas” or “exploring relationships” or maybe “working out a problem.” If pressed, they’ll probably reference “forces” and “activities” or “organizing principles.” These words describe the conceptual contents that their drawing or sketching media are used to capture, the design elements they work with cognitively while their pen or pencil makes marks on the page. One reason that pen and paper remain popular is that, while simple, they may be used to construct complex representations with very different semantic content. While individual computer programs may deliver the power of particular analog activities, from free-form doodles to 3D sketching and BIM, each imposes its own set of requirements and limitations on the designer. Delivering the fluidity of interaction and range of expression possible with pen and paper remains a substantial challenge.
The characteristics of the medium and the features of the representation artifact are intimately connected. As a consequence, another understanding of the term representation (or sometimes, model) has emerged. It is used in the collective sense to refer to categories of similar objects—plan drawings, pasteboard models, 2D CAD data, BIM data, water colors, etc. This is especially relevant to discussion of software, where the cost of development invariably requires that it support creation of multiple models in multiple projects. This goal creates a preference for data features or operational affordances that supply the most widely sought-after, generic qualities of the medium, and may lead to provision of affordances that generalize or constrict representations for the sake of efficient production.
Closure and Complexity
It may seem that the best strategy for making an all-purpose design tool is to include as many high-level primitives as possible. The ones the user needs will be available, and the ones they don’t need will simply not participate. There are two problems with this: closure under editing operations and interaction between primitives.
For example, several years ago there was a 2D drafting program that included lines, circles, arcs, and ellipses among its primitives. It also had commands to subdivide, or break, lines. A broken line turns into two shorter lines. A broken circle turns into an arc. Unfortunately, it wasn’t possible to break ellipses, as there was no elliptical arc primitive. The set of primitives was not closed when using the break operation.
While closure is not necessary for the software to run, it is highly desirable. As the number of possible operations and the number of primitives each increase, assuring closure under all operations is a problem of geometric proportions. That is, it grows as the product of the number of distinct primitives and global operations.
Similarly, the complexity of some routine operations, such as line-of-intersection computations in a 3D modeling application, depends on the number of possible primitive types involved. If all models consist of polygons, we need only consider the intersection of two polygons, but if we have both polygons and cylinders, we must have code for plane–plane, plane–cylinder, and cylinder–cylinder intersections.
What this means is that completely aside from issues of interface complexity and user training, software developers are strongly motivated to use simple generic primitives in their representations rather than complex domain-specific ones. One of the attractive features of NURB modeling, in addition to precise surface representation, is that NURBs can be used to represent both planar forms and curved ones, so a NURB–NURB intersection computation, while complex, can be used in almost all calculations.
Drawings
It is worth remembering that the early efforts to apply computing to design occurred prior to the development of high-performance graphics displays, and actually tended to focus more on issues of optimized circulation and rational spatial layout than on appearance or documentation (Lawson 1997). The focus on drawings and computer aided drafting (the modern sense of the term CAD) came about with the explosion of personal computers in the 1980s and 1990s.
While they dominate the discussion, drawings play such different cognitive roles at different stages in the development of a design that it might be better to develop a more refined taxonomy. A bubble diagram is not the same as a plan sketch, which is not the same as a detail; there is a context switch that identifies which information in each drawing is important, and in what ways. Still drawing can support the design process in almost every stage.
Pencil and paper drawings do have a number of limitations. Changes in scale require re-drawing. The drawing can run off the edge of the paper if overall size, scale, and orientation are not considered from the very beginning. Even simple edits usually require erasing at least part of the drawing and redoing it. The big problem—the drawing coordination problem—is that nothing inherent to the medium guarantees that the building shown in one view is the same size as the building shown in another, or has all the same features (doors, windows, corners). Nor is it certain that window openings are in the same place in plans and elevations, etc. This problem is only resolved through significant expenditure of cognitive effort. Finally, even when drawings are complete and well-coordinated, most analyses require substantial human interpretation of the drawing before they can be completed (Augenbroe 2003).
Technologically, tracing paper, xerography, Mylar drafting film, light-tables and pin drafting all served to reduce the problems associated with assembling coordinated drawing sets. In this light, the adoption of 2D CAD and BIM are part of a natural progression, as both attack a number of consistency and efficiency problems head-on.
As discussed in Chapter 5, digitally a “drawing” usually means a graphic defined as a list of individual elements (lines, circles, arcs, and text), each defined by certain coordinates and parameters, while a “painting” means a grid of pixels, each assigned a color. In three dimensions, polyhedral or parametric-patch boundary representation or solid models capture geometry, with surface qualities or attributes assigned as parameters, images, or parametric textures. Object-based geometry takes up less space than raster data, and can be selected, scaled, copied, rotated, and manipulated parametrically. This foundation was natural for 2D and 3D CAD, at least in part because the actual decision of what to draw was left up to the human user.
Symbolic Content in Drawings
Architectural drawings contain representation of both the building geometry and a variety of cultural symbols, a fact which complicates the processes of learning to read drawings as well as the automatic production of drawings which is necessary to bridge between a 3D design model and 2D construction documents. For example, walls in plan are shown as if cut approximately at waist height, but this may vary in order to expose significant features such as partial height partitions, clerestories, mezzanines, etc. Even when the positions of the lines forming the boundaries of the wall can be determined geometrically, the poché between the lines is a symbolic and conventionalized representation of the wall assembly. Figure 8.2 shows the traditional poché for a wood-stud wall.
Elsewhere on the plans, one may find “dollar signs”—symbols representing electrical switches in location but not size or geometry. They are shown outside but geometrically adjacent to the wall in which the implied electrical box housing the switch should be placed. The same switch, shown in an interior elevation, may well have the geometry of a cover-plate. Note how the location of the symbol is geometrically relevant to the design, but the graphic of the symbol varies by drawing type (plan, elevation, etc.). In other cases, it is even more complex: doors are quasi-geometric symbols. They show where the door fits in the wall, how big it is, the volume intersected by its swing, and where the hinge goes—all geometric qualities. However, by convention doors are shown open in plan but closed in elevation, with a visible (but non-physical) arc in plan to indicate the swing, and (usually) a text label linking the symbol to additional information about fire rating, finish materials, hardware, etc.
Dimensions and pochés tell us things about the design, but not the geometry. Line weight identifies cut geometry and relative distance to the next surface; line style may indicate edges above or below; and color/shade may well indicate elements to be removed as well as added. All-in-all, construction documents follow a complex language of denotation. The notion that they are simply slices through a 3D geometry is clearly incorrect. BIM software, which does produce 2D drawings from models, generally employs a “box model” that permits or requires alternative 2D representations to be created for those tricky objects and assemblies that don’t follow geometric drawing rules. Users are insulated from this complexity by a robust supply of pre-made generic building parts.
Figure 8.2 Symbolism and geometry in architectural drawing.
Buildings
The BIM packages of today are primarily design documentation systems, which means their primary product is construction documents. They represent buildings as needed to service that end. They include many pre-made building elements (wall assemblies, windows, doors, furniture, etc.) that have been created to work with each other and with the underlying drawing-extraction system. The predefined parts mean users don’t have to address geometry vs. symbol problems just to get their first project done, but the complexity of these parts also means the users may not be readily able to delay decisions (e.g., walls must have a specified thickness), or add their own building components, making design exploration and experimentation more difficult.
Regardless of how drawing conventions expect doors to look, the contractor has to order and install real doors with real hardware and trim. Details and door schedules are intended to bring the relevant information together in a compact form, but they also duplicate information shown elsewhere in the drawing set, creating opportunity for errors. On a big project, just updating the door schedule can be a full-time job. In typical 2D CAD software, standardized symbols can help because they can be tracked and counted, but they can also be exploded—turned back into simple primitives during editing—which destroys their semantic value. Representing a door as an irreducible first-class object, with appropriate parameters for hardware, glazing, fire-rating, etc. creates data that can be reliably searched for, collected, and manipulated by software. It reduces errors and saves money. Combined with other data, it might enable code-compliance checking. On the other hand, there are many ways that doors may be constructed—pocket doors, sliding barn doors, double-doors, Dutch-doors, saloon doors—so making a universal “door” object in a BIM program isn’t trivial, even if you know how to draw each of those.
Alternative Representations
The dominant characteristic of most vector representations is that of a list. Discrete data objects representing constructible parts of the building appear in no particular order within the list. Editing consists of adding, altering, or deleting elements, sometimes (via object snaps) after extracting coordinate data from existing objects for use in new ones. However, there are other ways of representing a design.
Topology: Beyond an Aggregation of Shapes
In some building types (especially hospitals, courthouses, and factories) there is a lot of attention to the proximity of activities, and the flow of people and resources. Issues of connection trump issues of location. Even in more mundane buildings, such as homes, adjacency diagrams showing relationships between spaces—bubble diagrams—play an important role in focusing client–architect communications on issues of acoustic and visual privacy, access, and spatial hierarchy. In these drawings, as in Figure 5.4, spaces are often represented as simple circles or rounded rectangles. Openings, hallways, and doorways are lines linking spaces. These are graphs. Landownership, floor plans, street networks, and many other basically 2D phenomena have been explored as graphs. Such representations make it possible to distinguish inside from outside and guarantee enclosure for energy calculations or 3D printing, and enable testing for code-compliant exit pathways in a high-rise, detecting unassigned square-footage in a rental plan, etc. They are not, however, widely used because they are hard to reliably extract from a large list of elements that may not join up exactly at their corners, etc.
The tendency to focus on a list of things that must be installed or constructed ignores the most important part of architecture—the spaces created between the walls. If the model is maintained as a list of objects, created in the order entered by the user and not organized according to the building geometry, it means the programs may not be able to answer questions involving spatial connectivity, circulation and emergency egress, or HVAC. Such information can be incorporated in a space network, adjacency graph, or “soap-bubble” diagram. Focused on spaces and their shared boundaries, such descriptions may also require different (i.e., non-manifold) topology for their full expression.
These models take advantage of connectivity. As illustrated in Figure 5.4b, if we establish the coordinate at each corner or intersection of a 2D plan, the walls connect pairs of points. If a shared point is moved, the connecting walls in all related rooms are adjusted. Doors are simply penetrable parts of the walls. We have added topology information to the model in the form of a connectivity graph. As shown in Figure 8.3, the graph can be used to establish room adjacency and possible circulation paths.
Figure 8.3 Planar graphs represent spatial relationships of (a) circulation, and (b) adjacency or boundary locations in a simple plan.
A graph is a concept from discrete mathematics. It is a set of nodes (the dots are points in space) connected by links (the walls). If you did a diagram of a website, the pages would be the nodes and the anchors linking between pages would be the links. A floor plan may also be thought of as a graph, as may a family tree. Graphs exhibit various interesting properties that are important to some aspects of design computing, such as circulation.
While the visual character of the building depends on representing the material that is there, circulation within the building depends on what is not there. The exact geometry of the walls (glazed or not, interior or exterior) isn’t important. Within a space it is assumed that we can move about freely. Connections between spaces depend on where the doors, stairs, and elevators are. Doors connect two (and only two) spaces. This means that circulation can also be represented as a graph, with nodes representing spaces, and links (or edges) representing connections between spaces. If you overlay a circulation graph with its associated plan graph, they are clearly related. In fact, they are said to be duals of each other.
Graphs are useful for capturing something that is divided in irregular ways, such as the way land is divided by property-lines, and for representing circulation within cities or corporate campuses, where the nodes might be buildings or intersections and the connecting links are streets or sidewalks.
In a well-formed and complete model, this information can be computed from the boundary-element information for simple cases such as enclosed rooms connected by doorways, but it is much more difficult to extract in the case of environments with incomplete modeling or errors, or where there are implied spatial subdivisions such as pilasters, ceiling beams, flooring changes, or built-in furnishings. Extraction and interpretation of such information from the geometry of an environment is one goal of space syntax research, using techniques such as isovists (Benedikt 1979) and connectivity graphs.
In the 1970s there was a great deal of interest in the potential of linear graphs for space planning (Grason 1971), an interest that seems to crop up once a decade or so (Arvin and House 1999). Today, we see this technology in our route-finding satellite navigation systems.
Shape Grammars: History, Shape Equality, and Emergence
The multiplicity of equivalent representations possible in a line-oriented drawing editor makes it very difficult to establish equality between two drawings, or to identify changes. It also means that semantically different representations may appear to be quite similar. A modest reinterpretation of the lines may suggest a very different design. In the process of drawing, aspects of the project that might not have been associated with each other become visible, or a drawing may reveal a relationship between parts of the project that had been considered separately. This discovery of unrecognized information or possibility in the project is known as emergence. We have seen this as a component of design cognition in the previous chapter, but it also presents a representational challenge, because the emergent reading of the drawing may suggest a design move that the original data does not readily support. The history implicit in the data may need to be rewritten.
In the previous chapter Figure 7.2 showed a plan sketched initially as two overlapping squares, which subsequently suggested a courtyard and two L-shaped buildings, and the possibility of opening up the courtyard to the larger site. Most designers and most software would capture the initial sketch as two rectangles. In today’s CAD software their overlap is not explicitly represented, nor are the points where they intersect. Reinterpreting the sketch as two facing L-shapes with a void between them requires the rectangles to be broken down into lines, their intersections found, and new polygon outlines created and substituted for the original squares. Since this is only one of several ways to reconstitute the outlines, there is no obvious automatic “rewrite” rule. It will probably be necessary for the designer to make a choice, although the emergent interpretation might be implied by the edit the user is attempting to make. These are open research questions.
The study of such transformations forms the heart of shape grammars (Stiny 1980), introduced in Chapter 7, an approach that evolved out of computational linguistics. While the most obvious characteristic of most grammar systems is sets of production rules from which increasingly complex configurations can be built, the underlying representational goal is one in which the sequence of construction doesn’t matter, so history is removed, shape equivalence is computable, and emergence is directly supported.
In this context, one of the appealing qualities of a raster representation is its lack of history. In a paint program the squares of our example are just collections of pixels. While we may view them as squares, there is no drawing data that encodes their history. If the user can carefully select the pixels that constitute one of the two L-shapes, the job is done. The designer is free to reinterpret the sketch in any fashion at any time. Unfortunately, since this depends on the user, it also imposes skill and attention requirements on the user (to make the selection) and the use of raster data dramatically reduces the possibility of machine interpretation of the drawing. At this time, a representation capable of supporting the strengths of both vector and raster media remains elusive.
Decisions: Capturing Design Rationale
Representations focused on the constructed elements of a building do not capture design rationale. Designers and clients develop reasoning for decisions, but once a decision has been reached and recorded in the documents, there is no ready means of recording the reasons behind it—the office debate about where to put the CEO’s office, or why certain areas have half-height partitions. These decisions are often made in response to specific client input or site conditions. In the face of complex and changing requirements, revisiting the reasons for a design being the way it is ends up relying on the notoriously fallible memories of the people involved, assuming they are still available to consult. This observation has motivated the development of issue based information systems (IBIS) (McCall et al. 1989) and case-based reasoning systems (Kolodner 1992), both of which feature representations that focus less on the physical aspects of a design and more on the problem structure and rationale that brought them to their current state.
Computational Design: Designing in Code
While geometry data can reflect thought, computer code can directly capture and express thought. Geometry editors such as 2D and 3D CAD/BIM systems take very neutral stances towards the geometry they edit; they are meant to be tools for the designer, not collaborators. Some formalisms, such as shape grammars, do capture elements of design thinking because they attempt to capture the rules (processes) that move a design from one state to the next. The appearance of scripting languages as a part of CAD software packages, beginning with AutoLISP in the 1980s but continuing to Generative Components, RhinoScript, Grasshopper, MAXScript, and Dynamo, taps into the persistent desire to explicitly create, edit, test, and execute design thoughts.
Modern scripting owes a debt to software systems that have been modularized and refactored to split user-interfaces from the geometry and rendering engines that operate in the background. In the process of making their systems easier to update and extend, developers have also made them easier for the user to manipulate, creating the world of scripting. Online open-source communities have disseminated excitement and knowledge about the resulting information ecologies, leading to a resurgence of interest in delineating design through code.
Parametric Design
One result of the interest in scripting in design is the rich and complex interaction of nested ideas and geometry that we call parametric design. These are objects, some of which might be quite complex, that change to fit the situation in which they are used. For example, the geometry of a real stairway is controlled by building code rules governing stair tread and riser dimensions as well as the overall floor-to-floor distance. Where earlier designers would have drawn a few standard-sized treads and computed the required number of risers from the floor-to-floor dimension and then drawn or noted the appropriate number of treads, today’s designer can insert a parametric stair object that extracts the floor-to-floor distance from the system settings and draws itself fully formed, complete with code-compliant handrails. Further, if the floor-to-floor is large enough, it will insert a landing at the midpoint of the stair as well.
Mass Customization: Process as the Product of Design
The meaning, or semantic payload, of a representation is never entirely explicit. Much is implied, left to cultural norms of the construction trades (dimension round-offs, finish standards, etc.), or used and abandoned in the process of data entry (grid and ortho snaps, keyboard ortho constraints, relative coordinate keyboard entry, etc.). Further, and quite ironically, as digital fabrication becomes more common, the physical object is no longer the product of design, a data file is. In the even more abstract case of “mass customization” a family of objects, represented by end-user-specified parameters and designer-specified process, produces objects, some of which may not have been foreseen. The design itself becomes implicit.
Challenges to the Single-Model Concept
We know that the finished physical building will be singular, not plural, and believe that there is a single design toward which it is being guided. We know that efficiency can be found in computation processes that share data. These facts support the belief that a single representation is both possible and desirable. What challenges it? Certainly, industry inertia makes it hard to change, but are there, perhaps, more fundamental problems with the fundamental goal?
Incompatibility: Representation and Abstraction
Even within those representations focused on geometry, there is more than one way to represent a design project, meaning both that there is more than one form of external representation that might be used and that an individual designer’s construction of an external representation will be personal and unique. Each representation is a means to an end, whether that end is design development, construction documents, rendering, energy analysis, cost estimating, construction planning, egress analysis, structural analysis, or all of these. As each of these ends has developed over time, they have developed their own representations for a building. Until quite recently, no one has sought to represent just a building, as such. That is what drawings were for, but drawings require interpretation, a step we are now seeking to eliminate. Arising in independent disciplinary silos, different analyses focus on different details of the building, ranging from surface color, to physical properties such as heat conductivity and strength, to properties of history such as embodied energy and carbon footprint, material sourcing, or operating expense. The analysis cannot be conducted if the information isn’t available, but the information may not be explicitly stored in the data model. It may, in fact, be implied by the locale, the building type, building code requirements, or even basic industry practice.
Not only do the different analyses focus on different building details, different disciplines often use different approximations to produce analyses at each stage in the design process. And, while the geometrical representation of room surfaces required for construction begins fairly simply and gradually grows to be quite complex, some other representations remain fairly simple, even for completed buildings; for example, much HVAC design largely ignores internal partitions and treats the building as two zones—one near the windows and one interior. This geometry may not be explicitly defined by building elements, nor computable from those elements that are explicitly defined; requiring that it be supplied during analysis in order to complete the analysis. Such manual delineation means there will be multiple overlapping geometries in a building, that may have to be manually updated as well, adding opportunity for error. Nor are such updates trivial to make; when you move a wall it might matter to the economic model because it changes rentable area, but not to the HVAC system because it is interior to an HVAC zone.
Conversion Between Representations
While a single “cradle to grave” data model might be desirable, it is not yet available. Numerous circumstances arise in which designers need to convert data from one format to another. They may wish to use data supplied by the client, a consultant, or a vendor. They may wish to perform a numerical analysis or simulation of the project that their software does not directly support. Finally, they may find one tool conducive to schematic design, but wish to use another for design development. In each case, they will need to convert data from one representation to another. These conversions raise a number of issues.
Translation and Augmentation
The process of converting a design into an analysis model is likely to precipitate decisions. To create a cost estimate from a geometrical design representation we need to perform “material takeoffs” that turn CAD or BIM data into areas and volumes for estimating. It may also be necessary to explicitly define outlines for areas of flooring. To build a thermal-performance estimate, areas will again be needed, but carpeted floor may be treated differently from raw concrete (necessitating special/modified areas), most interior partitioning will be ignored, while exterior wall, floor, ceiling, and window assemblies must be specified thermally. Exterior walls will be aggregated based on assembly, orientation, and solar exposure, and both floor and ceiling conditions must be explicitly identified (occupied vs. unoccupied space? Above grade or below? etc.). While this information might be estimated or deduced from model geometry, other information, about occupancy schedule and occupant load (numbers of users and their activity level) and estimates of plug-loads from equipment, will almost certainly need to be added.
The point of these two examples is to illustrate how differently the building may be seen by different performance analyses. In each case the design must be interpreted in terms of the needs of the analysis, and in each case additional data must be supplied to the analysis. While these interpretations may be saved and reused in subsequent analyses, the limited integration of building data with analysis data is cumbersome.
Many Data Formats
Analyses and simulations may examine issues ranging from construction cost to structural soundness, to carbon-footprint, to energy use, to projected revenue generation. In each case computational models have been developed that incorporate the appropriate knowledge and process information. Each begins with the “building” geometry, but brings a specialized view of the design that often requires a different interpretation of that geometry and needs certain specialized information not found in the CAD or BIM model. The analysis thus requires both translation of the underlying design geometry and augmentation of that model with additional information. Each model begins with spatial information about the project (areas, lengths, volumes, locations, geometry, etc.) aggregating, simplifying and augmenting it to supply the necessary information. While supplying that data from the design representation would be sensible, and some vendors provide products that do this if you remain within their product family, it remains a very challenging goal in the general case.
One indication of the extent of fragmentation is the number of distinct file formats. One list of CAD and modeling file types includes over 1100 different file extensions for CAD data (file-extensions.org 2016). As mentioned in Chapter 5, efforts to establish a data exchange standard for the architecture, engineering, and construction (AEC) industry were not initially successful. While many programs are able to read and save the de facto standard DWG or DXF file formats, and are increasingly able to use Industry Foundation Class (IFC) or gbXML, the fact that these are not their native storage format means conversion is needed. While simulation platforms may import geometry from a CAD model, many utilize their own file formats for saving models and results. Thus, when a designer wishes to conduct one of these analyses, they must generally prepare input data for the analysis program, using their building design data for reference.
Phases and Focus
Individual design representations focus attention on those aspects of a problem which are open to manipulation during the design process, or which influence simulations or analyses that can be carried out based on the representation. In that sense, representations are incomplete. Further, as the designer’s attention shifts, representations will shift as well, from simple to detailed, from occupant circulation to energy use, etc. In the past it was common to create new representations at key transitions or for specific purposes in the course of a design, as when sketch design drawings were “hard lined” on the drafting table, given typical dimensions, made orthogonal, etc. Or when material quantity takeoffs were done for cost estimating. Such transformations take time and energy. One of the persistent attractions of digital technology is the idea of representations that span a project from “cradle to grave,” a feat that has yet to be fully realized. Among the heavy BIM users present at a 2008 GSA workshop in Seattle, most saw three broad categories of BIM model: design, construction, and operation—largely distinguished by the way in which contained information is used. Others speak of “federations” of BIM models (Scheer 2014).
Whether this is a single universal building model or a federation of BIM models, there will be a variety of conversion problems, either because the design must be re-created in a new representation or converted from one to another. This issue will re-emerge in regard to the role of expertise in the design process (Chapter 11), but consider this example from geometry: There are many times when a 3D modeling application needs to represent a surface with a hole in it, as when putting a window in a wall. As a wireframe elevation drawing in a CAD system, this can be done with two rectangles, one inside the other. If the outer rectangle has a poché or hatch pattern, the inner rectangle is usually expressed as a continuation of the perimeter of the outer rectangle, traversing one in a clockwise direction and the other in a counter-clockwise direction and drawing invisible lines on the edges that connect the two. This works okay in some surface-modeling programs too, in which a “hole” is just an area where no data is, but many hidden-line algorithms need convex polygons, or, worse, triangles. Converting our “wall with an opening” from one format to another may turn it into a wild collection of triangles. It’ll render well, but if you edit it in this form and need to convert it back, it may be very difficult.
Design Iteration, Progression, and the Single Model (Round-Tripping and Incomplete)
As designs iterate to increasing levels of detail, their representations move from bubble-diagrams to rough wall layouts to detailed plans and sections. These changes illustrate that conversions happen over time within disciplines as well as across disciplines.
Each candidate design solution will consist of an arrangement of parts. Early in the process these might be rooms or zones. Later on they will be walls, doors, and windows. There are different possible representations of each solution. Each has its own appropriate level of detail for analysis or simulation.
Not all design media are used in a fully intentional way. With pen and paper, the designer’s initial sketch may consist of unstructured, even random, marks on the page (Purcell and Gero 1998). These marks are thought to facilitate retrieval of content from the designer’s long-term memory, content which begins to layer semantic structure onto the sketch, guiding its further development. Ambiguity and imprecise drawing thus engage long-term memory, possibly leading to emergence and a reassignment of meaning. This pattern of divergent thinking will be followed at some point by the designer shifting to a more analytical convergent mode of thought in which drawing tools and scaled lines play a more prominent role. At any time, the designer may revert to divergent ideational drawing, with the result that a given piece of paper may contain drawings of any type, all drawn with the same tools.
The digital tool-kit is currently less flexible, but arguably more powerful, divided roughly into the categories of sketching, drafting, and modeling, spanning from raster to 2D drawing to 3D modeling. Only modest long-term overlap occurs, though BIM and some 3D modeling systems do include fairly extensive drafting sub-systems, and “redlining” or similar markup tools may be applied to virtually any document that can be converted to PDF. The reduced flexibility comes from the necessity of picking a tool (program) at the beginning of a representation task and the limited range of expression that the tool facilitates. Greater power is associated with tools with a wider range of editing options (scaling, copy/paste, etc.), but few users sketch in a CAD program or draft in a paint program—transitions seem inevitable.
It may well be the case that the cognitive shift that occurs and the tool shift that is currently required as a design progresses happen at about the same stage in the development of the project, minimizing any negative impact attending to re-building the representation, possibly even facilitating development by encouraging a shift. Unfortunately, the iterative nature of design and the common occurrence of backtracking in some, if not all, areas of a project can make these transitions painful and frustrating. A system that blends the various representations, allowing quick overlay sketches in the midst of a BIM modeling session, has yet to emerge.
Conservation of Information
The concept of higher- and lower-level representations has been discussed previously. It is easy to convert a water color to pixels, but hard to convert one to drawing primitives. It is easy to turn a solid model into a boundary-representation model, and to turn that b-rep model into wireframe data, but it is much harder to construct a b-rep model from multi-view sketches, much less construct a compatible solid model.
The Round-Tripping Problem
This is particularly problematic when you consider that designers often “backtrack” to earlier design states as they work, with the result that re-creation or re-conversion may need to happen repeatedly. Further, the designer may wish to combine elements of a later state with those of an earlier one, which means that conversions may need to be bi-directional.
Traditional “dumb” representations such as paper drawings benefit from human interpretation that is intelligent, flexible, and adaptive. This enables a wide range of “downstream” uses of design data, but the interpretation step makes such use expensive. Digital representations, using computable semantically laden primitives in sophisticated relational data structures, promise to automate or eliminate interpretation and make downstream use inexpensive, potentially allowing design software to provide real-time estimates of cost, building use, carbon footprint, and energy use, all updated by background computations run against the single building representation in the BIM data set.
Unfortunately, we can eliminate interpretation only if the primary representation contains all information required by a secondary representation, but this is unlikely if not impossible. Automating interpretation will require various levels of information insertion, ranging from default values to full-on artificial intelligence. Automating interpretation may also require geometrical interpretation, projecting volumes from footprints of adjacent buildings, filling in detail in ambiguous areas, simplifying complex forms, or completing incomplete ones.
Summary
We create representations to exercise power over complex situations we need to change. Exactly how we conceive of them, as physical objects, relationships, or processes, and the assumptions we use to cage and control them matters a great deal. As participants in a collaborative social process, sharing our representations is increasingly necessary, requiring conversion and interpretation, simplification, and extrapolation along the way. The digital representations we create to work with them balance human hand–eye skills and associative memory against machine recordkeeping and process automation in processes where meaning changes as new interpretations emerge, as projects mature, or in response to a need to view the project in a new way. The ideal representation would support sketching, drawing, and constructing in a workflow where reinterpretation and emergence are supported, nagging is minimized, and designers are able to flip between thinking of spaces and surfaces, between organizing principles, regulating lines, and replacement rules or constraints, and where history can be ignored to follow an emergent idea, or consulted to recover design rationale. It is a task as complex as our personal and cultural relationship to the built environment as a whole.
No single representation exists at this time that can deliver all this, but Bryan Lawson closed out the third edition of How Designers Think with this relevant observation, which suggests how we might get there: “I have found that one of the most penetrative inquiries you make into how designers think is to demand that they use a computer tool and then allow them to complain about it” (Lawson 1997).
Suggested Reading
Lawson, Bryan. 1997. How designers think: The design process demystified (3rd edition). Oxford: Architectural Press.
Mueller, Pam A. and Daniel M. Oppenheimer. 2014. The pen is mightier than the keyboard: Advantages of longhand over laptop note taking. Psychological Science 25: 1159–1168.
Scheer, David Ross. 2014. The death of drawing: Architecture in the age of simulation. New York, NY: Routledge.
Stiny, G. 1980. Introduction to shape and shape grammars. Environment and Planning B: Planning and Design 7: 343–351.
References
Arvin, Scott and D. H. House. 1999. Modeling architectural design objectives in physically based space planning, in Media and design process: Proceedings of ACADIA ’99. Edited by O. Ataman and J. Bermudez, 212–225. ACADIA.
Augenbroe, Godfried. 2003. Developments in interoperability, in Advanced building simulation. Edited by A. Malkawi and G. Augenbroe, 189–216. New York, NY: Spon.
Benedikt, M. L. 1979. To take hold of space: Isovists and isovist fields. Environment and Planning B 6: 47–65.
Clayton, Mark. 2014. Modeling architectural meaning, in Building information modeling: BIM in current and future practice. Edited by K. Kensek and D. Noble, 29–41. Hoboken, NJ: Wiley.
Eastman, C. 1970. On the analysis of the intuitive design process, in Emerging methods in environmental design and planning. Edited by G. Moore, 21–37. Cambridge: MIT Press.
File-extensions.org. 2016. 3D graphics, CAD-CAM-CAE file extensions list. www.file-extensions.orgfiletype/extension/name/3d-graphics-cad-cam-files
Grason, John. 1971. An approach to computerized space planning using graph theory. Proceedings of the 8th annual design automation workshop.
Kolodner, Janet. 1992. An introduction to case-based reasoning. Artificial Intelligence Review 6: 3–34.
Lawson, Bryan. 1997. How designers think: The design process demystified (3rd edition). Oxford: Architectural Press.
Lawson, Bryan. 1999. “Fake” and “real” creativity using computer aided design: Some lessons from Herman Hertzberger, in Proceedings of Creativity and Cognition ’99. ACM.
McCall, Raymond, Gerhard Fischer, and Anders Morch. 1989. Supporting reflection-in-action in the Janus design environment, in Proceedings of CAAD Futures 1989, 247–259. Cambridge, MA: MIT Press.
Mueller, Pam A. and Daniel M. Oppenheimer. 2014. The pen is mightier than the keyboard: Advantages of longhand over laptop note taking. Psychological Science 25: 1159–1168.
Purcell, A. T. and John Gero. 1998. Drawings and the design process. Design Studies 19: 389–430.
Scheer, David Ross. 2014. The death of drawing: Architecture in the age of simulation. New York, NY: Routledge.
Stiny, G. 1980. Introduction to shape and shape grammars. Environment and Planning B: Planning and Design 7: 343–351.