In order to promote wider dissemination of architectural research, I have created this HTML version, though I still recommend reading the actual published paper as well as other papers in the proceedings. For one thing, it's easier to cite dead wood than html (html doesn't really have page numbers and such). Rights for this paper are retained by the author (me), so if you want to copy the paper for some reason other than your own personal use, email me and ask for permission.

Making Models Architectural:

Protean Representations to Fit Architects' Minds

Typical CAD representations, however, are based on geometric/mathematical elements like points, lines, planes, and symbols. Even more experimental approaches like parametric shapes or procedural assemblies correspond poorly to architectural elements, and seldom lend themselves well to making conceptual changes that would allow exploration of design alternatives. Small wonder some architecture schools experience a division between computer courses and studio courses, or even between computer faculty and studio faculty. Different ways of talking and thinking are involved. The concepts involved are often mutually exclusive.

This paper discusses an attempt to address this conceptual mismatch, using what are termed “protean” (meaning “very changeable”) elements. These are high-level elements corresponding to architectural concepts like “wall,” or “dome.” They each have parameters appropriate for the particular type of element they represent, and produce the polyhedra necessary for graphics based on these parameters. A system (called Proteus) is currently being implemented which allows models to be constructed using these elements. The protean elements form a loosely structured model, in which some elements hierarchically contain others, and some elements are essentially freestanding, being created and manipulated independently of other elements. Characteristics of the element are discussed, including the underlying object-oriented structure, the relationship between elements and graphics, and functions associated with the objects. A scheme is explained whereby all parts of a design can be represented, making the model complete, even when the design includes extremely unusual forms not conforming to predictable classes of elements. The necessary support framework is also discussed; general flow of the system and mechanisms for viewing the model and editing subcomponents are explained.

The current status of the project, and intentions for future work are discussed. The project has been partially implemented, and the necessary framework to support the system is mostly complete. Future work is expected to focus on implementation of classes of elements. Long range plans are to add code to perform an analysis on the model, and/or to integrate elements at the level of manufactured components.

The Language of Studio

However, a person walking through a computer lab is likely to hear completely different jargon, even if the users are making architectural drawings or modeling buildings. A person modeling on a computer, trying to accomplish the same effect as the one in studio, might need to create a volume to subtract from a cuboid, or translate another group of objects by (0”, 0”, 24”). He has to think about concepts like set operations, symbol instances, selection sets, and snapping modes.

These aren't cosmetic differences. They represent fundamental differences in the way the world is seen, described, and conceptually manipulated. In order to express ideas from one domain in the terms of the other, a person must translate ideas from the person's mental representation into a representation that differs significantly, inhibiting the cognitive capabilities of the person doing the work (Norman 1991).

This sort of extra mental processing is to be avoided in interface design. It stands in the way of making the interface transparent. It forces an additional degree of removal between the architect and the task of designing architecture. It interferes with design, rather than facilitating it. In order to truly utilize computers in the studio and in the design process, interference has to be avoided. The CAD program must become more user friendly, which in this case means becoming more architect-friendly. It must communicate with the architect on the architects terms and in the architect's terms.

Augmenting Mental Abilities

When people work in a domain, they develop short-cuts to help them operate in that domain. They augment their memories or simplify their tasks by using tools or external media, writing things down or drawing images they are trying to visualize (Norman 1991, 19-22). As they become experts in the domain, they start to associate (chunk) pieces of information together, so that the information can be remembered and thought about more efficiently (Hayes 1991 121-126; Best 1989, 133). They develop a jargon to describe the things they encounter in their domain (Lakoff 1987, 308), which we can presume corresponds roughly with these chunks. Experts in a domain also start to automatize a variety of mental tasks, from recognition to high-level problem solving strategies (Norman 1991 23-24; Anderson 1982; LaBerge and Samuels 1974).

Need to Use Architectural Elements

Need for Flexibility

In addition to using the concepts they are used to working with, architects also need to be able to work with the processes they are used to working with. Letting architects work with their automatized mental processes would be reason enough for this, but there is more. Architects develop their libraries of chunks and processes because they are so well suited for designing architecture. Even if architects were completely re-trained and given decades of experience using new “computer-friendly” thought processes for designing architecture, it is likely that these new processes would still not be as well suited for visualization, creative ideation, evaluating symbolic meaning, and other tasks associated with architectural design. CAD systems need to accommodate mental processes used in design, not the other way around.

In order to fit the way architects think while designing, a CAD system needs to allow a top-down method of working. It is well-established that design proceeds in a primarily top-down manner, with broad decisions (like where to put a certain room) being made before decisions about details. A CAD system needs to support such decision-making by allowing broad decisions to be modeled before all the component details have been refined.

A CAD system also needs to be flexible. As a design evolves, things change. Rooms may move, appear out of nowhere, or disappear altogether. One structural system may be replaced with another. The second floor may be completely unsupported for a time before the first floor is resolved. Volumes might collide with each other before being squeezed into their proper places. A CAD system needs to be flexible enough to allow drastic changes. It needs to allow topology-altering changes, as well as changes which produce temporary states of structural or geometric impossibility.

Current Representational Approaches

Parametric shapes have been utilized in more experimental systems to provide a top-down working environment, and even improved correspondence to architectural concepts (Mitchell and others 1988; Mitchell and others 1992). Topological shapes can be selected which correspond to architectural elements. By describing a model as instances of particular shapes with different segments or faces stretched by different amounts, architectural forms can be modeled. By allowing a shape to be substituted or augmented with more specific shapes, an impressive degree of top-down model-building can be allowed. However, these effects generally come at the expense of flexibility. Only those topologies anticipated by the programmer can be modeled. Furthermore, the ability to create “freestanding” elements (not derived from elements already in the model) can be limited; a system based too heavily on substitution can constrain the options available to the designer.

Other representational systems also have drawbacks. Feature-based systems allow a certain degree of top-down decision making, allowing a user to select forms added earlier, and add or remove “features” like additional forms to be unioned with or subtracted from the form. But feature-based systems typically are oriented around Constructive Solid Geometries rather than more architectural elements. Procedural shape systems create shapes or forms based on architectural parameters (like number of risers in a stairway), but don't save this information -- low-level geometrical/mathematical elements are created based on the information. Procedural assemblies don't even let the user work graphically -- the user has to try to script a series of solid modeling commands that will produce the desired shape. None of these approaches allows the sort of editing needed.

General Characteristics

Anticipated Use in the Design Process

Figure 1. Creating or editing an existing element.

It is intended that as the design is refined, additional changes may be made. An object of one type may be replaced with an object of another type. A wall might be replaced with a colonnade, or a dome might be replaced with a more specific subtype, a ribbed dome. Any attributes the objects have in common are copied over, and the old object is replaced with the new one.

Description of Elements

A full implementation of a system based on protean elements would include perhaps a couple hundred elements, arranged in a hierarchy similar to that shown in figure 3.

Unusual Elements and Completeness

Several classes of elements are needed in order to round out the elements available and make the system complete. These additional elements must be as general-purpose as possible in order to accommodate any conceivable type of form. A combination of geometric primitives, process-oriented descriptions (e.g., solids of revolution), and if all else fails, Constructive Solid Geometries (CSG's) supply the necessary completeness.

Few systems have incorporated both architectural elements and a mechanism for complete, general-purpose modeling. Yet one does not preclude the other. Both architectural and general-purpose elements have characteristics that describe their particular geometry, and it is sensible to make both editable in the same manner. Both can be made to produce polyhedral representations of themselves, for use by the same drawing routines.

The use of general-purpose vs. architectural classes may have some relevance for certain analytical calculations. For example, structural calculations might be affected by whether a certain element is technically a column or a cylinder. This possible relevance has not yet been explored.

Elements Not Included

The omission of such elements is deliberate. While the significance of such elements in the thoughts and reasoning of architects can not be denied, this alone does not indicate that such an element should be included as such in a CAD system. The analogy may be made that while elements like “foreshadowing,” “comic relief,” and “irony” are elements of literature, it is not useful to organize a text editor around such elements. They lack consistent, predictable form; its not even easy to say with great certainty exactly where such elements begin and end. One would not, for instance, press a key to add an instance of comic relief to a story in the same way that press a key to add a letter or paste a word or phrase.

In the same way, there are numerous concepts which can be considered “elements” of architecture, but which lack distinct bounds or predictable characteristics. Different instances share some characteristics, but not enough to fall into what psychologists would call a “basic level category” (Rosch 1978). They do not share a large number of common visual features, or characteristics of use. Often they are composite elements, composed of numerous smaller elements put together. These elements are deliberately omitted from the test implementation.

Support Framework

Current Status of Test Implementation

General support code has been completed. This includes the code necessary for file access, opening and closing windows and dialog boxes, setting viewing parameters, entering points graphically by clicking, and other general-purpose code. This portion of the project is necessary, but not particularly interesting from the point of view of researchers.

In its current state, Proteus also includes the framework necessary to work with protean elements, drawing them on the screen, identifying them from right-clicks, opening a dialog box, and updating information. This code is necessary in order for protean elements to function. Code for these tasks works with modular code for each particular type of element. For instance, general purpose code for Proteus determines that a right-click was made, searches a display list for a line drawn on the screen which passes near the clicked point, and determines which element that line is associated with. Proteus then opens a dialog box, and tells the selected element to fill the dialog box with the appropriate fields and their values for the particular element selected. This code is modular in nature, and details are different for each class of element. Proteus just needs to invoke the function, and each element takes care of particulars for its own case. In a similar way, Proteus draws the polyhedra provided by the elements, displays a menu appropriate for the current element, and opens windows for editing sub-components of complex elements.

Most element-specific code has not yet been implemented. At this point, only CSG's and a rudimentary version of walls have been implemented; implementing these was necessary to make sure that the general code and the framework for protean elements were working correctly. This supporting framework seems to work properly, so there does not seem to be any reason why work can not proceed.

Kits of Parts

One approach that is sometimes taken for representation of architectural designs is a “kit-of-parts” approach. A kit-of-parts approach involves a large set of pre-defined architectural “elements” or “parts,” which are combined in order to define a model. Usually symbols or similar grouping methods are used to define the parts, although parts could conceivably be more like procedural or parametric shapes in nature.

In some respects, protean elements are similar to elements used in a kit-of-parts approach, particularly a more sophisticated, parametric representation. However, there is a fundamental difference in the way models are created in a protean approach. A kit-of-parts is inherently bottom-up in nature. Models are made by combining parts into a larger aggregate.

A protean approach, however, is not necessarily bottom up, though protean elements can be used in that manner if desired. With protean elements, a column could be defined and then used in a colonnade (in a bottom-up manner), but the colonnade could also be created first, leaving the definition of the columns for later. A window could be added before the mullions and moldings are decided on. Protean elements allow design to proceed in a top-down manner, with details being resolved after broader design decisions.

“High level” Approach to Element Definition

This is in contrast to a “low level” approach, where an attempt would be made to represent high-level architectural attributes by combining low-level graphical entities. A “low level” approach might at first look promising when attempting to add architectural elements on top of an existing drawing or modeling system. However, prior experience has indicated that the “low-level” strategy has inherent problems. It is difficult to represent attributes like “column spacing” directly with lines, polygons, polyhedra, and so forth. Even traditional ways of grouping graphics, like groups or symbols, do not work well for this purpose.

One way to get past this difficulty might be to create additional data structures to hold “architectural” information, and list the component drawing entities. This approach is effectively very similar to the one taken; high level attributes are stored for possible editing later.

Another possible “low level” approach would be to have a model consisting entirely of graphical elements, and to recognize architectural elements from the graphics, similar to the way architects can “read” a model. This approach might potentially be very powerful. It might, for instance, allow a set of independently-placed columns to be recognized as a colonnade, without having been expressly created as such. However, this approach assumes recognition capabilities that have not yet been realized. It also assumes that there is a set of architectural elements that the graphics can be recognized as. In effect, the strategy requires the ability to recognize elements very similar to protean elements out of graphical ones. The major difference is that such elements would be temporary, being synthesized on demand to allow changes, and being deleted once the changes were implemented in the graphical elements (possibly to be temporarily re-created for further changes). This approach is therefore considered to be difficult to implement, but not entirely incompatible with protean elements.

“No rules” Approach to Element Creation

The Topdown system demonstrated that a system using shape grammars can provide admirable ability to build models in a top-down manner, with the model becoming gradually more detailed as the design is refined. However, the use of shape grammars in a modeling system limits the design evolution to those ideas anticipated by the programmer. At any given point in the evolution of the design, a particular change can only be made if there is a rule for transforming some part of the model in the desired manner. Each possible change requires a corresponding rule, and since the number of rules in a system is necessarily finite, the flexibility of a rule-based system is necessarily limited.

A rule-based system could get around this limitation by having rules along the lines of, “In any situation, a wall can be added.” Since this effectively eliminates the conditions of the rule, however, this really would represent a degenerate case of a rule system. There would be little reason to implement such a rule system, as opposed to a system that let the user add elements without filtering them through ineffectual rules.

This system is intended to allow gradual definition and refinement of a design, without reliance on generative rules. The choice of what changes to make is left entirely to the architect.

“Correctness” of Models

Many modeling representations (e.g. EDM (Eastman 1992), ARCH:PLAN (Turner and Hall 1985) or P3 (Khemlani and others 1997) rely on a restriction that models be “correct” or well-formed.” This means that the model must conform to certain strict standards regarding topology. For example, some systems require that every room be surrounded by a wall at every point of its perimeter, and every wall must have a “left room” and a “right room.” Such requirements prevent “nonsensical” configurations of elements like overlapping solids, and facilitate analytical calculations by prohibiting problems like floors receiving more than one set of loads.

Correctness typically carries a heavy price in terms of how easily the model can be manipulated. Often, special, unintuitive steps have to be taken in order to get a design idea to conform to the correct representational topology. For instance, in some systems, all rooms must have walls along their entire perimeters. If, for instance, the breakfast nook and the kitchen are not separated by an actual wall, the designer must create an “invisible” or “zero-thickness” wall in the modeling system in order to separate them.

If our goal is to have modeling system elements correspond to architectural ones, and we have to invent “invisible walls” to make the modeling system work, we are falling short of our goal.

Protean elements do not assume or require that a model be “well-formed” or “correct.” It does not require a strict relationship between rooms and walls, it does not require elements to be supported structurally, and it does not even prohibit solid objects which intersect. This is intentional.

Ideas for well-formed designs to not spring spontaneously into a designer's head. Design is an ongoing process, and initial ideas are often conflicting or mutually incompatible. This does not mean that these ideas should not be sketched or modeled. On the contrary, it is by modeling these ideas that they are mentally evaluated by the designer, their faults are seen, and various attempts at rectifying them can be proposed. Eventually the various problems and geometrically impossible arrangements are ironed out.

Protean elements are intended to model evolving designs. These means representing things which are ill-formed. Its true that ill-formed models do not facilitate structural, thermal, lighting, or probably any other sort of numerical analysis. I would argue, however, that there is little need to perform such analyses on models which are ill-formed. The model can be corrected and the analyses performed later, once the design has reached a state where such an analysis would be meaningful.

Plans for Future Work

Given the limited resources available (a single programmer), not all of these elements will probably be implemented. Probably the most basic architectural elements will be supported (walls, rooms, beams, and so on), and some class of element will probably be chosen for further exploration. Specific subtypes of this element will be implemented to explore the number of subtypes needed and whether implementing subtypes becomes easier or harder than the basic-level classes.

Eventual plans are to investigate other aspects of protean elements. Can a protean model be elaborated to adequately represent buildings at the level of studs, sill plates, and vapor barriers? How easily could analyses like structural or lighting calculations be incorporated into protean elements? The answers to these questions are unclear at the moment.

Initial results are promising. Protean elements allow characteristics of architecturally-oriented elements to be changed, without sacrificing model completeness. Highly anomalous forms can still be created. Protean elements can generate a polyhedral representation to allow the necessary graphics, without sacrificing performance like being able to select element by clicking. Although the naturalness with which Proteus fits the design process can not be evaluated at the current stage of the implementation, the approach conforms to current information on cognition and mental representation. The protean elements approach appears potentially very useful, and should be explored further.

Anderson, John R. 1985. The development of expertise. Chapter 9 of Cognitive Psychology and its implications. 2nd ed. New York: W. H. Freeman & Company.

Anderson, John R. 1982. Acquisition of cognitive skill. Psychological Review, 89, no. 4: 369-406.

Best, John B. 1989. Cognitive Psychology. 2nd ed. Saint Paul, Minnesota: West Publishing Company.

Day, Ruth S. 1988. Alternative representations. The Psychology of Learning and Motivation, 22, 261-305.

Eastman, Charles M. 1992. Use of data modeling in the conceptual structuring of design problems. In CAAD futures '91: Computer aided architectural design futures: Education, research, applications, ed. Gerhard N. Schmitt, 225-243. Braunschweig/ Wiesbaden: Friedr. Vieweg & Sohn Verlagsgesellshaft mbH.

Hayes, John R. 1989. The Complete Problem Solver. 2nd ed. Hillsdale, New Jersey: Lawrence Erlbaum Associates.

Johnson, Scott E. 1997. What's in a representation, why do we care, and what does it mean? Examining evidence from psychology. ACADIA 97: Representation and Design, eds. J. Peter Jordan, Bettina Mehnert, and Anton Harfmann, 5-15. Cincinnati, Ohio: The Association for Computer-Aided Design in Architecture.

Khemlani, Lachmi, Anne Timerman, Beatrice Benne, and Yehuda E. Kalay. 1997. Semantically rich building representation. ACADIA 97: Representation and Design, eds. J. Peter Jordan, Bettina Mehnert, and Anton Harfmann, 207-227. Cincinnati, Ohio: The Association for Computer-Aided Design in Architecture.

LaBerge, David, and S. Jay Samuels. 1974. Toward a theory of automatic information processing in reading. Cognitive Psychology 6, no. 2: 293-323.

Lakoff, George. 1987. Women, Fire, and Dangerous Things: What Categories Reveal about the Mind. Chicago: University of Chicago Press.

Mitchell, William J., Robin S. Liggett, Spiro N. Pollalis, and Milton Tan. 1992. Integrating shape grammars and design analysis. In CAAD Futures '91: Computer-Aided Architectural Design Futures: Education, Research, Applications, ed. Gerhard N. Schmitt, 17-32. Braunschweig/ Wiesbaden: Friedr. Vieweg & Sohn Verlagsgesellshaft mbH.

Mitchell, William J., Robin S. Liggett, and Milton Tan. 1988. The Topdown system and its use in teaching: An exploration of structured, knowledge-based design. In Computing in Design Education: ACADIA '88 Workshop Proceedings, ed. Pamela J. Bancroft, 251-262. Ann Arbor, Michigan: Association for Computer-Aided Design in Architecture.

Norman, Donald A. 1991. Cognitive Artifacts. Chap. in Designing Interaction: Psychology at the Human-Computer Interface, ed. J. M. Carroll. New York: Cambridge University Press.

Norman, Donald A. 1988. The Psychology of Everyday Things. New York: Doubleday.

Rosch, Eleanor. 1978. Principles of Categorization. Chap. in Cognition and Categorization, ed. Eleanor Rosch and Barbara B. Lloyd. Hillsdale, New Jersey: Lawrence Erlbaum Associates.

Rowe, Peter G. 1987. Design Thinking. Cambridge, Massachusetts: The M.I.T Press.

Schön, Donald A. 1988. Designing: Rules, types, and worlds. Design Studies 9, no. 3: 181-190.

Schön, Donald A. 1983. The Reflective Practitioner.: How Professionals Think in Action. New York, New York: Basic Books, Inc., Publishers.

Turner, James A. and Theodore W. Hall. 1985. The automated generation of room polygons from a weighted and directed planar graph of wall lines. Seminar presentation paper from the 5th Annual Pacific Northwest Computer Graphics Week, Eugene, Oregon. Photcopy obtained from Architecture and Planning Research Laboratory, College of Architecture and Urban Planning, University of Michigan.

This concludes the paper as published in the ACADIA Conference Procedings.

More information:

• Other publications by Scott Johnson
  
• Short curriculum vitae for Scott Johnson
  
• Home page for Scott Johnson
• Statement expressing my area of research interest