Background work is perpetually executed within a resident machine that is devoted to servicing a specific designer. This kind of work did not appear relevant at the inception of URBAN5. But about halfway through the system’s development it became clear that URBAN5 had to function in parallel to the user in order to support a growing concern for enriching the dialogue.
While the designer deliberates, URBAN5 engages in five temporal tasks in the following order of priority: (1) it checks for conflicts (as described in the previous section); (2) it does long operations; (3) it takes care of output procedures; (4) it does housekeeping; (5) it plays. When the designer presses a button, types in a message, or uses the light pen, he is interrupting one of these five operations by demanding the machine’s attention elsewhere. As soon as the machine finishes servicing him, it returns to the unfinished or newly created background work.
Long operations are user-requested design tasks that require more than just a few seconds of machine time. To expedite the designer’s sequence of actions, URBAN5, when it recognizes a lengthy job, places the operation in the temporal zone to be processed when operationally convenient. The system suggests that the architect continue, and the outcome will be reported later. Naturally, if the operation is critical to a next step (or if the designer is going off for a cup of coffee anyway), he can intervene and demand that the task be undertaken sequentially, thus tying up the machine until completion of the long operation.
Another background task is on-line equalizing, a function that depends on the mode of operation. In a mode concerned with elements, attributes concerning elements will be posted very shortly after their occurrence. In this illustration the user is informed that a surface change has affected eleven other elements. Since this is neither a conflict nor a warning, the message is displayed, but the bell is not rung.
Some elements never receive implicit qualities because of their position.
Output procedures are specific, long operations that take unusually large amounts of computer time due to the slowness of many output devices, such as plotters, printers, card punches, and the like. A complex drawing can take three minutes to plot and is accordingly ascribed a low priority. For example, when URBAN5 is plotting a site plan in the background and the designer interrupts it, the machine stops drawing and tends to the foreground command. After answering the designer, if his command has meanwhile generated a new long operation of higher priority than plotting, URBAN5 starts the new job. Only after it finishes does the machine return to the previously started site plan.
Housekeeping chores are in the nature of a physical checkup. Leftover memory, messy files, and disorderly data structures are cleaned up. As background work, housekeeping procedures are of low priority until untidiness becomes an ailment that warrants full attention. Finally, if the house is tidy, the machine can play.
Playing is learning, but URBAN5 has not been sufficiently sophisticated actually to frolic; instead it has inexhaustably printed garbage.
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
