URBAN5 was designed to be a self-teaching system. At first it was assumed that the architect-user would have had no previous programming experience. Later, it was further assumed that he had not even read an instruction manual. Thus URBAN5 would have to teach its own language; learn through teaching, change from learning, and adapt from changing.
URBAN5 greets a designer with only the start button illuminated. When it is depressed, the first question is whether this is the user’s first experience with the machine. If it is indeed the first time, the machine presents an unsolicited page of text that describes how to proceed, how to use the hardware, and what to do when the user gets stuck. Also, each time the designer enters a mode for the first time or uses an operation for the first time, the monitor automatically calls forth a set of instructions. In each case, as the designer is told, he must reinterrupt the machine with his original request to have the operation actually executed and the text removed.
However, even the text of these instructions may employ a language that is new or unclear to the designer. The words may be too technical or cloudy in their new context. In this case the designer may detect an unintelligible word with his light pen (as he has been told), and the machine will display a new paragraph defining that word. Naturally, the interrogation of word meaning can continue recursively, word definition within definition, within another definition. All words, of course, are not internally defined; when simple terms are detected, the designer is referred to a dictionary.
The word-learning role works both ways. For example, a designer may state a criterion in the following conversation:
Architect: All studios must have outdoor access. URBAN5: I am sorry I do not understand. Architect: All studios must have access to the outdoors. URBAN5: I am sorry I do not understand. Architect: A one-room residential unit must have outdoor access. URBAN5: Now I understand. Furthermore, from now on, whenever you say “studios,” I will assume you mean one-room residential units.
At this point, not only is the criterion entered into the general conflict structure, but the new word “studios” is recorded in the translation mechanism that belongs to this particular architect. Another designer would have to undergo a similar session with his machine to define “studios” (possibly with another meaning).
When symbols are defined by the designer, they too are registered in his personal machine lexicon. In just these examples of word building, the designer is beginning to construct his own machine partner out of the skeletal framework of URBAN5. This transformation occurs in the satellite machine, where the user is allowed to penetrate the surface of URBAN5, getting deeper and deeper into its assumptions and definitions. The user can even change algorithms without actually programming in a computer language or knowing where the routine resides.
This pseudoevolution is implemented in the following manner. The virgin system is stored on a disk, and the user’s consciously and subconsciously composed system is recorded on a magnetic tape. When a designer arrives at the display terminal, he meets a generalized computer system that asks his name. Having identified the designer, URBAN5 automatically dumps the contents of the designer’s magnetic tape onto URBAN5’s disk, thus overlaying the general system with the personal edition of this designer. At this point the machine appears to the designer as his particular (possibly evolved) design partner. At the termination of a design “sitting” (since the present configuration does not allow twenty-four-hour dedication), the designer’s magnetic tape is re-created, incorporating any changes or inklings of evolution, and URBAN5’s disk is restored to anonymity.
At the first man-machine encounter, the designer’s tape is empty; he converses with the nucleus of the system. As he converses with the machine more and more frequently, the contents of his tape become more significant. As time passes, URBAN5 in fact shrinks itself, letting certain operations self-destruct themselves through obsolescence. To allow for the user-created machine, unused procedures are discarded. (Should the designer ever request a procedure that has been previously removed, the system will require some time to fetch the routine from a library and to reincorporate it into the system.)
The first time one employs URBAN5, a barrage of unsolicited instructions will be presented to explain the knobs and dials.
Ted Turano observes explanatory text, which includes a diagram representing his site, the section he is working in, and an arrow denoting his orientation.
Upon termination, a few of the many statistics are presented.
In theory, after some time the designer’s system would bear little semblance to the original URBAN5. The authors of URBAN5 might not recognize the transformed version. URBAN5 will have ushered the user deeper and deeper into the system, first teaching him, then learning from him, and eventually dialoguing with him. The progression that URBAN5 suggests is one that proceeds from a rigid system (for the designer to understand easily) to a flexible system (volatile enough to allow different tasks) to an adaptable system (where the machine loses its flexibility but gains an adaptability through evolution).
In other words, URBAN5 suggests true dialogue, suggests an evolutionary system, suggests an intelligent system—but, in itself, is none of these.
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
