ARCHITECTURE-BY-YOU RSELF An Experiment with Computer Graphics for House Design' Guy Weinzapfel and Nicholas Negroponte Architecture

Machine Group, Department of Architecture Massachusetts Institute of Technology, Cambridge, Massachusetts Architecture-by-Yourself is an experiment in computer aided design that applies the medium of computer graphics, used by a general populace. The research program confronts the delicate balance between insightfulness and paternalism toward a user who ultimately bares the risk. The paper reports on a case study, on the underlying philosophy's of the French architect Yona Friedman, and on a computer implementation called YONA. As part of a larger research effort, Machine Recognition and Inference Making in Computer Aids to Design, we postulate further developments that will exercise input and visualization techniques in a relentless setting, relentless in the sense that the user is demanding, the problem is hard, and the product is a personal, one-of-a-kind design. 1. INTRODUCTION design "actions," participating only to provide graphic representations where they were needed and to suggest "next steps" when the couple's efforts were frustrated.

Architecture-by-yourself is an ongoing applications work unit of a computer graphics research project titled, "Machine Recognition and Inference Making in Computer Aids to Design" [1]. As its title suggests, Architecture-by-yourself is concerned with the development of design aids for "do-it-yourself" designers - people designing their own homes or apartments. We see these users as designers, but designers who, unlike architects, are not trained or practiced in the skill. For this reason, their requirements for design aids differ significantly from those of aids created for architects. Most importantly, unpracticed designers require much greater assistance in visualizing their goals and potential form solutions for those goals. They also require assistance (not paternalism) in the process of design - direction, if you will, as to how to go about designing, what steps to pursue next, what to do when progress has stopped. Also, we can argue that they, unlike architects, bear a risk! It is these demands-to visualization and for strategic assistancewhich make design aids for unpracticed designers especially appealing to the Architecture Machine Group, for the Group's major interest is "to understand the makings of architecture; the interfaces between people, machines, and the real world" [2]. It is our expectation that the demands of the unpracticed will push forward developments in the other components of our research program. Focusing on applications for the "by-yourself designer" will accelerate development of graphical input techniques, display capabilities and design strategy systems. The goal of Architecture-by-Yourself is to allow people to design their own homes without either a middleman or a middle machine creating whole solutions for them. This goal diverges from other efforts in computer-assisted architecture which either have generated complete designs for the "user" (such as the ARCHIT system developed at the University of Oregon [3] ) or have required of him a skill and an experience completely at odds with a novice's role (IMAGE would be an example of such a system [4]). 2. DESIGN CASE STUDY

Owner/Designer's Sketch of House Plan The case study is documented elsewhere [5] but the results were quite clear. Most importantly, the couple's greatest difficulties involved a clear understanding of "next steps." Their previous experience enabled them to select favorites from a set of plans or perspectives, but they had no idea how to go about creating plans of their own. Nor could they evaluate given plans against their own stated objectives. When shown problems in or shortcomings with plans they liked, they could "explain away" neither the plans nor their criteria.

To test our hypothesis about the needs of unskilled designers, and to get a sense of the difficulty of what we hoped to do, a simple first step was undertaken: a case study of a young couple designing their own home, a home which they would actually build and live in. This experiment was naively constructed, yet produced very instructive results. The couple met each week for 8 weeks with the Architectureby-Yourself staff. The staff did not function in a conventional architectural fashion. Rather, they served as observers of the couple's

74

Additionally, the couple was never able to visualize what proposed designs would look like. This proved to be a difficult task for the observers as well. Perspectives, showing how a building or space might appear, are time consuming and difficult to draw - sufficiently difficult so that the staff seldom had enough time to provide a representation which was adequate for the couple to make decisions. Conclusions from the case study verified our hypothesis: any design aid developed for unpracticed designers would have to be based on a methodology which incorporated a clear, step-by-step strategy. This was needed to serve as a basis for directing users when they were halted. 3. YONA FRIEDMAN'S GRAPH THEORY PROCESS

The design method proposed by Yona Friedman in his book Towards a Scientific Architecture [6] provided just such a framework. His notion is that the linkages of the house - the connections (doorways) between its spaces - provide both the backbone of the design and the largest payoff in terms of describing the designer's objectives. Friedman represents the rooms of the house and the linkages between them as a graph':

The graph enables the designer to see simple difficulties in his linkages. The use of a graph representation also permits an observer to monitor the designer's progress and to use graph theory to spot troubles early on. These "troubles" might include: 1. 2. 3. the need for multilevels enclosed spaces (implying size and window limitations) impossible access between groups of spaces. 4. THE YONA SYSTEM

Yona Friedman's approach also proposes a series of functions or steps which form a procedural strategy for the inexperienced designer to follow. By determining first a graph, then bubbles over the graph, then shapes over the bubbles, this approach introduces completeness to the design without undue complexity. After the user has learned to deal with one component of design with confidence, the next concept is brought forth. The problem is elaborated until the user is able to deal with an assemblage of concepts and to cycle among them. The strategy is sufficiently flexible so that a user can jump about on his own initiative if he wishes. Perhaps most importantly, Friedman's approach decomposes the design problem, not by abstract concepts of form and function, or by service spaces and areas served, but by the more tangible factors of room placement, connectivity, size, shape, and 3D form. The graph theory approach is additionally pleasing inasmuch as it incorporates the notion of using different representations, each of which is uniquely appropriate to a specific function: 1. 2. 3. planar graphs for room placement relative to other rooms, to sun, wind, and view "bubble diagrams" to visualize areas plan diagrams to determine room shape

The happy correspondence between (1) our interests in graphic communications and nonpaternalistic guidance, (2) the conclusions derived from our case study, and (3) the capabilities of the graph theory approach led quite naturally to the implementation of this approach on the Architecture Machine Group's min-computers. This implementation, titled YONA, runs on any of the Group's Interdata machines (these enclude a Model 70, 7/32s and an 85). Each machine has 64K bytes of core, and any differences between models is transparent to the implementation. User/machine communication is entirely graphical, using IMLAC dynamic displays. Until recently, a light pen had been used for input, but this device proved to be cumbersome and inaccurate. A Touch Sensitive Display tablet [7] has been fitted in place of the IMLAC's implosion shield so that users can manipulate objects on the screen by pointing at them with their fingers.. This eliminates one of the more serious barriers between naive users and the machine. It is illustrated at the top of the next page.

75

updated in real time. When the arrow is released, background routines total the present areas and print the sum along with a range of probable construction costs at the bottom of the screen. In this way, the user is kept abreast of the cost consequences of each change in his specification. By manipulating areas relative to cost estimates, the user can deal with his trade-offs immediately, avoiding unnecessary disappointments later in the process. This simple feature has proven to be one of the most useful in the system, and one which is entirely out of the question in a conventional process. When the user has created all the spaces he wants, he goes on to the next step simply by pointing at LINK SPACES in the upper menu. The screen is blanked and a message appears, PLEASE WAIT. OVERLAYING NEW ROUTINES., u n t i l t h a t o p e r a t i o n i s c o m p l e t e d (approximately 5 seconds).

All of YONA's routines are written in PL/1, the support for which was developed by the Groups software support staff. The size of the system is sufficiently large so that an overlay is used for each of the systems six major functions. Programs within each overlay are organized so that any action taken by a user will receive immediate foreground attention, while periods of user inactivity permit the system to analyze consequences of the users actions in a background mode.

4.2 LINK SPACES. Instructions at the top of the screen inform the user that spaces are linked by first pointing at one space, then at the space with which it is to be linked. The first space identified begins to blink and continues to do so until it is pointed at again. In this way, one space can be linked to several others in rapid succession. A redundant matrix of the linkages is displayed and updated as each new link is added. This has been shown to be of great value, as a user can read across any set of links to verify that the appropriate connection has been made. Links are deleted simply by pointing to the name of either of the linked spaces where it appears in the IS LINKED WITH portion of the window. That is, a link between kitchen and entry could be deleted by pointing either at kitchen where it appears to the right of entry, or entry to the right of kitchen. As each additional link is created, background routines, using graph theorems [8], t e s t t h a t t h e g r a p h i m p l i e d by linkages is still planar. Where it is not, a message is displayed at the bottom of the screen: NO SINGLE LEVEL ARRANGEMENT CAN BE FOUND FOR THIS SET OF LINKS. The user is then referred to a training manual which explains his options: 1. 2. 3. deleting links adding circulation spaces and relinking d e a l i n g w i t h m u l t i p l e l e v e l s i n separate graphs.

4.1.

MAKE SPACES.

In this first of the systems six functions, the user identifies which spaces he wishes to include in his home. He does this by pointing at candidate space names in a menu beside the display window. He may also type the names of those spaces which he does not find in the menu. Created spaces are displayed and an indication of area is included adjacent to the name in the form of a bar spanning from very small to very large. A p o i n t e r i s l o c a t e d o n t h e b a r , s e t initially to the center (average) location, and a numerical value for that pointer location is printed at the end of the line. The user can adjust the size of a space by pointing at the area arrow and sliding it to a new position. While he does this, the numerical value is

It is interesting that. to date. no naive user has yet triggered this message.

76

4.3

ARRANGE GRAPH.

4.5

PRE-SHAPE SPACES.

An initial graph configuration of the specified "home" is generated for the user in which no links are shown crossing. At present, a simple, heuristic approach is used for this generation. However, it is known that the heuristic will not work for all cases, and a deterministic technique [9] is to be implemented shortly.

After a satisfactory arrangement is achieved, "bubbles" of the appropriate areas are displayed over each node/space. The bubbles are drawn using a closed B-spline curve algorithm [10]. The splines are "fitted" within polygons which are formed by the dual of the graph and an outside perimeter which matches the boundary of the graph.

4.4

MOVE SPACES.

The user rearranges the graph by pointing at any "node" and sliding it to a new location. Crossed links provide graphic "warnings" that the connections involved are impossible. Background routines being developed will warn if "NO ARRANGEMENT IS POSSIBLE WITHOUT SOME ENCLOSED SPACE." * Further background routines may be added to check that orientation for views, sun, and wind are maintained. Development of these routines have been postponed because we are concerned that soliciting the necessary information may be too taxing for users of the system. It may be better to ask and do less. Experiments in the next year will address this issue.

Diagram of dual displayed over graph with "bubbles" drawn within polygons of dual. The bubbles are "sized" in two passes. First a vector sum "gravity" routine adjusts the placement of the nodes in the graph according to their relative sizes. Then a second vector sum pass is made for the points of each polygon in the dual.

77

4.6 SKETCH SHAPE. Using the sized bubbles as area guides, the user sketches the actual shapes of the rooms. To simplify this task, a grid is displayed to which the sketched lines are snapped. Only straight lines and arcs are possible at this time. As the shapes are completed, the bubbles are deleted. Checking for the reporting of major deviations are done in the background. And our adjusted played. (These are n o t shown in the previous tines are only now being interfaced with the 5. FUTURE DEVELOPMENT from area requirements cost estimate is disfigure as these rousystem.)

REFERENCES
1.

Machine Recognition and Inference Making in Computer Aids to Design. MIT, Architecture Machine Group, NSF Proposal, 1974. Negroponte, Nicholas, The Architecture Machine,
Aided Design, Vol. 7. No. 3, 1975.

2. 3.

Computer

Finrow, Jerry, and Heilman, Robert, Toward a User Based Automated Architectural Design System: Theory, System O p e r a t i o n a n d F u t u r e D e v e l o p m e n t , DMG-DRS J o u r n a l , Vol. 7, No. 2, 1973, p. 124. Weinzapfel, G u y , IMAGE-A Computer Design Aid System,
WorkProceedings of the Share-ACM-IEEE Design Automation shop, June 28-30, 1971, Atlantic City, New Jersey.

4. Two additional capabilities will be added during the next year. The first of these will translate the sketched room shapes into more complete plan representations, showing wall thicknesses and door and window locations and enabling placement of furniture.

5. 6. 7. 8.

Weinzapfel, Guy, The Falco Experiment, MIT, Architecture Machine Group, working paper, 1975. Friedman, Yona, Toward a Scientific Architecture, MIT Press, 1975. Cambridge:

Touch Sensitive Displays, MIT, Architecture Machine Group, ARPA Proposal, 1978. A simplistic brute force process is used at the present time. See John Hopcroft and Robert Tarjan, Efficient Planarity Testing, Journal of the Association for Computing Machinery. Vol. 21, No. 4, pp. 549-568, 1974, for a more efficient algorithm which may be implemented in the coming year if response times are too slow from our present routine. Smith, Stephen Garland, A Graph Theoretic Approach to Interactive Layout Planning, MIT, M.S. Thesis, Management, Dewey Archives, 1971.

9.

Potential representation of floor plan with walls and thicknesses indicated and furniture placed. YONA presently makes n o u s e o f t h e M a c h i n e G r o u p s r a p i d l y developing raster scan capabilities. The coming years work, however, should see significant explorations of this technology for visualizations o f d e s i g n e d e n v i r o n m e n t s . O n e can e a s i l y i m a g i n e a u s e r p a i n t i n g the walls of his/her living room, not only with various colors but with textures as well (brick, panelling, et cetera). In summary, we see Architecture-by-Yourself as a worst-case exercise in man-machine interaction. The machine must be simultaneously understanding, helpful and not paternalistic. The user must deal with the soul-searching decisions of personal design. And, the partnership must yield a workable, cost-affective, one-of-a-kind solution.

78