VISUAL CRITIQUING IN DOMAIN ORIENTED DESIGN ENVIRONMENTS: SHOWING THE RIGHT THING AT THE RIGHT PLACE M. STOLZE Department of Computer Science University of Colorado at Boulder Boulder, CO 80309-0430
[email protected]
Abstract. Traditionally critiquing messages in Domain Oriented Design Environments are presented as text in a window to which all critics send their message. In this paper alternative methods for presenting critiquing messages in a direct manipulation style will be discussed. Critics which change the shape of the cursor, indicate relations of objects, change the visible properties of the objects, modify the contents of the evaluation window and the agenda, and let users manipulate their designs from alternative perspectives will be presented in the context of the PetriNED design environment. It will be argued that the challenge for critics using direct manipulation style critique delivery is not –as for critics following the traditional way of presenting messages– to “say the right thing at the right time” but to “show the right thing at the right place”, and that the latter challenge is not as big as the former and allows for a much better support of design tasks.
1. Introduction: Critiquing in Domain Oriented Design Environments Domain Oriented Design Environments have been proposed as an architecture for systems supporting a wide range of design activities like architectural design, computer network design or user interface design. These environments typically supply users with a direct manipulation construction construction kit as well as other modules like, for example, a catalog of previously successful designs and an argumentative hypertext module to record and retrieve design rational information (Fischer, Lemke et al., 1991). A central module of Domain Oriented Design Environments is the critiquing component. It helps users to detect problems in their designs by indicating how well the design conforms with general design goals as well as specific goals specified by the user (Fischer, Nakakoji et al., 1993). There is a growing consensus that critiquing mechanisms present a promising way of using knowledge based techniques to support non-routine design tasks (Fischer, Lemke et al., 1991; Silverman & Mezher, 1992) and that the main challenge for these critiquing mechanisms is to “say the right thing at the right time”.
2
M. Stolze
1.1. THE TRADITIONAL CRITIQUING CHALLENGE: SAYING THE RIGHT THING AT THE RIGHT TIME
The critiquing component of Domain Oriented Design Environments can be envisioned as consisting of a collection of individual “critics” (or “critiquing agents”) which monitor the user’s construction activities and check whether the evolving design complies with the design goals they are in charge of. When violations are detected, the critics have to notify the user. Traditionally critics do this by presenting their critiques as a text in a specific message window which is used by all critics to deliver their messages. Users are assumed to read these messages and to take action to remedy the identified problem. However, this way of critiquing is rather intrusive as users have to interrupt their current activity, shift their focus of attention to the message window, and consciously read and understand each of the critiquing messages. Users can, of course, ignore the current messages and continue their work without looking at the message window, but this can be problematic too, as they might continue their work in an unproductive direction without noticing it. To keep users interested in the contents of the message window, care has to be taken that critics do not interrupt users too often in their primary design task. Therefore, if a design problem is detected, critics have to “decide” whether their message is relevant enough to notify the user immediately or whether the observed problem is likely to be only temporary and no immediate critiquing is needed. The latter might be the case if the user is in the middle of a task that involves some problematic transitory states. For example, an architectural design rule might state that rooms should not have less than a certain amount of window space. But when should a user be notified that the design does not satisfy this rule? Some users might choose to defer window placement until very late in the design process. Interrupting and reminding the user after each step that there is still not enough window space is obviously not a workable solution. Different methods have been proposed to tackle the problem described above, that is, the problem to “say the right thing at the right time”. Fischer, Nakakoji et al. (1993) propose to increase the “shared context” of users and critics. The idea is that the more the critics “know” about the user’s current task-context, the better they can determine the relevance of their message to the user’s current task. In addition to this, it is proposed to make critics enduser modifiable so that users can tailor critics to their own working style. Another possibility is to use “passive” instead of “active” critics (Fischer, Lemke et al., 1985). Whereas active critics deliver their critiques whenever they detect a problem, passive critics have to be started explicitly by the user. Some spelling checkers, for example, are able to work in both
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
3
modes. They can be configurated to notify users whenever a word gets misspelled (active mode), and they can also be started explicitly to check a whole document. While passive critics do not distract users from their primary design task, they can be problematic if users fail to start them early enough and walk down a garden path investing considerable effort and time into a design which will finally have to be abandoned. Whether to use active or passive critics cannot be decided in general. Instead, the specific properties of the application have to be considered. Letting the user control whether critics should be active or passive is another option. To make critics say “the right thing at the right time”, Silverman & Mezher (1992) propose to equip systems with a dialog generator module. As in tutoring systems, this module would use user-models to tailor the critics’ messages to user needs. For Silverman a set of switches to control the critics would be an example of such a user model. 1.2. THE CHALLENGE OF VISUAL CRITIQUING: SHOWING THE RIGHT THING AT THE RIGHT PLACE
The above mentioned authors see the problem of “saying the right thing at the right time” as the central problem of critiquing mechanisms in design environments. However, this framing of the problem is strongly influenced by the way critics are currently presenting their messages to the user. The problem of finding the right time for presenting information mainly results from the fact that critics write their messages sequentially in a single separate message window which the user has to consult every time a new message appears. This used to be the standard way of presenting information in early terminal oriented programs. This method has been transcended by direct manipulation interfaces which support spatial and dynamic presentation of text and graphics (Hutchins, Hollan et al., 1985). However, current critiquing mechanisms do not take advantage of the potential of alternative ways for presenting design critiques. Presenting all the critiquing messages sequentially in one separate text window unnecessarily emphasizes the sequential aspects of critiquing and thereby “causes” the problem of correct timing. If direct manipulation style methods are used for presenting critiques to the user, the question of the “right time” gets less important, and instead “showing the right thing at the right place” becomes the central question. This transformation of the question is advantageous because finding the right place is often easier that determining the right time. When arranging critiques in time it can only be decided whether a critique should be displayed now, some time later, or not at all. The “intrusiveness” of critiques cannot be controlled as they are displayed uniformly in the message window and the user is supposed to look at all of them.
4
M. Stolze
Instead, if critiques are arranged in space, multiple critiques can be displayed in parallel and they can either be placed within, close to, or outside the user’s current visual focus of attention (i.e. the cursor position); or they might even be placed in a currently invisible part of the interface. This way the critiques can be made more or less intrusive according to their relevance to the current task. Also, graphics instead of text can be used for presenting critiques, and these might also be displayed only temporarily. In the following I will refer to critiquing methods which use the direct manipulation style to deliver their critiques as “visual critiquing”. Visual critics can, for example, change the shape of the cursor, they can annotate elements of the constructed design, or they can post their critiques to an “agenda” which is displayed outside the user’s current focus of attention. These and other methods will be discussed in more detail in the next section in the context of the PetriNED design environment. Depending on the time needed to compute their critiques, visual critics can deliver their messages already while users are performing their actions, directly after user actions, or with a delay after the action. I will call these three modes of critiquing “early critiquing”, “immediate critiquing” and “delayed critiquing”. Early critiquing helps users to anticipate the results of their actions. Early critics will deliver their critiques at the user’s current focus of attention and they indicate in advance potential positive or negative results of the user’s current action. Immediate critics compute and deliver their critiques directly after the user has performed an action. Often immediate critics will display their messages close to the user’s focus of attention. The computation of delayed critiques takes so much time that users cannot wait for the result before starting their next action. Delayed critics will typically post their critiques to “agendas” outside the user’s focus of attention. 2. Critiquing in the PetriNED Domain Oriented Design Environment PetriNED (Petri Net EDitor) is a design environment supporting the design of Petri nets. Petri nets are traditionally used for the design of communication protocols, multi-processor systems, and other operating system oriented applications (Murata, 1989), but they have also been used in the context of decision making (Tabak & Levis, 1985), neural networks (Stoica & Roth, 1986), hypertext systems (Stotts & Furuta, 1989), and human-computer interface design (Bastide & Palanque, 1990). PetriNED is implemented in Macintosh Common Lisp and runs under Mac System 7. It consists of four windows: a construction window (Figure 1), an analysis window (Figure 2, right), a property window (Figure 3, left), and an incidence matrix window (Figure 3, right).
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
5
Palette
Tool Bar Move Operation Connect Operation
Nr. of Tokens
Construction Area
Fig. 1. The PetriNED Construction Window. Gray rounded rectangles are not part of the interface but are annotations of elements in the figure. Screen shots of two different user actions are merged in the figure (“Move Operation” and “Connect Operation”). In the construction window users can select prototypes of places, transitions and trash cans from the palette and move them to the construction area. Once the objects have been placed in the construction area, properties like their name or the number of tokens of places can be changed directly on the object. Also objects can be moved around with the arrow tool, they can be connected with the connect tool, and transitions can be fired for simulation purposes with the firing tool.
6
M. Stolze
Connect Operation
Corrected Connections
Currently Displayed Situation
Wrong Connections
Fig. 2. The PetriNED Construction and the Analysis Window. Screen shots of two different user actions are merged in the figure. The Analysis Window displays a list of possible deadlock and unbound sequences of the currently constructed net. That is, all sequences of transition-firings in which the net gets stuck because no transition can fire any more and the sequences in which places potentially accumulate infinite numbers of tokens. Each sequence is represented in the list by a token indicating its type (deadlock or unbound) and the number of individual situations in the sequence. If the user selects one of the sequences in the list, the last situation of the sequence (i.e. its configuration of tokens in the net) is displayed directly in the construction area. The user can then use the scroll-bar in the lower part of the window to see the other situations in the sequence. As determining deadlocks and unbound sequences is computationally expensive, the list gets computed incrementally and in parallel while the user is constructing the net. The content of the Analysis Window refers to the situation after the “connect operation” has been completed. The configuration of tokens in the net is the result of the second user action in which the sequence “Unbound(7,4)” is selected in the analysis window and the last situation of the sequence is displayed in the construction area.
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
7
Left Column: Connections from Transitions to Places
Right Column: Connections from Places to Transitions Problematic Columns
Fig. 3. The PetriNED Properties and the Incidence Matrix Window. The Properties window (left) displays some easy computable properties of the net under construction. The Incidence Matrix window always shows the incidence matrix of the net under construction. The incidence matrix is an alternative, diagrammatic representation of the Petri net. Columns represent incoming and outgoing connections from and to places and rows represent the transitions these connections are either coming from or going to. The labels of the rows and columns are abbreviations generated from the names of the elements in the construction area. The matrix is not only an alternative visualization of the net; the user can also change, enter and delete connections directly in the matrix and these changes are then propagated to the construction window.
2.1. A PETRINED USE SCENARIO INCLUDING VISUAL CRITIQUING In the scenario the user wants to construct a simplified Petri net model of a communication protocol (Murata, 1989). The user starts constructing the model by moving places from the palette into the construction area and changing their name afterwards. Figure 1 shows the situation after all places have been entered. Next, the user starts moving places to align them with others. When the user is moving the outline of the place “P1 Buffer Full” close to a position that is directly above the place “P2 Buffer Full” and in a 45 degree angle to the place “Ready to Rec”, two “alignment critics” are activated. The critics notify the user of this relation by drawing lines between the involved objects (Figure 1, “Move Operation”). If the user moved the outline out of a certain range, the lines would disappear again. But the user decides to let the place drop and thus to make it aligned to the other places. Next the user selects the connect tool and tries to connect the place “Ready to Send” with the place “Wait for Ack” (Figure 1, “Connect Operation”). However, this connection is not possible, as in Petri nets places
8
M. Stolze
can only be connected to transitions and vice versa. When the user tries to connect the two places, the second place –as an implicit critique– does not respond to the rubber-band cursor as it would usually do if the connection came from a transition. This makes the user aware of the fact that first transitions have to be introduced before connections can be made. Only if the user still tried to make the connection by releasing the mouse button while having the rubber-band cursor positioned over the second place, an explicit critiquing message would pop up saying that places can only be connected to transitions and vice versa. In the next step the user drags the transitions from the palette to the appropriate positions in the construction area, changes their names, and connects them as shown in Figure 2. However, instead of connecting the place “Ack. Received” with the transition “Process 1” and that transition with the place “Ready to Send”, these connections were erroneously made the other way round. The user gets suspicious of the problem when the analysis window detects unbound and deadlock sequences and the property window shows that the maximum number of outgoing connections for places is not one, as expected, but two (Figure 3, right). When looking at the incidence matrix (Figure 3, left) the user finds that contrary to all other places the place “Ready to Send” only has outgoing connections and the place “Ack. Received” has only incoming connections. Thus the user decides that the connections from and to “Process 1” need to be changed. While it would have been possible to change this directly in the matrix, the user decides to do this with the connection tool in the construction area. In Figure 2 the user has already corrected the connection between “Ack. Received” and “Process 1”, and currently the connection between “Process 1” is about to be made (Figure 2, “Connect Operation”). The place “Ready to Send” has responded to the rubber-band cursor by inverting to its outline, but while usually the tip of the rubber-band cursor has the form of a cross, it has now turned into a little gray circle. This is caused by a critic watching whether the user is about to make a circular connection. The user notices this, but nevertheless goes ahead creating the connection as the circularity is intended. But certainly knowledge about circularities can be helpful in other situations to avoid potential mistakes. After correcting these connections the user consults the analysis window and sees that deadlock and unbound sequences still get detected. The user selects one of the unbound sequences (Figure 2, right). When scrolling through the sequence, the user sees that the reason for the problem is that also the connections from and to “P2 Buffer Full” are made the wrong way round. After this problem has been eliminated the model is finally correct.
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
9
2.2. MECHANISMS FOR VISUAL CRITIQUING In the scenario different ways for critics to deliver their critiques were presented in the context of a design task. Critics changed the shape of the cursor, they indicated relations of objects in the construction area, they changed the visible properties of the objects in the construction area, they modified the contents of the evaluation window and the agenda, and they made it possible for users to see and manipulate their designs from alternative perspectives (Table 1). Below I will discuss in more detail each of the visual critiquing methods. TABLE 1. Applicability of Visual Critiquing Methods
Early Critiquing
Immediate Critiquing
Delayed Critiquing
Change Cursor
✔
¬
¬
Indication of Relations
✔
❬✔❭
¬
Change Visible Properties
✔
✔
❬✔❭
Posting to an Agenda
¬
✔
✔
Interactive Representation
¬
✔
✔
Changing the cursor shape. In the scenario the critic watching whether the user was about to make a cyclic connection changed the tip of the rubberband cursor from a cross to small a circle. This is an example of an early critic, as users get informed of the potential consequences of making connections already before connections are actually made. Having the circularity critic as an early critic can be problematic in large nets because the time to determine circularities can be too long and delay the updating of cursor positions and cursor shapes in an unacceptable way. However, critics changing the cursor need to be early critics, as changing the cursor after an action has already taken place does not make sense. An alternative method for the circularity critic to deliver its critique will be discussed below. Indicating Relations of Objects in the Construction Area. In the scenario the “alignment critics” are examples of early critics which deliver their critiques by indicating relations of objects. The interesting property of these critics is that they are delivering “positive critiques” (i.e. detect positive properties of the design) and actively support users in establishing these positive properties. The user only needs to be in a certain range of the place where these relations hold, and the critics make sure that the indicated relations will be established if the user decides to do the action. In the scenario
10
M. Stolze
the established alignment relations do not remain visible after the move operation has been finished. In some applications it might, however, be useful to leave the established relations visible (Gross 1992). If relations remain visible also immediate critics can make use of this critiquing method. Changing the visible properties of the objects in the construction area. In the scenario the critic watching that places only get connected to transitions and transitions only to places is an example of an early critic delivering its critique by changing the visible properties of the objects in the construction area. Only if users attempt to make the right kind of connections will the target object be inverted to an outline. The critique concerning incorrect connections is initially only implicit, as in this case objects do not get inverted if the rubber-band cursor is positioned over them. As implicit critiques can be problematic on their own, an explicit message is shown if the user still tries to make the connection. What makes this critic different from other critics is that it actively keeps users from improper making connections. This is the standard way of controlling interaction in direct manipulation interfaces which can be problematic in design environments. In our scenario it makes sense to constrain user actions, because the critic’s rule is a “hard” design rule every net must conform to. Often, however, design rules will be “soft” and it must be allowed to perform actions which contradict some of the rules. There is an example of an immediate critic which changes the visible properties of the objects in the PetriNED environment, but it was not discussed explicitly in the scenario. This critic determines for each transition whether it is enabled (i.e. ready to fire) or not. If a transition is enabled, it is shown as a dark square, and the color of disabled transitions is changed to gray. As this critic is an immediate critic, the color of transitions affected by a user action does change only after the action has been performed. As illustrated in the two examples above, critics which change visible object properties can be early or immediate critics and, in principle, even delayed critics. For large nets the circularity critic discussed above should be implemented as an immediate critic to avoid delays in cursor updates during actions. As such it could for example color the cyclic connections . Modifying the Contents of the Evaluation Window and the Analysis Window. In the scenario the critic updating the evaluation window was an immediate critic and the critics in charge of the agenda were delayed critics. The critiques are displayed in another window outside the user’s focus of attention because they can be affected by transitory problematic states of the design and because they contain information which is too complex to be monitored without conscious attention. In the case of the analysis window the user can click on the tokens in the list and scroll through the sequence to receive an “interactive, visual explanation” of the critiques.
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
11
By placing the critiques in another window users are saved from being interrupted in the middle of a design step. Users can look at these windows after finishing a sequence of design actions in one of the other windows. Another reason for displaying the information in the analysis window outside the user’s focus of attention was that the critiques are generated by a delayed critic. Thus these critiques may not be directly related to the user’s current action. Displaying them too close to the user’s current focus of attention might be confusing, as he or she might infer wrongly that the critique is referring to the current action. In the case of the analysis window users can use their peripheral vision to monitor the dynamic detection of deadlock and unbound conditions in the window. If they are surprised by the fact that problems are detected in a certain situation, they can focus their attention on the analysis window and start exploring the detected problems. Finding the right place can become challenging if conflicting placement criteria exist. The critiques displayed in the Analysis Window are a point in case. While the objects the critiques are referring to are located in the construction area, the critiques cannot be displayed close to these objects. This would be too intrusive and the visual critiques would also clutter the construction. The solution was to display the critiques as tokens in the analysis window outside the user’s focus of attention and only display the full visual critique when the token is selected by the user. This way the cluttering of screen is avoided, the critiques are displayed at the right level of intrusiveness, and the connection to the objects the critique is referring to is maintained. Posting critiques to an agenda like the Analysis Window can also help in situations in which the design is too large to have all design elements displayed at the same time. Instead of annotating the invisible design elements without the user knowing about it, tokens of the critiques can be posted to an agenda where they become visible immediately. If the user selects these tokens, the design elements can be made visible and the visual critique can be displayed. Posting critiques about invisible elements to an agenda is not necessary if the design is hierarchicaly organized. In this case the existence of a critique related to a currently invisible element low down in the hierarchy can be indicated by annotating a visible, higher level element. Supply Users with Multiple Interactive Representations of the Design. Alternative “interactive representations” let users see and manipulate their designs from alternative perspectives. They can be interpreted as elaborated design critiques. In the scenario the interactive incidence matrix representation of the evolving Petri net offers users an alternative perspective on their design. The interesting property of the incidence matrix is that it is not only an alternative visualization of some properties of the net (as the evaluation
12
M. Stolze
window and the agenda), but that it also allows the user to change the visualized properties directly in the interactive representation. 3. Discussion Generally when new ideas or methods are presented, three camps of people have to be convinced (1) those believing that it is not possible at all (2) those believing that it is not necessary to use the method, and (3) those believing that this is what they have been doing all the time already anyway. Although it is only a modest prototype, the PetriNED environment presented above should be enough evidence to convince people from the first camp that visual critiquing is possible. Below I will try to convince people in the two other camps and argue that it is advantageous to use the proposed critiquing methods in design environments and that the proposed methods for critique presentation transcend the currently used methods. 3.1. USING VISUAL CRITIQUING IS ADVANTAGEOUS. Visual critiquing uses a larger-bandwidth, more flexible channel for critique signaling than purely text-based critique presentation methods. As a result, the question of “saying the right thing at the right time” becomes much less important, and system designers mainly have to worry about “showing the right thing at the right place”. This is advantageous because a fine-grained control of the intrusiveness of critiques is possible by changing the placement and the delivery method. Usually critiques delivered at the user’s current focus of attention will be more intrusive than others. However, not only the placement but also the mode that is used for delivering critiques determines their intrusiveness. Textual messages are highly intrusive because they require the conscious attention and explicit understanding on the part of the user. Non-textual delivery of critiques is usually less intrusive as long as the user understands the meaning of the delivered critiques. Changing the shape of the cursor and modifying the appearance of the objects is in some way very intrusive because this happens at the user’s focus of attention, but on the other hand it is less intrusive than presenting a long text because the effort needed for understanding the non-textual critique is relatively low. In PetriNED methods for integrating textual and non-textual delivery of critiques were explored. Users are notified unintrusively through non-responding of places or transitions that connections between elements of the same type are not possible. Only if users try to force connections, a textual message will inform the user explicitly –and intrusively– that such connections are not possible. Visual critiquing extends the palette of possibilities de-
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
13
velopers of critiquing mechanisms can choose from for presenting their critiques. The traditional, text-oriented way for presenting critiques becomes only one possibility among others. Which methods are the best and where critiques should ideally be placed cannot be decided independently from an application, but the PetriNED environment has exemplified a number of situations in which alternative critique presentation methods are advantageous. Another indication of the advantage of visual critiquing mechanisms is the fact that they have been used – though only in a few cases up till now– in commercial products. For example, programming environments like Think Pascal will do a partial syntax check of the preceding statement each time you type ";" and will reprint the statement in a funny font if an error is found. Drawing tools like Canvas include visual “alignment critics”. Finally, document editors like Word supply users with multiple, interactive document representations. Users can, for example, switch seamlessly between editing their document in the “Outline View” and the “Page View”. 3.2. VISUAL CRITIQUING TRANSCENDS CURRENT METHODS. An obvious critique of the approach presented in this paper is that it only proposes an alternative presentation of critiques and that this is only “syntactic sugar” and “nice to have” but does not add to the understanding of critiquing mechanisms. The underlying assumption of this critique is that “form follows function” and that the important part about critics is their function, that is, the knowledge representations and inference mechanisms they are using for computing their critiques. In this view the way the critiques are presented is secondary and only needs to be addressed once the functionality has been determined. However, this function centered way of system development is problematic (Stolze, 1994). An example from the PetriNED design environment shows why this is the case. Usually it is assumed that users do not care much about positive critiques and that critics should focus on determining problematic properties of the design. However, this is only true if the traditional text-oriented (i.e. intrusive) way of presenting critiques is used. In PetriNED positive critiques get delivered in a graphical way and close to the user’s focus of attention. This way critiques are not distracting users who are not interested in the positive critique, and the critiques are helpful to those users who are interested in getting positive feedback. Thus, in this case “function follows form”, that is, the way critiques get delivered determines what kind of critiques should be computed. Usually the form and the function of design environments co-evolve, and knowing about the possible functionality of critics turns out to be as important as knowing about possible ways for presenting the critiques.
14
M. Stolze
Nakakoji (1993) argues that not only the “right thing” and the “right time”, but also the “right style” is important for the critique delivery, but her argumentation remains in the realm of text-oriented critiquing and therefore does not consider that the question of the right timing can become obsolete if the right style of critiquing is used. Silverman & Mezher (1992) present an example of visual critique delivery. Antennas which are placed in problematic positions on a navy boat are marked red by critics. However, this remains the only example of visual critiquing, and it is not embedded into a broader discussion of direct manipulation style mechanisms for critique delivery. Terveen et al. (1991) introduced the concept of “implicit agendas” which is an interesting alternative perspective for studying ways in which immediate and delayed critics should deliver their critiques. However, early critics are not covered by the concept of implicit agendas, and the only method proposed for implementing implicit agendas is to change the visible properties of problematic objects in the design. As discussed above, also other methods can be used by immediate and delayed critics, and these additional methods should also be considered when designing implicit agendas. Another critique which could be raised is that the proposed methods for critique delivery are “just other names for well-known direct manipulation feedback mechanisms”. In response to this I would argue that thinking about feedback mechanisms as critics is an important change of perspective which can help to generate new ideas on what kinds of feedback are possible and desirable. Usually feedback-mechanisms are very simple and do not involve extensive “intelligence” on the part of the system. With the arrival of high performance processors even in lower-priced workstations it might be useful to think of feedback not in terms of simple mechanisms but in terms of critiquing to make appropriate use of the available computing power. Also, the proposed mechanisms for critique presentation go beyond “wellknown” methods for feedback in direct manipulation interfaces. Concepts like early critiquing, delayed critiquing and visual explanations have not been studied in any depth in the context of direct manipulation interfaces. A critique, closely related to the previous one, is that the proposed methods overstretch the concept of critiquing mechanisms and that only the traditional text-oriented critics should be called critics. It is true that the “critics” I discussed in the context of the PetriNED design environment did much more than traditional critics which only support users in detecting problematic properties of the design. The critics discussed here also inform users of potential positive properties of the design and help users to establish them; they help users not only in detecting but also in understanding problems of
ARTIFICIAL INTELLIGENCE IN DESIGN ’94
15
the design by supplying them with visual explanations, and critics using interactive representations even went beyond this by supporting the detection, understanding, and direct remedy of design problems. However, I do not think that this overstretches the concept of critics. Looking at these mechanisms as critiquing mechanisms is a valid development perspective (Stolze, 1991; Stolze, 1993) which will prove its usefulness only in the context of concrete development projects. 3.3. OPEN ISSUES The methods for visual critiquing discussed in this paper were developed in the context of the PetriNED design environment. While the presented methods seem to be applicable to many different kinds of design environments, it might turn out that they need to be adapted for some applications and that additional methods can be used or even have to be used there. For example, methods that allow users to tailor critics to their individual working style will be important in some design environments, though they were not necessary in PetriNED. Also PetriNED only supports individual design work; using visual critiquing methods for supporting group work is another interesting but as yet unexplored topic. Empirical evaluations and more experience in equipping design environments with visual critiquing mechanisms is needed to gain a better understanding of the potential of visual critiquing. 4. Summary Different methods for critique presentation in domain oriented design environments were discussed in the context of the PetriNED environment. Critics changed the shape of the cursor, they indicated relations of objects in the construction area, they changed the visible properties of the objects in the construction area, they modified the contents of the the agenda, and they let users see and manipulate their designs from alternative perspectives. It was shown that the challenge for the presented methods is not –as in traditional text-oriented critiquing– to “say the right thing at the right time” but to “show the right thing at the right place” and that the latter problem is easier to solve, as “finding the right place” allows for a fine-grained control of the intrusiveness of critiquing messages. The proposed methods support the delivery of messages by early, immediate and delayed critics. The alternative way of presenting messages allows critics to give users additional support beyond what is possible with traditional presentation methods. This makes the proposed methods a critical element in the development of any domain oriented design environment.
16
M. Stolze
Acknowledgments I would like to thank the members of the Human-Computer Communication Group at the University of Colorado at Boulder, who helped me with important ideas and criticism. The research is supported by the Swiss National Science Foundation. References Bastide, R. & P. Palanque (1990). Petri Net Objects for the Design, Validation and Prototyping of User-Driven Interfaces. Proceedings of IFIP INTERACT’90: HumanComputer Interaction. 625-631. Fischer, G., A. Lemke & T. Schwab (1985). Knowledge-Based Help Systems. Proceedings of ACM CHI’85 Conference on Human Factors in Computing Systems. 161-167. Fischer, G., A. C. Lemke, R. McCall & A. I. Morch (1991). Making Argumentation Serve Design. Human-Computer Interaction 6(3-4): 393-419. Fischer, G., K. Nakakoji, J. Ostwald, G. Stahl & T. Sumner (1993). Embedding Computer-Based Critics in the Contexts of Design. Proceedings of ACM INTERCHI’93 Conference on Human Factors in Computing Systems. 157-164. Gross, M. (1992). Graphical Constraints in CoDraw. IEEE Workshop on Visual Languages, Seattle, WA, IEEE Press. Hutchins, E. L., J. D. Hollan & D. A. Norman (1985). Direct Manipulation Interfaces. Human-Computer Interaction 1(4): 311-338. Murata, T. (1989). Petri Nets: Properties, Analysis and Applications. IEEE Proceedings 77(4): 541-579. Silverman, B. G. & T. M. Mezher (1992). Expert Critics in Engineering Design: Lessons Learned and Research Needs. AI Magazine Spring: 45-61. Stoica, N. & G. Roth (1986). Neuronal networks modeled by Petri type nets with controllers. Proc. 12th IFIP Conf., , Budapest, Lecture notes in Control Inf. Sci. Stolze (1991). From Knowledge Engineering to Work-Oriented Development of Knowledge Systems. Unpublished Ph.D. Dissertation, University of Zurich, CH. Stolze (1993). The Workshop Perspective: Beyond the Optimization of the “Joint ManMachine Cognitive System”. AAAI Fall Symposium, Human-Computer Collaboration: Reconciling Theory, Synthesizing Practice, AAAI Technical Report FS-93-05. Stolze (1994). From System Requirements to Appropriate Knowledge Representations: A Case Study. Artificial Intelligence for Applications, San Antonio, TX, IEEE Press. Stotts, P. D. & R. Furuta (1989). Petri-Net-Based Hypertext: Document Structure with Browsing Semantics. ACM Transactions on Information Systems 7(1): 3-29. Tabak, D. & A. H. Levis (1985). Petri net representation of decision models. IEEE Trans. Syst. Man, Cybern. 15(6): 812-818. Terveen, L. G. (1991). Intelligent Systems as Cooperative Systems. The International Journal of Intelligent Systems (Special Issue on The Social Context of Intelligent Systems) :
