U A Case Study in Architectural Design Michael Pearce, Galaxy Scientific Corporation Ashok K. Goel, Janet 1. Kolodner, Craig Zimring, Lucas Sentosa, and Richard Billington, Georgia Institute of Technology

have many possible spatial configurations

facts involves a series of decisions. To design an office building, you might make decisions about applying abstract design concepts and skeletal design plans, selecting specific systems and components, retracting earlier decisions, relaxing design con- straints, accepting design solutions, and so on. How hard it is to make these decisions

zines, books, and the memories of other ence as naive users of office buildings.

W E WANTED TO FIND OUT WHETHER A LARGE CASE LIBRARY COULD SUPPORT HUMAN DECISION MAKING IN A

COMPLEX TASK SUCH AS DESIGN. WHILE THE ARCHIE SYSTEM MET MANY OF OUR GOALS, WE LEARNED JUST AS

MUCH FROM ITS LIMITATIONS.

decisions. For the office building, we might but are scattered in file cabinets, maga-

that do not correspond directly to design , designers. Some large architectural firms constraints, making it hard to select among ~ have small libraries of proprietary designs, them. If the architect does not have the but typically they are indexed with just a appropriate knowledge, poor decisions- , few mnemonic features that do not always and poor designs-can result. Thus, pro- ~ indicate a past design's relevance to a cur- viding good decision support for architects ~ rent design problem. and other designers is a real challenge for To find out whether large case libraries researchers on intelligent computer-aided can support and improve human decision design. ~ making in complex tasks,' we decided to

access to domain experts and experi-

(3) The system should support conceptual as opposed to detailed design, because this is generally the more difficult and innovative part of the process, and be- causetheseearlydecisions haveamajor impact on what follows. We also de- cided to support design proposal and critiquing, two subtasks of conceptual design.

IEEE EXPERT -~ . .

OXX5/9000/92/1000-0014 $3 00 0 1992 IEEE ~-

14

choices. However, despite the apparent ~ (1) The system should support common abundance and extensive use of past de- ~ design tasks but leave all decisions to signs in decision making, architects do not the user. always have easy access to appropriate (2) The system should apply to the design cases. They are not organized in libraries, of office buildings, because we had

represent, index, and retrieve architectural design cases, our early work focused on developing a vocabulary for representing and organizing such cases in a library, and on schemes for retrieving those relevant to

0-Goal Group interaction Very important

0-Goal Organization type

Figure 1. A design case in Archie.

a given design task. While building and using Archie, we encountered other issues whose importance we did not fully appre- ciate at first, but that we are now exploring in two parallel projects: Archie2 and Archie Tutor.

design plans that specify building com- ponents (such as walls, doors, and furni- ture) and a satisfactory configuration; outcomes that describe how well the plan satisfies its goals and constraints (explicit and implicit) from a specific point of view (for example, a design outcome could be that auditory privacy was low); and lessons to be learned from the case (not shown), indicating in which situations

lllustra tive examples

Archie helps architects in the high-level task of conceptual design as opposed to low-level tasks such as drawing and draft- ing, numerical calculations, and constraint propagation.

Proposing a design. Archie gives archi- tects access to office building designs cre- ated by other architects, and points to fac- tors that must be considered in solving a given design problem. Each case in Archie contains several types of information (see Figure 1 )?:

design goals (such as group interaction) andconstraints (such as a partition height above eye level):

the case will be useful, provided to the user as text annotations so they are easy to understand.

The goals and outcomes prefixed by “0” in the figure pertain to the client organiza- tion and describe the people who use the building and their interactions with that building. The goals, plans, and outcomes prefixed by “C” describe the core, or per- manent aspects, of the building. For exam- ple, the total area of the design described in Figure I is about 14,500 square feet and is likely to remain the same over time. Fea- tures prefixed by “P’ specify the building partitions, the nonpermanent interior struc- tures that divide the space. For example,

one changeable aspect ofthe plan in Figure 1 is that the manager’s office has glass walls. Features prefixed by “F’ represent furniture. For example, one outcome of the design in Figure 1 is that the furniture color was pleasing.

A session with Archie begins as a client outlines a set of requirements for an office building-let’s say office space for a small accounting firm:

Since customers frequently visit the com- pany offices, the image projected by the office space is very important. Given the nature of the work to be done there, the offices need facilities for face- to-face contact and group interaction. The company is dynamic and growing, so the design should allow for future modifications. Since the company maintains paper files on its clients, the offices must have a good filing system. The company needs about 12.000 square feet of space and has budgeted $300,000 for partitions and furniture.

The architect uses Archie’s vocabulary to prepare a probe representing the customer’s

I Figure 2. Probing Archie‘s case memory.

I Color shade I F G e 3. Model of lighting quality.

design goals and constraints (see Figure 2 ) Each box in the figure represents a feature in the probe The feature’s name is on the left, its balue is on the right, and the label\ to the right ot each box describe the type ot value it can tdke Fedtures in probes use the same “0,” “C,” and “F’ prefixes that case features use (see Figure 1 )

Having received a probe, Archie cdlcu-

~ ~~~~~~ ~ ~

~~ ~ ~~

16

lates a similarity value for each stored case based on how close each concept value i s to specified values in the probe and on the concept’s importance. It retrieves cases whose similarity value is above a predeter- mined threshold. Figure 1 is part of a case retrieved by the probe i n Figure 2.

Browsing through the retrieved cases, the architect sees how other architects solved

similar design problems, and can combine solutions from several cases to create a high-level qualitative design that achieves the client’s goals. For example, the case in Figure 1 uses an open office plan to achieve flexibility, face-to-face contact, and group interaction. An open architectural plan implies low, movable partitions to separate office spaces rather than fixed ceiling-to- floor walls. Since face-to-face contact and employee interaction are important design goals in the current problem, the architect might adopt the open office plan of the previous case. The architect copies fea- tures from interesting cases to produce a partially specified conceptual design for the new office building. In this way, Archie helps architects brainstorm by letting them explore previous cases for ideas and inspi- rations.

Critiquing a design. With a partially specified conceptual design in hand, the architect can now critique the design to locate potential problems. This mode of operation involves more focused reason- ing: The architect wants detailed informa- tion within a narrow context. For example, the architect may be concerned with the quality of lighting i n a proposed office design, and selects one of several qualita- tive domain models in Archie that repre- sent the perspectives of different experts on that aspect of the design (see Figure 3).

Figure 4 shows the part of a retrieved case that pertains to lighting, including design goals, plan critiques, lessons learned, and so on. Comments on the case are ex- pressed as text annotations (shown in shaded boxes): Goal comments refer to interactions among design goals, plan com- ments specify individual design decisions and their relations to goals, outcome com- ments explain the outcomes, and case com- ments provide general background on the building’s design. The “0-Outcome: Moral” list, enclosed in adouble box. spec- ifies the lessons learned from the case.

The “C-Outcome: Lighting Satisfaction- Artificial” feature, also enclosed in a dou- ble box, shows that the glare problems that led Archie to retrieve this case were caused by artificial lighting. The “0-Outcome: Moral” tells the architect how to modify the proposed design (by using diffusers over bulbs).

After fixing this aspect of the design, the architect might similarly critique the

*Design for a wide variety of users ‘Information technology modular furniture used except in outside workgroup

*All offices have fixed partitions, no 1 Goal 1 1 Plan secretary bays 11 Outcome ‘Easy to adjust workgroup size 1 both sides (managers on outside)

*Hodgepodge of furni ture systems

*Not much interaction with workers

comments ‘Central hallway with offices on comments comments

-~ igure 4. Case features associated with lighting quality.

design from other perspectives. This pro- cess of retrieving, critiquing, and adapting continues until the architect is satisfied with the design.

System implementation

We built Archie using Remind, Cogni- tive Systems’ case-based knowledge- engineering shell.’ The tool lets program- mers design a case representation, enter case information, set up a retrieval mecha- nism, and design a presentation format. Remind includes a graphical function edi- tor for dynamically computing features, a direct manipulation editor for designing

a specific aspect of a building such as aesthetics, furniture systems, lighting sys- tems, and so on. Finally, we used post- occupancy evaluations written by archi- tects and researchers who were trying to identify the sources of a building’s prob- lems and suggest ways (based on cost and effort) to fix them. Thus, the quality and completeness of information in Archie’s cases vary widely.

Knowledge organization. Archie con- tains three kinds of knowledge: primitive concepts, domain models, and design cases. Primitive concepts refer to the primitive objects, relations, and parameters of office buildings, and form part of the language for representing and indexing cases. Do- main models capture the causal relation- ships among case concepts.

Cases in Archie are represented as flat,

~.

case displays, and a retrieval explanation editor. All the figures i n this article are based on Archie screens that were pro- duced using Remind.

Cases in Archie describe specific build- ing designs. We collected about 20 cases from three sources. Some are based on our experiences in the office buildings where we (one or more ofthe authors) have worked. We also used professional architectural journals, whose articles typically deal with

static frames, each with more than 150 possible features Features can be con- cepts, text, integers, real numbers, or func- tions Most features are concepts, with some numbers and text

Archie’s features originated from three wurces From our analysis of office build-

~~ ~ ~~~ ~

~~~ ~~ ~~~

I

ings, we developed features that differenti- ate one building from another, including I

descriptions of users, rooms, equipment, , and users’ likes and dislikes. Other fea- ,

of the walls, floor, and furniture all affect i tures came from the domain models that describe outcomes. For example, the color

the amount of glare in a office, so these features were added to the representation 1 language. Finally, some features devel- oped from usability issues.

Understanding a case by reading the concept features in its description can be difficult because of the large number of features. Since users must understand the points a case is trying to make but don’t have to understand Archie’s representa- tion scheme, we added textual features to create a more natural interface. The num- ber of features in Archie grew rapidly as we analyzed the first few cases, but then stabilized after about 10 cases.

Case retrieval. Remind gives Archie two mechanisms for retrieving cases: near- est-neighbor matching and model-based clustering. These mechanisms are used in the brainstorming and focused-problem-

17 ~ ~ ~~~~~~~ . ~~

~~~~~ ~~~~~~ ~ .

I I Figure 5. A partial concept hierarchy.

solving modes of operation, respectively, which we described earlier.

Primitive concepts and nearest-neighbor matching. Archie uses nearest-neighbor matching and primitive concepts to re- trieve building designs that satisfy a prob- lem’s goals and constraints. The concept features that form Archie’s representation language are organized hierarchically to specify the goals, plans, and outcomes of design cases. Concept slots are the most important features for case retrieval be- cause they represent classes of objects and their partial orderings. Some of Archie’s concepts pertain to domain objects such as lighting devices; others are more abstract, such as lighting quality. Figure 5 shows a small subset of these concepts. Concept nodes with squares in their boxes have subnodes that can be expanded into the values that the concept can take. For exam-

ple, Archie knows that lighting devices can be fluorescent, halogen, or incandescent. The “<” relation in the figure indicates partially ordered concepts.

Domain models and model-based clus- tering. Archie’s second retrieval method uses simple domain models to cluster cases i n memory. These models represent Arch- ie’s domain knowledge about office build- ing design. For example, according to Arch- ie’s causal model of lighting (see Figure 3), satisfaction with lighting depends on the quality of light and the glare intensity (the nodes with rounded corners). The lower half of the model captures knowledge about the factors that lead to glare in an office: the shade of the wall color, the shade of the floor color, and so on. The nodes on the far left in the figure are case features. The positive (and negative) signs indicate that as the value of a case feature increases, the

value of the feature being pointed to in- creases (or decreases). For example, as the shade of the wall color “increases” from lighter to darker shades, the glare intensity decreases, which increases the overall sat- isfaction with the lighting.

To critique a proposed design’s lighting quality, an architect might select the light- ing model shown in Figure 3. Archie uses this model to cluster cases by the features that affect the lighting outcome, and the resulting classification tree is shown in Figure 6. The rectangular boxes specify the tree’s partitioning nodes and the names of corresponding features from the light- ing model. The boxes with rounded cor- ners represent case clusters, and the text describes the outcomes of the cases.

Archie retrieves the appropriate cases and predicts the outcome of new designs based on this tree. For example, the round- ed box with the text “1 Glare Case” and its placement in the classification tree indi- cate that Archie has only one case with low lighting quality and high glare inten- sity. If the features of the current design lead Archie to predict this outcome, the system retrieves “ 1 Glare Case” and dis- plays it to the architect. In this way, Arch- ie’s models help architects critique pro- posed designs.

lessons learned

In developing Archie, we learned sever- al practical lessons about building large

1 No control over level Case

1

Figure 6. Clustering of cases based on the lighting model.

18 IEEE EXPERT

case-based systems to support real-world decision making.

Lesson 1: Real-world cases are incom- plete. While the domain of architectural design contains an abundance of cases, it is not easy to find well-documented cases of office building designs. Drawings and pic- tures are readily available, but their case analyses are often incomplete, and justifi- cations for the architect’s design decisions and outcomes are generally not known. Even the design goals and constraints are often unclear. This severely limits the use- fulness of past cases in making new design decisions. It is also one of the reasons why Archie contains only about 20 cases.

So how do we acquire well-documented cases? Or, how do we use incomplete cases to support decision making? The best prac- tical solution might be to settle for many semidocumented cases rather than a few fully documented ones. This approach will require robust reasoning procedures that can process incomplete and possibly in- consistent case descriptions. It might, for example, require procedures to combine information from multiple cases in a way that detects inconsistencies.

Lesson 2: Real-world cases are large. Archie needs a large vocabulary to capture enough information about a case to make it useful in different situations. A well- documented case might contain a huge amount of potentially useful information about clients, design goals and constraints, designers, design history, the design plan, post-occupancy feedback and analysis, and so on. The large size of cases is another reason why Archie contains only about 20 cases: Much effort is required to gather this much information.

This presents problems for building a case-based decision-support system, includ- ing how to represent case content and in- dex and display cases. For example, there is a large gap between the grain size of available cases and the grain size of deci- sions the architect needs to make. It is not easy to extract fine-grained information from Archie’s large-grain cases.

In Archie 2,4 we are trying to organize large cases into case-subcase hi er arc hie^.^ However, this solution raises several more complex issues, including the dimensions into which a case can and should be de- composed. For example, the Julia system

OCTOBER 1992 ~________________

structurally decomposes meals to design menus.6 The Kritik system, which designs electrical and mechanical devices, decom- poses devices functionally and structural- ly.’ We could do the same with office spaces. For example, we could structurally decompose an office building into floors, and the floors into offices, corridors, and so on; we could also decompose the same building functionally into different types of offices and other spaces.

The organization of case-subcase hier- archies raises another issue: how to present information about a case’s internal organi- zation so that a user can easily navigate through subcases. The format must enable navigation both within and across cases.

Lesson 3: Systems must offer users multiple types of knowledge. Since our initial goal was to investigate the role of case-based reasoning in design, Archie pro- vides only an external memory of design cases; architects cannot access the domain models themselves. However, as the project progressed, we realized that access to the models might be useful, especially because architects often use multiple types of knowl- edge when designing buildings. Access to both models and cases might be especially useful for architecture students, because they are creating explicit interactions among domain objects and processes.

In Archie Tutor, we are investigating how to represent design cases and rules as well as domain models, and how to give architects access to all three kinds ofknowl- edge. Different types of knowledge will need to be cross-indexed, so that the user can navigate from one type to another; for example, from a design case to a domain model that explains some portion of the case, to a design rule abstracted from the model, to another case that illustrates the rule. Kritik provides a scheme for cross- indexing design cases and causal models7 AskJef, which helps software engineers design human-computer interfaces, provides a scheme for cross-indexing design cases and design rules.8 Such direct access to different types of knowledge requires a tax- onomy of decisions and decision contexts that the prospective user might face. It also requires an indexing scheme that maps classes of decisions and their contexts into the different types of stored knowledge.

Lesson 4: Systems must present rele-

vant information. Archie uses a set of static forms (the same ones for proposing and critiquing designs) to present informa- tion. Each form corresponds to a view of the system (such as the lighting model) and specifies a subset of case features and an arrangement for displaying them. Presented with achoice of forms, the architect selects one relevant to the task at hand.

Since the forms are static, neither the architect nor the system can dynamically restructure the interface to make important information more salient. However, since Archie’s cases are used for both proposing and critiquing, different chunks of infor- mation are more or less important in differ- ent phases of the design process.

Also, since our early work focused on representation, we designed the interface more for knowledge engineering than for use by architects. It soon became obvious that the interface was too painful to use by anyone other than a knowledge engineer. Even if Archie had many well-documented cases, it would not be usable until it could present information in a quickly and easily understood format. We are now exploring usability issues, especially how to best present large amounts of knowledge to user^.^^^

A RCHIE goes beyond supporting ar- chitects in design proposal and critiquing. It acts as a shared external memory that supports two kinds of design collabora- tion.’” First, by including enough knowl- edge about the goals, plans, outcomes, and lessons of past cases, it lets the designer access the work of previous architects. Second, by providing access to the per- spectives of domain experts via the domain models, Archie helps architects anticipate and accommodate experts’ views on evolv- ing designs.

The system accomplished many of the goals we had in mind when we started the project. Its vocabulary is stable and ex- pressive enough to represent and index both existing and new cases. However, the current version of Archie is only par- tially successful in supporting architec- tural design. Indeed, some of the most important contributions of the Archie ex- periment are the lessons we learned from its limitations.

Acknowledgments

Sambasiva Bhatta, Thomas Hinrichs, Ali Malkawi, and Daniel Willham worked on the original Archie system. The Archie 2 team in- cludes Richard Billington, Joshua Bleier, Eric Domeshek, Janet Kolodner, Anna Zacherl, and Craig Zimring. The Archie Tutor team includes Ashok Goel, Kim Liu, Ali Malkawi, and Michael Pearce. The AskJef group included John Barber, Sambasiva Bhatta, Ashok Goel. Mark Jacobson, Michael Pearce, Louise Penberthy, Murali Shan- kar, Robert Simpson, and Eleni Stroulia. Work on Archie has been supported by agrant from the US Defense Dept.’s Advanced Research Projects Agency, monitored by the Air Force Office of Scientific Research under contract F49620-88- c-0058.

References

1 . J . Kolodner, “Improving Human Decision Making Through Case-Based Decision Aid- ing,” AI Magazine, Vol. 12, No. 2, 1991, pp. 52-68.

2. A. Goel et al., “A Case-Based Tool for Conceptual Design Problem Solving,” Proc. Third DARPA Workshop on Cuse-Bused Reasoning, Morgan Kaufmann, San Ma- teo, Calif., 1991, pp. 109-120.

3. Case-Based Retrieval Shell Users Manual, Cognitive Systems, Boston, Jan. 1990.

4. E. Domeshek and J. Kolodner, “A Case- Based Design Aid for Architecture,” Proc. Second Int’l Conf on AI in DesiRn, Kluwer Academic Publishers. pp. 497-5 16.

, Norwell, Mass., 1992,

5. M. Redmond, “Distributed Cases for Case- 1 Based Reasoning: Facilitating Use of Mul- , tiple Cases,” Proc. Eighth Nut ‘ I Con$ Arti- ficial Intelligence (AAA1 ’90). Morgan 1 Kaufmann, San Mateo, Calif., 1990, pp. I 304-309.

6. T. Hinrichs, Problem Solb’ing in Open 1 Worlds: A Case Sfudy in Design, doctoral dissertation, College of Computing, Geor- gia Institute of Technology, Atlanta, 1991.

7. A. Goel, ”A Model-Based Approach to Case Adaptation,” Proc. 13th Annual ConJ: Cognitive Science Soc., Lawrence Erlbaum, Hillsdale, N.J., 1991, pp. 143.148.

8. J. Barber et al., “AskJef Integration of Case-Based and Multimedia Technologies for Interface Design Support,” Proc. Sec- ond Int’l Conf. AI in Desian. Kluwer Aca-

Michael Pearce is a software engineer at Galaxy Scientific Cor- poration, where he builds intelligent tutoring sys- tems. He received his MS in information and computer science from the Georgia Institute of Technologyin 1991.His current research inter-

ests include man-machine interface design, inte- grated training and job-aiding systems, theory of design, and the learning of robot navigation.

He can be reached at Galaxy Scientific Corp., Information Division, 3210ParklakeDrive, Suite 325, Atlanta, BA 30345.

Ashok K. Goel is an assistant professor in the College of Comput- ing at the Georgia In- stitute of Technology. His research focuses on planning and design problem solving, qual- itative modeling and model-based reasoning, and cased-based rea-

soning and learning. He received his MS in physics and his PhD in computer and informa- tion science from Ohio State University. He chairs the Artificial Intelligence Technical Committee of the IEEE Systems, Man, and Cybernetics Society.

Janet 1. Kolodner is a professor of computer science in the College of Computing at the Georgia Institute of Technology She re- ceived her PhD in com- puter science from Yale University in 1980.

Having pio- demic Publishers, Norwell, Mass., 1992, , neered the development

of case-based reasoning, she is concentrating pp. 457-476. I on applying that method to design, and on the

9. A. Goel et al., “Archie: A Case-Based Ar- implications of CBR for decision aiding, edu- chitectural Design System,” Tech. Report cation, and creative problem solving. She is GIT-CC-9 1/18, College of Computing, I editor-in-chief of The Journal o f the Learning Georgialnst. ofTechnology, Atlanta, 1991. ~ Sciences.

_ _ _ - ~ - ~ ~ ~ _______ ~ ~ _ _ ~ ~ - ~ _ ~ _ _ _ _ 20 - - - ~ ~ ~ _ _ _ _ _ _ _ _ _ ~ ~ ~ ~ ~ ~ _ _ _ ~ ~ - _ _

Craig Zimring is asso- ciate professor of archi- tecture and psychology at the Georgia Institute of Technology. He re- ceived his PhD in envi- ronmental psychology from the University of Massachusetts at Am- herst. His research fo- cuses on studying and

developing collaborative design and evaluation tools and processes for building planning, de- sign, and evaluation. He is a member of the Environmental Design Research Association and the International Association of People and Their Physical Setting.

Lucas Sentosa is a doctoral candidate in archi- tecture at the Georgia Institute of Technology. He received his Master of Architecture degree from the University of Colorado at Boulder. His research interests include environment behavior studies and computer-assisted space manage- ment in architecture. His photograph was not available

R....mrd Billington is a research scientist at the Georgia Institute of Technology and vice president of the Associ- ation of Lisp Users. He received his MS in in- formation and comput- er science from the Uni- versity of Pennsylvania.

Readers can reach the authors in care of Ashok Goel, College of Computing, Georgia Institute of Technology, 801 Atlantic Drive, Atlanta, CA 30332, or by e-mail at goel @cc.gatech.edu

IEEE EXPERT

I

I

I

I 1

I

i

I

i

i I

i

I

I i I

F -1 __I