Figure 1. Trying to change a 24" wide door symbol (left) to represent a 36" door, by changing one (middle) or two (right) scale factors. Note how the thickness of the door and size of the jambs is affected by scale factors.
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. 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.
Scott Johnson
This paper examines psychological evidence on the nature and role of representations in cognition. Both internal (mental) and external (physical or digital) representations are considered. It is discovered that both types of representation are deeply linked to thought processes. They are linked to learning, the ability to use existing knowledge, and problem solving strategies. The links between representations, thought processes, and behavior are so deep that even eye movements are partly governed by representations. Choice of representations can affect limited cognitive resources like attention and short-term memory by forcing a person to try to utilize poorly organized information or perform "translations" from one representation to another. The implications of this evidence are discussed. Based on these findings, a set of guidelines is presented, for digital representations which minimize drain of cognitive resources. These guidelines describe what sorts of characteristics and behaviors a representation should exhibit, and what sorts of information it should contain in order to accommodate and facilitate design. Current attempts to implement such representations are discussed.
All computer software intended for drafting, modeling, or design -- indeed, all software intended for any purpose whatsoever -- has some sort of inherent way of representing whatever it is that the program is meant to manipulate. In the case of computer-aided design software, representations are often based on graphic/ mathematical entities meant to facilitate coordinate transformations and other graphics routines, but we often find complaints that such software is unfriendly or difficult to use.
Potentially, such software can be made easier to use if we base the software on representations that facilitate human cognition and design. In order to do this, we must have some understanding of how the human mind works and how it uses representations. What are representations, and how are they used? What are the effects of using alternate representations? What are the implications for architectural design systems? In other words, what's in a representation, why do we care, and what does it mean?
Cognitive psychologists describe the mind as being comprised of certain resources and mechanisms. These components behave in certain well-documented ways, with certain inherent limitations. Components include short-term (working) memory, long-term memory, and attention, as well as various buffers to handle sensory input, and other mechanisms.
Short-term (STM), or working memory holds information which is currently in use. We use it when we repeat a phone number to ourselves in preparation of dialing, when we keep track of operands and partial results as we perform arithmetic operations, when we listen to a lecture, when we compose a sentence, or when we imagine a scene. Information in short term memory decays in a matter of seconds unless it is constantly rehearsed, in which case it can last minutes. There is a verbal component of short-term memory, which is limited to about seven words, or two seconds of speech. There also seem to be a visual-spatial component which is used to form mental pictures, and an organizational component, which helps us keep our places when performing complex tasks. The various components are largely independent, although when one component approaches capacity, other components are somewhat inhibited (Schacter 1989, 687-689).
When short-term memory capacity is exceeded, or when information decays, we find ourselves forgetting information we are using. We forget the phone number before we can dial it, forget how a sentence started, or lose track of what we were doing.
Long term memory (LTM) is what most people refer to when they talk about memory. It holds information for an hour or a lifetime. It holds facts, experiences, or well-rehearsed processes. It seems to have no "maximum capacity." With disuse, information fades from long-term memory, but information which is occasionally used can persist indefinitely (Hayes 1989, 112, 128).
Attention is another resource which is quite limited in nature. It is not considered to be a storage medium, but rather, a mechanism by which processing is consciously directed. In general, a person can attend to only one thing at a time, although attention can be switched from one task to another very quickly. Furthermore, certain actions can be performed more or less automatically, with little or no attention (Laberge and Samuels 1974, 294-295).
Because cognitive resources -- especially short-term memory and attention -- are limited, humans have ways of economizing use of resources when frequently-used information and processes are involved. Small pieces of information can be "chunked" together into larger units, and frequently-used processes can become automatized.
When certain pieces of information often appear together, the mind often defines this group in long-term memory as a single "chunk." This allows short-term memory to refer to the pieces of information as if they were a single entity, reducing the load on STM. Frequently-cited examples of chunks are certain groups of letters and digits, such as "IBM," "USA," or, "1492" (Hayes 1989, 125; Anderson 1990,133). Other examples may include groups of pen strokes that form certain characters, groups of letters that form frequently-encountered words (Laberge and Samuels 1974, 300-301), or in some people, groupings of chess pieces that form frequently-encountered functional units (Chase and Simon 1983). Akin (1986) has identified certain visual chunks based on patterns of recall exhibited by architects. The significance of these mental representations will be discussed shortly.
Certain frequently repeated sequences of actions become "automated" or "automatized." For the remainder of this paper, the term "automatized" will be used, in order to avoid confusion with other possible meanings of the word "automated."
When first learning a new physical or mental procedure, the mind often traverses a sort of declarative list of steps. This requires a great deal of attention. However, as the procedure becomes more practiced, it can become automatized to reduce the amount of attention necessary for performance. The procedure may demand attention only occasionally, allowing attention to be focused on concurrent tasks. In the extreme case, the procedure becomes a sort of monolithic entity, which requires only a small amount of attention to set in motion, and once set in motion, generally executes in its entirety. Automatized procedures vary greatly in scope, from recognition of characters, or sequences of motor actions, to complex procedures like driving to work, navigating through a video game, or giving a sequence of commands. Without automatization, even understanding written text would be horrendously difficult, as we would have to consciously study each letter to identify it, and consciously put letters together into words, before being able to consider the meaning of the text.
Automatization has been compared to running a compiled procedure, as opposed one that is being interpreted (Anderson 1983). Not only does automatization allow attention to be focused on other tasks, it also frees short term memory, which no longer has to be used to remember as many partial results, to remember steps of interpreted procedures, or to keep track of one's position within such series of steps. Procedures which are automatized require fewer of our cognitive resources, so for instance, we find it easier to understand the ideas of a technical paper if it is written in our native language as opposed to one with which we know but haven't practiced extensively.
A representation can be defined as "something that stands for something else.... some sort of model of the thing (or things) it represents" (Palmer 1978, 262). Architects use physical and digital representations of proposed designs for the real world. Representations also exist internal to a person's mind. In order to properly understand the role of representations in design and other mental activities, we need to consider both internal (mental) and external (physical or digital) representations, how they are used, and how they relate to each other.
It is important to note that not all representations are created equal. A poor representation, either internal or external, can actually inhibit mental performance. Inefficient internal representations can waste short-term memory. Inefficient external representations can waste attention and short-term memory by forcing the user to filter out extraneous material, and often lead to inefficient internal representations. When internal and external representations do not correspond well, an additional drain is put on a person's mental resources. When the representation inherent in a device or tool puts a user in such a situation, the user must perform "translations," to convert their own representation into the device's terms. This takes cognitive resources away from other tasks (Day 1988). Psychologists note that while a person can develop expertise at working with a specific bad external representation, performance is still likely to suffer in times of peak cognitive demand (Norman 1988, 29).
Part of the reason why experts in a domain perform better than novices is because they develop representations better suited for their tasks. In many cases, their representations combine chunks with automatized processes. Studies of experts in various domains (architecture, chess, physics, psychiatry, etc.) have shown that experts in a field develop internal representations based on high-level features and problem-solving strategies (Schön 1983; Chase and Simon 1973; Anderson 1985; Chi, Feltovich, and Glaser 1981). They come to think of situations as "conservation of energy problems," "cases of measles," "cases of libel," etc. Experts develop mental "libraries" of situations and materials they frequently encounter, and how to deal with them. They develop a "repertoire of expectations, images, and techniques" (Schön 1983, 60).
Studies indicate that these "libraries" are not superficial; they are fundamental to an expert's ability to function. They are very deeply rooted. Chase and Simon (1973, 55) state that even eye movement -- a highly automatic and subconscious activity -- is largely guided by these internal representations. A chess expert literally sees the board in terms of combinations of pieces that hold certain functional relationships. Weisberg (1986, 13) estimates that the library of an expert contains 20,000-50,000 such chunks. According to another estimate, it takes 10 or more years of working 70-80 hours a week to develop this library (Hayes 1989, 293-298). Clearly, the internal representations developed by professionals in a field are not to be taken lightly!
Much design studies research converges on a similar idea of libraries of partial solutions. Alexander's (Alexander, et al., 1977) patterns are an example, as are the elements described by authors like Krier (1988), Thiis-Evensen (1991), Ching (1979), and even Durand (1802) in architectural primers. These authors describe elements like overhead planes, domes, walls, columns, doors, half-inch trim, and so forth. Schön (1988), and Peter Rowe (1987) describe more extensive categories of "enabling prejudices," "heuristics," "types," typologies," etc. Akin (1986) identifies similar "visual chunks" based on patterns of recall in architects.
The representations we use allow us to work more efficiently. Limiting drain on cognitive resources like attention and short-term memory is crucial for being able to work on complex problems. Experts in a field are able to do this by using internal representations that utilize chunks and evoke processes for dealing with common situations and materials.
External representations, like drawings, physical models, or computer models can improve a person's performance by effectively augmenting an architect's memory and allowing certain ideas to be evaluated more easily. However, in order to be valuable, an external representation must avoid being a drain of resources itself. It must avoid making users translate concepts from their internal representations into the terms of the external representation.
This information about the human mind, representations, and design indicates how representations are used. We know something about the sorts of representations used by architects, in particular. We have considered the question of what's in a representation.
We know something about the effects of representations. We have seen that using the wrong representations can force a person to translate from one representation to another, or keep them from taking full advantage of automatized processes. We have addressed the question of why do we care about representations.
So, what does this mean for CAD software? Based on the information about the effects of representations, I have compiled the following list of guidelines for CAD representations:
The repertoire of skills architects develop through years or decades of training and practice largely concern working with graphical representations of buildings. We learn how to "read" a plan, how to draft, and so on. We develop "libraries" of "graphical chunks" that are linked to heuristics for solving design problems. Rather than forcing a user to stop using these automatized skills and representations, and try to learn others with nearly the same degree of familiarity, a CAD representation should allow architects to use these skills.
This means for instance, that procedural assemblies, where a user writes a script describing a sequence of operations to execute to create a model, are undesirable except perhaps for a few rare situations. Significant mental translation is required in order for a user to express visual/spatial ideas in terms of a logical series of numerical transformations to be performed on sets of coordinates. The skills and processes involved in writing such a script concern logical conditions, flow of control, ordering of operations, working with numerical representations of form and space, and specification of syntax. The representations and processes used are very different from those generally required to imagine and evaluate spatial or graphical compositions. Software should avoid such situations, where the user is forced to develop new repertoires of skills, perform translations in the midst of complicated work, or try to remember multiple representations simultaneously. To this end, CAD software should let the user work primarily in a graphical format.
While CAD representations should be largely graphical/spatial in nature, they should not be based on the sorts of low-level geometric entities found in most commercial CAD packages. Describing architectural elements in terms of such entities is often a time-and thought-intensive process of translation.
Instead, for reasons of familiarity and appropriateness for architectural tasks, the elements in a CAD system should correspond to architectural elements like those described by Alexander, Ching, Rowe, Schön, and others. There is a large body of evidence that architects remember and think about designs in terms of elements like walls, doors, rooms, etc. These embody structural functions, symbolic meaning, and often manufacturing products; consequently, our representations are organized around them. CAD representations should be organized around them, as well.
The correspondence between CAD elements and architectural elements should not be merely cosmetic. CAD system elements should have characteristics appropriate for the type of architectural element they represent. An ordinary hinged door for instance, should have characteristics describing the size of the door, as well as descriptions of jambs, moldings, and placement of hardware.
Representations based on low-level geometric entities are generally incapable of corresponding to architectural elements in an appropriate manner. The characteristics of architectural elements are often hard to express in terms of such elements. Instances of symbols, for instance, may look like architectural elements, but their underlying representations are generally based on geometric entities instead of architectural ones. Consequently, they do not act like architectural entities. A door symbol may look like a door, for instance, but inappropriate performance will result if the user tries to perform a conceptually simple change like modifying the door width (Figure 1).
Figure 1. Trying to change a 24" wide door symbol (left) to represent a 36" door, by changing one (middle) or two (right) scale factors. Note how the thickness of the door and size of the jambs is affected by scale factors.
Some of an architectural element's characteristics can affect the topology of the element. A colonnade should have characteristics indicating the number and placement of columns. A window needs descriptions of how mullions are arranged. This means that parametric shapes based on simple graphic entities are inadequate for the task. Topological changes, like changing the number of cells in a waffle slab or the number and shape of lights in a window, can not be described by changing lengths of parts of a prototype shape. An example is shown below in Figure 2. The window on the right can not be described by changing the parameters of the parametric shape on the left. Even if substitution is allowed, so that one parametric shape can be substituted for another, full topological flexibility is not supported. A complete set of parameteric shapes, capable of representing every conceivable topology, can not be created. The user needs more than a selection of predefined topologies - he needs to have a framework for specifying topologies.
Figure 2. The parametric shape on the left can not handle the topological change to produce the window on the right
A better solution appears to be to describe an entity with high-level, topology-affecting characteristics appropriate for each particular element. A simple colonnade might have a characteristic to describe the number of columns. A window might have a list of mullions and descriptions of their placement. Appropriate lines, planes, volumes, etc. could then be created for display, based on the high-level description.
An element's characteristics should not disappear after initial creation of the elements, as is the case with procedural shapes. Many drafting systems use procedural shapes to generate representations of walls, stairs, colonnades, or another architectural entities, asking questions about wall thickness, number of risers, column spacing, or other characteristics of the architectural entity being represented. However, the actual representation created is a set of geometrically-based entities. For instance, a set of planes are created for the staircase. Initial specification of the representations takes place on the architect's terms, but afterwards, the representations are no easier to modify than lines, planes, or other graphic elements created by any other means. The values the user specified earlier can not be modified. The colonnade must be eliminated and a new one created in its stead. The user's thought processes are interrupted and he is forced to translate a relatively simple conceptual change into the software's terms.
Certain architectural elements can be thought of as being components of others. For instance, architectural primers usually describe doors and windows as being parts of walls. If a wall is moved or eliminated, so are any of its openings. CAD representations should reflect this organization. The characteristics of a high-level element should include references to component elements, and descriptions of how they are incorporated.
It is well established that designs do not jump fully intact into the architect's mind. They are gradually developed and refined, in a more-or-less top-down manner. Consequently, a representation that corresponds closely to the architect's internal representation must be capable of undergoing a similar process of refinement. Elements must be able to be added, be removed, or have values describing their characteristics changed. They should also be able to develop new characteristics as the designer makes additional decisions about their form. If the designer decides that a dome should be ribbed, or that a wall should have a window, the representation needs to be able to handle additional characteristics describing the form and position of the ribs or window.
This is not to say that design consists entirely of refining earlier elements. Architects seldom start with a single nondescript block and refine a building out of it. Elements are not only modified, but also added and removed. The ability to change or add details to existing design elements is very important, however.
One of the guidelines for the selection of representations states that a representation should contain exactly the information required for a task -- no more, no less (Norman 1991, 29). Insufficient information is obviously bad, and there is no reason to distract attention and fill memory with extraneous information.
Prompting a user for unnecessary information can have additional adverse effects. Much of the efficiency of the human mind is due to the automatization of processes. Needless interruption of such smooth-flowing cognitive processes is to be avoided. Interruption of thought processes has been shown to cause ideas to be lost -- in fact, it has been cited as the primary reason why groups of people generate fewer ideas than the same number of people working individually (Deihl and Strobe 1987).
It can therefore be seen that a computer aid for design should not interrupt the architect's thought processes to demand details the designer is not ready to provide. Yet, information sufficient for a designer's immediate task, like evaluating the aesthetic effect of an additional window on the facade of a building, may not be sufficient for other tasks the representation might be used for, like photorealistic rendering or structural calculations.
One possible solution to this seeming incongruity is to use default values or daemons to generate values, as needed, to supplement values provided by the architect. Thus, an architect might only need to indicate the desire to add a window, and perhaps its dimensions, and the software might be able to cope with the missing information by generating its own values to describe moldings, subdivisions, methods of operation, and other information missing from the representation. When exact values for these characteristics become important to the architect, he can replace the automatically-generated values with more accurate ones.
Steps in this direction have already been taken. Ironically, some of the best examples can be found in cheap "house modeling" software marketed to help non-architects design their "dream house." Figure 3, below, shows a screen from one such program, 3D Home Architect, running on an IBM personal computer. As can be seen, the representation of a window goes beyond lines, planes, or volumes. It is not merely an instance selected from a pre-defined list of symbols. Rather, it is a higher-level entity with attributes appropriate for a window, and produces an a graphic representation based on this description. It contains descriptions of method of operation; number, placement, and size of mullions; and size of moldings. It is nested within a wall entity. It contains little lighting information, and limits the user's options with inherent assumptions about construction methods and materials, but it is a step towards the elements described in this paper.
Figure 3. Definition of a window in 3D Home Architect, Edition 2.0 Demo version. Model is a sample provided with the demo version, modified by the author. 3D Home Architect is Copyright 1996 by Brøderbund Software, Inc., with program copyright by Advanced Relational Technology.
A project to implement a more extensive system is currently underway. The goal of this project is to allow the editing of computer models by letting the user manipulate representations of the sort described in this paper. In order to accommodate a full range of elements, three types of element descriptions are being used: standard, process-oriented, and bottom-up. These are shown in Table 1 and described below.
| description type | description method | example element | example description |
| standard | specification of parameters | round column | radius, height |
| process-oriented | parameters controlling the generation of the element according to a given generation process | solid of revolution | description of cross-section to revolve, angle of revolution |
| bottom-up | operations performed on non-architectural graphic primitives | unique sculpture | CSG description: set operations performed on primitive volumes |
Standard element descriptions are to be used in situations where an element follows a certain "standard" prototype, like a round column, a Vignolan Corinthian column, a standard plumbing fixture or piece of furniture, etc. The element can be described by specifying a few parameters for location, orientation, scale, radius, etc.
Process-oriented descriptions are to be used to describe elements according to a process for generating them. Examples include a column described as a series of cross-sections, a solid of revolution, an element created by extruding a cross section along a specified extrusion path, etc. Changing the characteristics of a process-oriented description can result in a change in the topology of an element.
Bottom-up descriptions are to supplement the other description methods. No matter how desperately a programmer tries to anticipate every possible form an architect might wish to create, some architect somewhere will want to create something so bizarre as to not fit any provided standard or process-oriented descriptions. A bottom-up description method, based on Constructive Solid Geometries will be provided for such contingencies.
These three types of element descriptions are not incompatible; they can work together. For instance, a standard description of a window might include references to component mullions, defined in a process-oriented manner as a cross-section to be extruded along a path. What starts out as a simple round column in early schematic design may be represented initially with a standard element description, but as the design is refined, it may be changed to a column defined as a series of cross-sections or as a unique form sculpted through CSG operations.
The mental representations architects use are vital for being able to function as productive designers. A variety of authors have identified elements like walls, columns, doors, rooms, and roofs as examples of the sorts of design elements around which an architect's knowledge and skills are based. These representations are not merely familiar; they allow efficient use of limited cognitive resources like attention and short-term memory. They are closely linked to the thought processes an architect uses in the process of design, including solution strategies and even perception.
In general, guidelines for user interfaces and for selection of external representations advocate matching internal representations. This avoids forcing the user to perform translations, and also avoids distracting the user with unwanted information. In keeping with this principle, several guidelines emerge concerning representations in an architectural CAD system:
A project is currently underway to demonstrate the feasibility of such elements. Through a combination of standard and process-oriented description methods, most architectural elements should be able to be represented, and a bottom-up description method can be used to represent any other, anomalous elements. The detail to which such a system of elements can reasonably be carried, the ability to base various analyses and calculations on such representations, and several other issues still need to be explored, but there is sound psychological evidence supporting the need for such representations.
3D Home Architect, Edition 2.0 Demo. Brøderbund Software, Inc., Novato, California.
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. 1982. "Acquisition of Cognitive Skill." Psychological Review, 89, no. 4, pp. 369-406.
Anderson, John R. 1985. "The Development of Expertise." Chapter 9 of Cognitive Psychology and Its Implications. 2nd ed. New York: W. H. Freeman & Co.
Anderson, John R. 1990. Cognitive Psychology and Its Implications. 3rd ed. New York: W. H. Freeman & Co.
Broderbund Software, Inc. 1992. 3D Home Architect: User's Manual. Navato, California: Broderbund Software, Inc.
Card, Stuart K., Thomas P. Moran, and Allen Newell. 1983. The Psychology of Human-Computer Interaction. Hillsdale, New Jersey: Lawrence Erlbaum Associates, Publishers.
Chase, William G., and Herbert A. Simon. 1973. "Perceptions in Chess." Cognitive Psychology, 4, no. 1: pp. 55-81.
Chi, Michelene T. H., Paul J. Feltovich, and Robert Glaser. 1981. "Categorization and Representation of Physics Problems by Experts and Novices." Cognitive Science, 5, pp. 121-152.
Ching, Francis D. K. 1979. Architecture: Form, Space & Order. New York: Van Nostrand Reinhold Co.
Day, Ruth S. 1988. "Alternative Representations." The Psychology of Learning and Motivation, 22, pp. 261-305.
Diehl, Michael, and Wolfgang Stroebe. 1987. "Productivity Loss in Brainstorming Groups: Toward the solution of a riddle." Journal of Personality and Social Psychology, 53, no. 3, pp. 497-509.
Durand, Jean-Nicolas-Louis. 1802. Précis des Leçons d'Architecture données a l'Ecole Polytechnique. Paris, France: Ecole Polytechnique.
Goldschmidt, Gabriella. 1992. "Criteria for Design Evaluation: A Process-Oriented Paradigm." In Evaluating and Predicting Design Performance, ed. Yehuda Kalay, pp. 67-77. New York, New York: John Wiley & Sons, Inc.
Hayes, John R. 1989. The Complete Problem Solver. Hillsdale, New Jersey: Lawrence Erlbaum Associates.
Kieras, David E., and Susan Bovair. 1984. "The Role of a Mental Model in Learning to Operate a Device." Cognitive Science, 8, pp. 255-273.
Krier, Rob. 1988. Architectural Composition. New York, New York: Rizzoli.
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. 1988. The Design of Everyday Things. New York: Doubleday.
Palmer, Stephen E. 1978. "Fundamental Aspects of Cognitive Representation." 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.
Rumelhart, D. E., and D. A. Norman. 1988. "Representation in Memory." Chap. in Stevens' Handbook of Experimental Psychology, eds. R. C Atkinson, R. J. Herrnstein, G. Lindzey, and R. D. Luce. New York: Wiley.
Schacter, Daniel L. 1989. "Memory." Chap. in Foundations of Cognitive Science, ed. M. I. Posner, 683-725. Cambridge, Mass.: M.I.T. Press.
Schön, Donald A. 1988. "Designing: Rules, Types, and Worlds." Design Studies, 9, no. 3, pp. 181-190.
Schön, Donald A. 1983. The Reflective Practitioner: How Professionals Think in Action. New York, New York: Basic Books, Inc.
Thiis-Evensen, Thomas. 1991. Archetypes in Architecture. Oslo, Norway: Norwegian University Press.
Weisberg, Robert W. 1986. Creativity: Genius and Other Myths. New York: W. H. Freeman and Co.
This concludes the paper as published in the ACADIA Conference Procedings.
More information: