Figure 1--A screen shot from the test implementation.
I don't like the idea of using computers in design. I can't design using a mouse. I can't coordinate what I am doing by my hand with what I see on the screen. I find it very difficult to draw lines the same way we draw freehand sketches. Now, I have to use this system. Sometimes I think on a piece of paper and then put the drawing on the computer. I tried once to develop a new strategy of using this system in design. The result was rectilinear design. It was a very rigid design. I felt like [I was] designing with both my hands tied....I think it is my mind that is tied, rather than my hands. I can't function properly while using this system. (Sakr 1991, 119-120)
Many complaints like the one above are legitimate, not the product of technophobic paranoia. Cognitive psychologists note a number of interesting points:
The quote above is now over 10 years old, but most CAAD systems still rely largely on the same representations that were used in 1991, which, in turn, were not so different from what was used in Sutherland's Sketchpad system in 1963 (Sutherland 1963). More advanced representations are now beginning to be put to use, but the transition is still incomplete, and many of the same problems persist.
Comparing these architectural elements to the sorts of things used in CAAD systems, we find a rather poor correlation. For instance, an architect might want to add a semi-circular window above an existing rectangular one. This might require eliminating a number of planes representing the wall and replacing them with new ones which leave open a semi-circular section. Or it may require creating half a cylinder, laying it down on its side, subtracting it from a wall model, and then adding whatever forms are necessary to represent the window itself. Or it might even require expressing the necessary transformations and set operations in terms of scripting language instructions for the computer to execute to generate the desired form. In any event, it requires a translation: a mapping of what is desired into the available elements and operators. Cognitive psychologists have found that such translations inhibit performance on concurrent tasks -- in this case, designing. At best, having to perform such translations means putting thoughts about lighting, R-values, architectural precedent, visual balance, degrees of privacy, and so forth on the back burner, in order to think about the proper means of constructing the desired window out of the available elements. At worst, it means deciding the effect isn't worth the effort, and changing the design to something easier to express in the software's terms.
More recently, commercial software like AutoCAD Architectural DeskTop, Microstation Triforma, and Revit has started using more architecturally-oriented elements. These are higher-level entities with their own stored parameters, not just complex collections of graphic primitives. Such elements are also found in home design software, like Broderbund's 3D Home Architect. In my opinion, these software packages represent an improvement over traditional graphically-oriented software, but they still do not take the idea as far as it should go.
As far as I am aware, this software does not take the idea of architecturally-oriented elements to the level of editable product-level components. It rarely attempts to associate data for analyses (structural, thermal, etc. analyses) with the elements. The designer's ability to create unusual high-level elements (e.g., highly sculptural stairs) is usually limited or non-existent--there is no "graceful degradation" from high-level architectural elements, through a hierarchy of increasingly general elements, to assemblages of graphic entities. Instead, there is usually a sharp distinction between architectural elements and graphical ones, with no attempt to bridge the gap or "cast" assemblages of graphic entities as anything more architectural.
Various research projects have also suggested or begun development of representations intended to be more architecturally oriented. Among these are ARCH:MODEL and GEDIT (Turner and Hall 1985), P3 (Khemlani, Timerman, Benne, and Kalay 1997), EDM (Eastman 1992; Eastman and Siabiris 1995), the M.E.R.O.DE. system described by Hendricx (1997), and systems proposed (but not implemented) by Mahalingam (1999) and Harfmann and his colleagues (Harfmann and Majkowski 1992; Harfmann and Chen 1993; Harfmann, Majkowski, and Chen, 1993). However, these representations also have shortcomings. Those that have been implmented typically rely heavily on "model correctness," that is, they utilize intricate networks of relationships between model elements that limit or prevent the representation's use in the design process. In fact, Khemlani (discussion on October 3, 1997) admits P3 is not really intended for the earliest stages of design, and Eastman (discussion on January 20, 2000) states that EDM is intended more as a format for a central database or an interlingua than as a representation for a design tool. The unimplemented systems sound promising, but do not fully explain many implementation issues, like how reliant they are on model correctness or how they model joints and relations between elements. Of all the representations described in the surveyed literature, only Harfmann's seriously addresses the duality between conceptual elements (e.g., "wall") and the product-level elements (e.g., "stud") that comprise them. Thus, the architectural representations described in the research literature, like those in commercial software, have significant shortcomings.
A goal in user interface design is to create a "transparent" interface--to let the user interact with his work, not with the program. In general, the better the mappings (between goals and available operators, between actual and perceived system states, etc.) the better the interface (see Norman 1988, 199). In my dissertation, I propose supplementing more primitive modelling elements with what I call "protean" (meaning "readily changing") elements, in order to improve the mapping between what the user wants to do and how he must do it, and to make interfaces for CAAD systems more transparent.
Protean elements are high-level, architecturally-oriented elements corresponding to things like walls, windows, columns, moldings, and so forth. They have characteristics that are appropriate for such elements, like width, starting and ending points, rough opening sizes, or a circuit describing cross-section. These characteristics are explicitly stored, so that they can be modified later, and they have default values for situations where the architect is considering an element but is not ready to specify every detail of it.
In order to test the idea of using protean elements, a test implementation, called Proteus, was constructed (figure 1). Object-oriented programming fit the concept of protean elements extremely well, so Visual C++ was used for the implementation. Among the issues explored in this test implementation are the basic operational organization, handling of joints between elements, de-emphasis of model correctness, and the ability to integrate tools for analysis with the visualization tool.
Figure 1--A screen shot from the test implementation.
Protean elements themselves are implemented as classes in a C++ application. Each class (one for walls, one for floors, one for columns, one for rooms, etc.) has parameters sufficient to describe an instance of that particular class. These variables are able to affect topology, representing an improvement over simple parametric shapes. Each element class also has member functions describing behavior for the class: how to put up a dialog box for specifying parameters, how to generate the graphical representation of the element based on its parameters, how to store itself in a file, and how to perform any functions unique to that particular class (like the way that a room might seek out walls to align itself to, if the user initiates such a command).
Since protean elements are not simple graphic entities, they can not be directly drawn by a computer. Therefore, each protean element produces a polyhedral representation of itself, which is then drawn using libraries of graphics code originally developed in the 70's and 80's for GEDIT software at the University of Michigan. A display list is kept, linking each protean element to what appears on the screen, so that elements can be selected from screen clicks.
There are many possible ways that joints might be handled by CAAD software. They might be handled as elements, or as attributes of other elements. They might be handled as binary joints, involving exactly two elements coming together, or multi-element joints, involving any number of elements coming together. They might modify the elements incoming to the joint, or not. They might have constraints associated with them, or not. Some of the software created for research purposes addresses the issue of how to treat joints, but there is no clear consensus on it. Proteus explores one possible scheme for handling joints, attempting to do so with a minimum of user intervention and model correctness being involved.
One reason these restrictions are put in place is to facilitate analyses. Structural analyses are easier if each piece of floor has only one room bearing on it. Thermal analyses work better if a room actually has an envelope around it, without gaps in the envelope, or other rooms (and their associated heat loads) intersecting the room in question.
However, enforcing model correctness has unpleasant side effects. For example, when a strict room/wall relationship is enforced, moving a room can be difficult, because rooms are tied to walls, which are in turn tied to other rooms. Another side effect is that every closet must be defined as a room. Another is that in plans where two rooms are not separated by a wall, the user must define an "invisible" or "zero-thickness" wall between them, for the sake of completing the room definitions. Such side effects contradict the intended spirit of protean elements, which is to match an architect's mental representations as closely as possible, to give the user control, and to avoid pestering the user for information.
Proteus explores the idea that such strictness might not be necessary. As an example of how to avoid such strictness, software can be written so as to consider all overlapping rooms bearing on a given piece of floor, and choose the one with the largest floor load. (Alternately, the software could be written so as to handle the situation by considering more than one load case.) As another example, architects are probably unlikely to perform a thermal analysis on a room that is not completely enclosed, but if they decide to do it, they should not be surprised if the analysis indicates a significant heat loss. Analysis software (or functions which output data for use in analysis software) could probably be written so as to warn the user when such situations were found, and then either do the analysis anyway, or ignore "bad" data.
...given an actor with the motor programs for sitting, it is a fact of the perceived world that objects with the perceptual attributes of chairs are more likely to have functional sit-on-able-ness than objects with the appearance of cats (Rosch 1978, 313).This suggests that there should be some correlation between architectural elements in a visualization tool and functional characteristics. It should be possible to associate data for analyses (of structure, lighting, acoustics, thermal performance, cost, etc.) with protean elements. In the test implementation, this possibility is explored by attempting to extract structural data (for a finite element analysis) from a model made of protean elements.
In the course of this dissertation, I first developed a familiarity with research literature concerning cognitive resources, development of expertise, and mental representation, particularly as it relates to architectural design. Based on this research literature, I developed a set of guidelines for CAAD representations for architectural design. This was presented at ACADIA '97 (in Cincinnati), in a paper titled, "What's in a Representation, Why do We Care, and What Does It Mean? Examining Evidence from Psychology."
I then began developing a test implementation based on these guidelines. Preliminary results from this test implementation were discussed in a paper delivered at ACADIA '98 (in Quebec) in a paper titled, "Making Models Architectural: Protean Representations to Fit Architects' Minds." This paper described the basic organization of Proteus, including the types of information and functions associated with protean elements, and the scheme for achieving a complete library of elements by including a spectrum of elements from "standard" element types, through process-oriented elements like solids of revolution, to the ultimate safety-net class, the CSG. As reported in the paper, no significant barriers were encountered that would indicate that the basic approach was unsound.
Further development of Proteus more deeply examines joints, minimal model correctness (particularly where rooms and walls are concerned), and extraction/abstraction of data for analyses.
Since the number of joints in a model is almost certainly several times larger than the number of non-joint elements, no sane user would want to have to specify data for very many of them. Therefore, joints are generated automatically whenever two elements come together, and destroyed if that situation ever changes. The user only needs to deal with joints if for some reason, he or she has an interest in the joint. This can happen if the user needs to specify information about the type of connection used at a structural joint, prior to performing a structural analysis.
The approach seems to work reasonably well in Proteus. The automated maintenance of joints seems to work as intended. Furthermore, joints are involved in a number of important operations, including aligning rooms to walls when initiated by a user, and extraction of structural data.
Furthermore, decisions about how elements are used in design are generally left to the user. For example, nothing dictates that a "wall" must be only one story tall, or that it necessarily stops at an intersection with another wall. If the user wants to think of the entire front facade of a building as being a single "wall," regardless of the fact that there may be five stories of offices immediately behind the wall, with 10 offices per floor, this is accommodated. Letting the architect think of the design in the terms he or she wishes is considered to be of paramount importance.
As part of the de-emphasis of model correctness, there is no strict room/wall relationship in Proteus. A room does not have to be bounded by walls, nor a wall by rooms. Rooms can overlap; walls can overlap; rooms can overlap walls; space on the floor plan is not necessarily allocated to a room.
However, since rooms might play a role in certain analyses (by virtue of the lighting requirements, heat loads, or floor loads associated with a room), the user may want to have a room align itself with walls. Aligning a room to existing walls is not trivial. This is particularly true in Proteus, since walls do not necessarily form closed circuits: the perimeter of a room may follow walls for the most part, but also jump short gaps between walls and/or columns. However, when the user initiates such an operation, Proteus is able to identify room boundaries through a combination of ray-casting (to find nearby walls and columns that might help define a perimeter) and chaining together of wall segments into chains and circuits of walls. It is not a perfect algorithm (note that even an architect may be confused about room boundaries in certain ambiguous situations), but it makes a very good guess as to the intended room boundaries, and the user can correct the rare errors that do occur.
The dissertation also describes an algorithm for applying room loads to floors, based on geometries. In essence, rooms are projected downwards up to eight feet until a supporting floor surface is found. The largest room load bearing on any particular area of floor is used for structural calculations.
These investigations lead me to believe that software can function in an acceptable and even preferable manner without rigid maintenance of model correctness. Of course, allowing the user this sort of flexibility has costs in terms of the programming that must be done in order to compensate. This is discussed in a later section of this web page.
A detailed protean element for a beam would have information about a "start point" and "end point," as well as information about its cross-section, moment of inertia, material, and so forth. In addition, a model comprised of protean elements also has information about joints between elements, including (for structural joints) the type of connection involved (fixed, pinned, or roller). Since this is precisely the sort of information needed for a structural analysis, it would appear that a relatively straightforward extraction of structural data should be possible.
However, it turns out that the problem is not that simple. This is because the data for a structural analysis involves an abstraction of the design. For example, in reality, the centerlines of joists and beams supporting a floor are generally not coplanar (figure 2). Yet, they are treated as such in a structural analysis. This can involve treating a structural member as if it is located a foot or more from its actual location. What is more, one structural member can not be abstracted without taking into consideration the rest of the structural system. Other situations can occur where abstraction involves moving an element, or even creating new, essentially fictitious elements to connect structural members that touch, but whose centerlines are skew (figure 3).
Figure 2-- Centerlines of joists and beams in a floor system are usually not truly coplanar (left), but they are usually abstracted to treat them as if they are. This can involve the abstraction of an element being located a foot or more from the actual element (right), and this abstraction can not be made based solely on the element itself-- other elements in the model must be considered.
Figure 3-- Sometimes, elements in a structure are connected, but skew. In some of these situations, neither element can be repositioned to meet the other, without damaging the accuracy of the analysis. An abstraction of the situation may need to add a semi-fictitious element to connect them.
It is likely that other analyses (thermal, acoustic, etc.) likewise require abstractions. What is more, they likely require different abstractions, complicating the matter. For instance, a wall height used in a structural analysis would likely be different from a wall height for an acoustic analysis, where the effective wall surface would end at a suspended ceiling.
These abstraction processes are fairly easy for a human to perform with relatively little practice, but they are difficult to codify algorithmically. Fortunately, abstraction does not occur in a haphazard manner, it seems to follow certain principles. For instance, in structures, joists, beams, and girders belonging to the same floor system (or roof system) are "adjusted" to be coplanar, but members of different floor systems or members of a truss are not. Because of this, an algorithmic abstraction is possible, though not trivial. In Proteus, code was written to abstract protean elements into finite elements for a structural analysis, but it was not a simple process of exporting stored data, as was first thought.
First, the upper limit of what can be done with graphical and solid elements has probably already been reached. New graphical and solid entities can be added, interface details can be improved, more scripts and macros can be added, and so forth, but these are not fundamental improvements, and the point of diminishing returns has probably been reached. Any significant improvements, i.e., improvements that architects are likely to want to spend money on, will likely require a change of the underlying representations used. In fact, this switch is already starting to appear, with programs like AutoCAD Architectural DeskTop, MicroStation Triforma, and Revit.
Second, it appears that after implementation of a few (20-30) basic level element classes, implementation of protean elements gets easier. The class with the largest number of member functions is CElement, the parent class for all other element classes. Classes for walls, rooms, columns, beams, floors, joints between elements, etc. also require quite a lot of programming, in order to ensure proper output for analyses, proper creation and maintenance of product-level components, and other desirable behavior. However, subclasses require fewer distinct member functions. For instance, a Corinthian column, a round column, and a square column can all use essentially the same code for abstracting their structural data (i.e., functions associated with their parent class).
Being from the field of architecture, I tend to emphasize ease of use for the user over ease for the programmer, hoping to create a better CAAD tool. However, at this point, some might consider the net benefits of de-emphasizing model correctness to be too minimal to justify the effort. While I tend to disagree, I must acknowledge that some points can be made in support of model correctness.
For example, imagine that an architect has modelled a long room, which is crossed at regular intervals by beams running across its width (figure 4). Then imagine that midway down the long sides of the room, under one of these beams, the architect decides to add a couple of walls, one projecting from each long sidewall like a fin. The result looks very much like a wall dividing the long room in half, pierced by a very large "doorway." But modelled out of protean elements, it will not act like a wall with a doorway, it will act like two walls and a beam. A user would have trouble making the "doorway" arched, or centering it in the "wall." One way around this might be to have some sort of command which could take coplanar walls and beams and redefine them as a single a wall element, but this would probably be an annoying operation from the user's perspective. It also might be difficult to implement all such functions, as it is unclear how many such redefinition functions would be needed.
Figure 4--Example of an emergent shape in architecture. A room is crossed by beams top left). Short lengths of wall are added along one of these beams (top right). The result looks very similar to a single wall with a large opening in it (bottom), however, the result will not behave like a single wall with an opening.
However, this problem of not being able to easily recognize emergent shapes
is common to essentially all CAAD software. Getting around the problem might
require software capable of recognizing high-level architectural elements out
of low-level graphic elements. This is an entirely separate--and exceedingly
difficult--research problem, which I am not currently prepared to investigate.
Until it is solved, I think CAAD users will be forced to deal with software
that does not handle emergent shapes elegantly.
Protean elements are to facilitate this through the use of subclasses. For instance, once the user decides that a window should be a casement window, Proteus is supposed to create an instance of the casement window class to replace the earlier instance of a generic window class. The casement window is to have all the data fields of the parent, generic window class, with this data being copied over from the generic window. In addition, the casement window is to have new fields not found in the generic parent class, such as a parameter describing direction of swing. These parameters are to be specified (or assumed, based on defaults) when the window is specified to be a casement window.
The scheme for this was planned out, but implementing it was beyond the scope of this dissertation. Thus, I was unable to see how hard it would be to implement subclasses, and much new code would be required. It is likely, however, that each subclass would involve significantly less programming than each parent class.
A complete set of Protean elements would theoretically include product-level elements. When incorporated into a building model, these product-level elements would co-exist in space with any conceptual-level elements of which they were parts. Studs, for instance, would co-exist in space with the walls of which they were parts. When drawing the model, this duality would need to be addressed, so that a conceptual-level element and its product-level components would not both be drawn. A conceptual-level element would ordinarily provide a graphical description of itself, but if it had product-level components, it would need to provide their graphical descriptions, so that they would be drawn, instead. Extracting data for analyses would have to be handled in a similar manner.
However, none of this is implemented in Proteus at this point. Development of protean elements along these lines remains theoretical. One unexamined issue which might present some difficulty is the matter of how to modify a conceptual-level element when constituent parts are edited, and vice-versa.
However, building this test implementation has been a lot of work, and I think I might want to take a break from it after finishing my dissertation and publishing related papers. It might be a good time to begin examining representations for genetic algorithms.
Alexander, Christopher, Sara Ishakawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Schlomo Angel. 1977. A pattern language: Towns, buildings, construction. New York: Oxford University Press.
Anderson, John R. 1985. The development of expertise. Chapter 9 of Cognitive psychology and its implications. 2nd ed. New York: W. H. Freeman & Co.
Chase, William G., and Herbert A. Simon. 1973. Perceptions in chess. Cognitive Psychology, 4, no. 1: 55-81.
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.
Eastman, Charles, and Anastassios Siabiris. 1995. A generic building product model incorporating building type information. Automation in Construction 3: 283-304.
Harfmann, Anton C., and Stuart S. Chen. 1993. Component-based building representation for design and construction. Automation in Construction 1: 339-350.
Harfmann, Anton C., and Bruce Majkowski. 1992. Component-based spatial reasoning. In Computer supported design in architecture:Mission, method, madness, ed. Karen Kensek and Douglas Noble, 103-111. Charleston, South Carolina: The Association for Computer-Aided Design in Architecture.
Harfmann, Anton C., Bruce Majkowski, and Stuart S. Chen. 1993. A component-based approch to building product representation and design development. In CAAD futures '93, ed. Ulrich Fleming and Skip Van Wyk, 437-452. Amsterdam, The Netherlands: Elsevier Science Publishers, B.V.
Hendricx, Ann. 1997. Shape, space, and building element: Development of a conceptual object model for the design process. In CumInCAD (Cumulative Index on CAD) online article database, http://info.tuwien.ac.at/ecaade/proc/hendricx/hendricx.htm. Last downloaded Sept.10, 2000. Reprint of paper in 15th (1997) eCAADe Conference Proceedings (Exact title of proceedings and original publication information not given).
Johnson, Scott E. 1997. What's in a representation, why do wecare, and what does it mean? Examining evidence from psychology. In ACADIA 97: Representation and design, ed. J. Peter Jordan, Bettina Mehnert, and Anton Harfmann, 5-15. Cincinnati, Ohio: The Association for Computer-Aided Design in Architecture.
Johnson, Scott E. 1998. Making models architectural: Protean representations to fit architects' minds. In Digital design studios: Do computers make a difference? ACADIA '98. ed. Thomas Seebohm and Skip Van Wyk, 354-365. Québec City, Canada: 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.
Kieras, David E., and Susan Bovair. 1984. The role of a mental model in learning to operate a device. Cognitive Science 8: 255-273.
Lakoff, George. 1987. Women, fire, and dangerous things: What categories reveal about the mind. Chicago: University of Chicago Press.
Mahalingam, Ganapathy. 1999. A parallel processing model for the analysis and design of rectangular frame structures. In Media and design process, ed. Osman Ataman and Julio Bermudez, 346-347. Salt Lake City, Utah: Association for Computer-Aided Design in Architecture.
Norman, Donald A. 1988. The design of everyday things. New York: Doubleday.
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.
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.
Sakr, Yasser H. 1991. Design in the age of information: The impact of computers on the practice of architectural design. D. Arch. diss., University of Michigan.
Schon, Donald A. 1988. Designing: Rules, types, and worlds. Design Studies 9, no. 3: 181-190.
Simon, Herbert A., and Michael Barenfeld. 1969. Information-processing analysis of perceptual processes in problem solving. Psychological Review, 76, no. 5: 473-483.
Sutherland, Ivan E. 1963. Sketchpad: A man-machine graphical communication system. In Proceedings: AFIPS conference proceedings, volume 23: 1963 spring joint computer conference, 329-346. Baltimore, Maryland: Spartan Books, Inc.
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. Photocopy obtained from Architecture and Planning Research Laboratory, College of Architecture and Urban Planning, University of Michigan.
Verstijnen, I.M., J.M. Hennessy, C. van Leeuween, R. Hamel, and Gabriella Goldschmidt. 1998. Sketching and creative discovery. Design Studies 19: 519-546.
Weisberg, Robert W. 1986. Creativity: Genius and other myths. New York: W. H. Freeman and Co.
More info: