7.1.    External Media for Design

Expert systems—which incorporate domain knowledge in a set of explicit computational rules and infer solutions to problems in the domain automatically from these rules—do not represent the only approach developed in AI. There have always been some researchers who sought ways to use technology to augment human problem solving (e.g., Bush, 1945; Engelbart, 1963), rather than to model, simulate, or replace it. The characteristics of design found in the studies of lunar habitat design suggest that computer systems for innovative design in such exploratory domains should be structured to capture evolving design rationale and other design knowledge during actual design processes. That is, at critical moments during design work the understanding which is normally tacit takes on some form of explicit expression, permitting it to be captured in external media or computer representations for future use. Computer systems that take advantage of this can support human designers, rather than trying to automate design on the basis of heuristics and knowledge representations formulated in advance. The idea is to keep the human designers in control, but to extend their ability to reuse knowledge gained in past design work (by themselves or by others).

There are two difficult aspects to this approach: (1) how to capture knowledge (i.e., design concepts, terminological refinements, critiquing rules) without imposing inappropriate representations and without requiring excessive effort, and (2) how to retrieve and present to the designers knowledge that has been stored but that is now timely and relevant. Issues of design capture and retrieval have been addressed by design environments. Phidias and Janus are prototypical design environments, both originally developed using the sample domain of the layout of kitchen floor plans. They address knowledge capture by proposing a process of seeding, evolutionary growth, and reseeding of the knowledge base. They address timely knowledge retrieval by the use of triggers and critics. These systems will be discussed in this section.

The Phidias design environment. Phidias[1] combines a hypertext issue-based information system with a CAD-style construction kit. The issue-base contains issues that are important for designing in the domain, along with possible answers to the issues and arguments supporting those answers. The issue-base is motivated by Rittel's view of design as an argumentative process (see Section 2.2). Designers can add their own answers and arguments, which can contradict alternatives already in the issue-base. The graphical construction kit facilitates the designer in constructing a solution to the task at hand. It provides an external representation of the design concept with which the designer can enter into dialogue.

The integration of graphical construction with this textual deliberation is seen by the developers of Phidias (and Janus) as a way of operationalizing Schön's theory of reflection-in-action or breakdown-and-repair, in which designers construct, observe, reflect, and respond (see Section 2.3). Phidias embodies knowledge of its domain in the hierarchy of information in the issue-base and in the palette of design items for the construction. Relevant knowledge is displayed through a trigger mechanism, which presents issues related to what palette item to select and where to place it. The designer can trigger this information by clicking on a button during the selection of a palette item. The designer is free to navigate through the hypertext from these displays to explore related issues. The trigger mechanism provides the designer easy access directly to the knowledge in the issue-base that is most relevant to the current decision of what to place where.

A simple query language is also available for displaying information from the issue-base. The query language—which is Phidias’ most important contribution to the problem of tacit and explicit understanding—will be discussed in Section 7.3 below.

The Janus design environment. Janus[2] takes a similar approach, with significant differences in the details and implementation. Knowledge about kitchen design is encoded in the various components of Janus' multi-faceted architecture (see Figure 7-1): A palette of kitchen appliances provides a kit of parts for a graphical construction of a layout.

Figure 7-1. The multi-faceted architecture of Janus.

The major components of the system (shown in ellipses) each use a different data representation. Other components (shown in rectangles) are used to bridge between these representations. Designers alternate between problem framing (altering the partial specification) and problem solving (altering the graphic construction).

Sets of critics embody rules of thumb about the placement of these appliances—such as that the stove should be near but not next to the refrigerator—and domain distinctions provide a vocabulary for expressing these rules. A specification checklist prioritizes client concerns, like whether the kitchen should be child-proof. An argumentation issue-base contains discussions of rationale for kitchen design, including deliberation related to the critic rules. There is also a catalog of past kitchen designs, which can be used as starting points for new designs or illustrations of abstract rules.

A number of additional components in Janus are used to link the major components together, translating the data representations used in one component to those in the other. For instance, the Catalog Explorer prioritizes items in the catalog according to the decisions made in the specification, and the Argumentation Illustrator displays catalog items that relate to a given topic in the argumentation.

Perhaps the most powerful computation in the system is carried out by the Construction Analyzer, which critiques the construction using a set of critic rules. These rules can be modified by decisions in the specification as well. For instance, if there is a stove and a refrigerator in the construction, then their distance apart is calculated and used in rules about minimum and maximum distances. The critics “fire” automatically when one of their rules is violated by the placement of items in the construction. If the construction does not meet the critic rules, a message is displayed alerting the designer to a possible problem. The designer can then view the relevant section of the issue-base. Like the triggers of Phidias, the critics of Janus present knowledge from the issue-base that is most relevant to what is taking place in the design construction, but now as analyzed actively by the system.

Despite the progress that systems like Janus represent in meeting the needs of designers, they still fall short of supporting interpretation. Consider the forms of knowledge in such a system. The paradigm is still that the programmer who built the system obtains pieces of knowledge from books and from domain experts, and enters it all in the system. Users benefit from being guided by the knowledgeable system (e.g., the critic rules). When designers want to, they can also explore the rationale for critic rules and defined characteristics of the standard appliances. But the bulk of the knowledge exists independently of the personal concerns of the user or the specifics of the task at hand.

Recently, an "end-user modification" component was created for Janus (Fischer & Girgensohn, 1990). This allows users to add new appliances (e.g., when microwave ovens become popular they can be added to the palette) and to modify existing definitions and critic rules. However, this is not intended as a mechanism for continual redesigning of components under alternative interpretations: it does not support multiple simultaneous definitions for different users or different interpretations. Nor does it provide a medium for designers to articulate and explore innovative interpretive perspectives. The ideal of support for an evolving knowledge base requires the ability to partition the knowledge base for alternative modifications, but Janus provides only a homogeneous knowledge base.

The reliance on standardized components and non-controversial rules of thumb in Janus may work in the realm of kitchen design because this domain is, in fact, well-defined and well-understood. Stoves, sinks, and cabinets come in standard sizes and raise few issues for the designer. By ignoring broader issues of aesthetics, sociability, and architectural interactions with the rest of the building, Janus is free to concentrate on rules that are independent of the interpretive perspectives of designers or their clients. For instance, the implemented critics have to do with distances between appliances, the size of the work triangle, the placement of the sink under a window, or the separation of the stove from the refrigerator. However, this approach needs to be extended for domains like lunar habitat design that are less well understood and less "tame".

Janus and Phidias are still like expert systems in their reliance on encoding domain knowledge in representation systems that are fixed in advance at the level of domain representations. They go beyond expert systems in two significant ways: (1) they recognize that most interesting design tasks cannot and should not be automated so they provide user-centered support systems, and (2) they recognize that domain knowledge evolves so they provide user-extensible systems. However, if one wants to have a design environment that, for instance, recognizes different people's definitions of privacy—and helps users explicate and share these definitions—and critiques designs using these multiple definitions, then one must extend the domain-orientation of Phidias and Janus to allow divergent interpretive perspectives, as discussed below in Section 7.2.

In a sense, the idea of a design environment is to open up an environment, or to disclose a world in which designs can come to be. In other words, a design environment provides a software model of the design situation, in Heidegger’s sense (see Section 4.1). The modeled situation includes the developing design of the artifact (modeled by graphical figures), rules of thumb (modeled by critic rules), the designer’s concerns (issues in the issue-base), design goals (specifications), domain concepts (issue-base distinctions), available parts for the design (palette), and past experience (the catalog of prior designs).

The theory of human problem-domain communication underlying the Janus system corresponds roughly to Heidegger’s insistence on the tacit nature of the understanding of the situation that is modeled. According to Fischer, et al. (1989),

To shape the computer into a truly usable and useful tool, users must be able to work directly on their problems and tasks. The goal of human problem-domain communication is to eliminate computer-specific programming languages and instead to build layers of abstraction with which domain specialists—such as kitchen designers—can feel comfortable. Human problem-domain communication provides a new level of quality in human-computer communication because the important abstract operations are built directly into the computing environment. (p.5 f)

The idea is to replace (for the users) general purpose computer programming languages with domain-specific media that represent or model elements of the problem-domain situation. Then kitchen designers can communicate their ideas about kitchen appliances in terms of tacitly comprehended representations of these appliances (e.g., icons of stoves and refrigerators) rather than by means of abstract and explicit statements in an abstract language like Lisp.

In order to turn the computer system into an “invisible instrument” that can be used tacitly in this way, Fischer (1989) calls for a layered architecture in which the “transformation distance” between the problem domain (e.g., kitchen layout) and the underlying system (e.g., Lisp) is in effect reduced for the designer by building intermediate layers of abstraction (i.e., the design environment).

Figure 7-2. A layered architecture

The design environment provides a layer of abstraction between the problem domain and the implementation language, reducing the transformation distance-1 for the designer to transformation distance-2. From (Fischer, 1989, p.15).

The existence of a series of intermediate layers supports end-user modifiability because if a modification is needed at one layer it can probably be made at the next lower level, without requiring the designer to descend to (and understand) the lowest level of implementation. For instance, if there is no microwave in the palette of the Kitchen Design Environment, then procedures in the Architectural Design Environment (Modifier) allow a microwave to be defined.

Fischer, et al. (1989) argue convincingly that it is important to relieve designers of the burden of “mastering the many details inherent in general purpose programming languages” (p.6). Designers have enough to keep in mind without learning and applying the complex knowledge required by sophisticated programming languages. However, the question is whether the palette of icons offered by Janus has sufficient expressiveness for creative, professional, innovative design. Even with its end-user modification component, there is only limited plasticity in Janus’ representations. Ironically, use of the modification component itself requires at least some knowledge of Lisp. The question of how to provide adequate expressivity without overwhelming the design task with extraneous programming tasks will be taken up in Section 7.3.

One way to think about this problem is to ask whether Janus has gone far enough with the layered architecture. There are two major gaps in Figure 7-2. Transformation distance-2 is certainly smaller than the original transformation distance-1, but it may be possible to build additional intermediate levels to further reduce the average effective transformation. Also, transformation distance-3 could be filled in to relieve at least two kinds of problems: (i) the difficulty for system developers of building new components and (ii) the fact that end-users of Modifier are often forced to use Lisp to define modifications. Hermes will address these gaps by introducing new layers in both of these areas. The perspectives mechanism allows designers to build their own hierarchies of layers of knowledge between their specific task and the design environment, filling in transformation distance-2 with arbitrarily many levels. The Hermes substrate fills transformation distance-3, providing high-level functionality for system developers to use in building new components and providing a language for designers to use in making their modifications (see Part III).

Design environment support for interpretation. A final question must be raised during this look at the computationally active media that Phidias and Janus propose for supporting design. To what extent do they support the designers’ interpretative processes?

The developers of Phidias and Janus justify their systems by appeal to Schön’s description of design and the process of breakdown. They are anxious to operationalize this theory in system mechanisms. In order to operationalize the analysis of breakdown, they construe it as breakdowns in action, rather than the underlying breakdown in situated understanding. For instance, McCall, et al. (1990a) write:

Reflection-in-action takes place when action breaks down. There are at least two major types of breakdowns. One is when the designer’s action results in unanticipated consequences—either good or bad. The second is when the designer is stuck and simply does not know how to act or which action to take. To apply Schön’s theory to environmental design we operationalized his concepts by dividing design into construction and argumentation. . . . To support reflection-in-action, the section of the issue-base relevant to a particular construction task must not be brought to the designer’s attention in such a way as to interfere with construction. There are two ways this can be accomplished: by allowing immediate retrieval of this section of the issue-base when construction produces surprising side-effects or by allowing such retrieval when the designer is deciding how to act. The former strategy is used by Janus; the latter by Phidias. (p. 156f; italics added)

In operationalizing Schön’s concepts of knowing-in-action and reflection-in-action, the developers of Janus and Phidias have squeezed out much of the interpretive content. Interpretation—the basis for innovative design—has been reduced primarily to a choice among pre-interpreted actions. Rather than supporting interpretation, these systems propose alternative actions.

The innovative interpretive tasks have been replaced by choices among limited actions listed in an issue base. Of course, it is necessary to drastically limit the set of palette icons and their possible locations in order to make it feasible to supply a manageable list of answers for their selection or a computationally tractable set of rules for critiquing them. But this restricts design to the level of routine design. It allows for more flexibility than automated expert systems because human designers are “kept in the loop” to make the choices among alternative actions and because new actions can occasionally be added to the system. However, this approach to operationalizing Schön’s theory does not fully support interpretation or the repair of breakdowns of interpretations.

The triggers of Phidias do provide partial support of interpretation in the sense that the issue base that is displayed can include alternative options and rationale for them. A designer can explore this rationale and use it to revise his or her understanding of the design situation. Phidias even allows the designer to add new options that arise in this deliberation. The shortcoming of this approach is that it takes little advantage of the computational power of the computer system. It goes beyond a paper system only in the indexing of information for display and linking of it for browsing.

Janus adds the power of computational critics. Fischer & Nakakoji (1991) point to Schön (1983) as the major theoretical influence behind their use of critics, but then claim to “move beyond Schön’s work”:

Schön’s framework is based on the cycle of ‘seeing-drawing-seeing’. However, Schön’s notion of seeing is ‘not good enough’; as Rittel pointed out, ‘buildings do not speak for themselves’. Non-expert designers (and this is what designers are, in almost all realistic situations) do not have the complete knowledge and experience to understand fully the conversation with the materials of the situation. Critiquing mechanisms serve as ‘interpreters’ that support designers in seeing and understanding the ‘back talk’ of the situation. When a critic fires, reflection does not occur on the simple basis of the message. Designers ‘listen to’ the design material with the help of the interpreter in the form of a critic (p.27; italics added).

 In what sense do the critics serve as interpreters? A critic may act as a reminder to focus one’s seeing, but scarcely as an insightful interpreter. The only sense in which a critic provides an interpretation of the design situation, is that it provides the abstract, decontextualized interpretation of whoever programmed the critic rule. This is someone else’s interpretation, far removed from the designer’s situation. The programmer may have been considerably less expert than many users in terms of domain knowledge, having expertise in the area of programming. Like a knowledge engineer for expert systems, the programmer may have relied on generally accepted rules. These rules were then “interpreted” by the programmer in the sense of being expressed in a formalism that Janus could execute. They were not interpreted within the context of a concrete design situation because they have to apply to all designs.

The Modifier (Girgensohn, 1992) and Kid (Nakakoji, 1993) versions of Janus move further toward supporting interpretation. Modifier allows a designer to modify critic rules and other domain knowledge. However, this feature is intended more to support changes in the domain (e.g., the invention of new appliances) or in generally accepted domain knowledge (e.g., new rules of thumb or building codes), than to support tailoring knowledge to an individual designer, a particular design case, or a technical viewpoint. In addition to selecting critic rules based on the selection of design units that are placed in the construction area, Kid selects rules based on a series of specification questions that the designer answers for a specific design project. Kid derives “specific rules” by adapting the generic critic rules to the choice of specification answers. In these ways, the system of critics is tied to the specifics of the construction, the specification, and the evolving knowledge base. Furthermore, the critics merely display information which the designer can reflect upon; they leave the decision to the designer.

Triggers and critics have been shown to be useful, even powerful mechanisms for design environments. Janus and Phidias have recognized the need to support the repair of breakdowns in designing. However, their mechanisms fall short of offering the necessary support of interpretation. Nor is it a matter of scaling up the prototypes, for their approach to operationalizing the concept of breakdown is itself the problem. The representations proposed are simply not expressive enough to model the situations, perspectives, and languages of designers in order to support their interpretations in more than a partial way. Mechanisms for customizing domain knowledge to the situations of individual designers and teams are called for (such as the perspectives discussed in Section 7.2). Also, more expressive knowledge representation systems are needed (such as the languages in Section 7.3). As shown in Section 10.3, Hermes extends the trigger and critic mechanisms with its perspectives mechanism and end-user language to provide interpretive critics. These more fully support the capture, reuse, and modification of critic rules.

Go to top of this page

Return to Gerry Stahl's Home Page

Send email to Gerry.Stahl@drexel.edu

This page last modified on January 05, 2004