URBAN5’s Abstractions

In an ideal situation, the communication language could be so informal, that is so natural, that the computer aided designer would not have to learn it.… If an incompatibility is found, the designer concerned would be informed.…

I. H. Gould, “Some Limitations of Computer Aided Design”

Up to this point, suppositions have been a posteriori reflections upon experiences with the development of the computer system URBAN5. Therefore, this chapter primarily exemplifies some of the previous issues and describes the sequence of events that led to them.

URBAN5’s original goal was naively simple. It was to “study the desirability and feasibility of conversing with a machine about an environmental design project… using the computer as an objective mirror of the user’s own design criteria and form decisions; reflecting responses formed from a larger information base than the user’s personal experience” (Negroponte and Groisser, 1967a). The object was to develop a system that could monitor design procedures, in effect, be an urban design clerk.

At the onset of the experiment four assumptions were made: (1) the user is an architect; (2) urban design is based on physical form; (3) the design process is not algorithmic; (4) urban environments are equilibria resolved from many basic, primarily qualitative, relationships. The first assumption alone generated the spirit of the system, as we further assumed that the architect-user would have no previous experience with computers, let alone ever having talked to one. Thus URBAN5 first of all had to be capable of communicating with an architect in comprehensible language. To do this, the authors of the system chose two languages: English (entered from a typewriter) and a graphic language (using a cathode-ray tube and light pen).

The need for a graphic language made it clear that URBAN5 must handle some, if not all, problems in terms of their suitable abstractions. In other words, the system committed itself to work under synthetic conditions and not to attempt to canvas real-world problems. The graphic system is an example of such abstracting; the geometry selected was the cube—in ten-foot cubes. This building-block system abridged urban design to such an extent that URBAN5 had to recognize it was only simulating a design environment. The hypothesis was that this graphic abstraction “provides a method of simulating the graphics of urban design, furnishes the necessary ‘frictionless vacuum’ environment in which to work, and provides the full range of basic design interrelationships” (Negroponte and Groisser, 1967a).

This original graphic abstraction has distorted some problems, but the simplification has permitted advances that would have been thwarted by any attempt to furnish the “comprehensive” architect-machine graphic language. Critics have often misunderstood URBAN5’s ten-foot cube—it is only a launching vehicle, as, for example, in Newtonian mechanics an experiment will commence with the assumed absence of friction. The experimental results bear information relevant only to the abstract problem; should an engine be designed with only such information, it would indeed run badly in the real world. Similarly, URBAN5 cannot handle real design problems; it is a research toy, and playing with it has been a learning experience.

The ten-foot cube has few architectural impositions and many research conveniences. It generated a language of nouns (the cubes) and verbs (text appearing on the right side of the screen). In this vernacular the designer can pile up these blocks in three dimensions. He can give them qualities, and the machine can give them qualities. He can talk about them. He can play with them. But all this occurs within a context, and a context is defined by a mode.

The scope was connected to an IBM 360/67 (a time-sharing machine) but was not used in time-sharing mode. URBAN5 employed this mammoth computer as a dedicated machine. However, the reader should note that none of the facilities of URBAN5 exercised either device, scope or computer, to its potential. The computer was undertaxed, and the scope was never used dynamically. Both “underusages” anticipated on the one hand a small, dedicated computer and on the other hand a storage tube device like the ARDS.