TOOLS AND CHANNELS OF COMMUNICATION: DEALING WITH THE EFFECTS OF COMPUTER MEDIATION ON DESIGN COMMUNICATION

This paper proposes a methodology to evaluate the effects of computer-mediated communication on collaboratively solving design problems. When setting up a virtual design community, choices must be made between a variety of tools, choices dictated by budget, bandwidth, ability and availability. How do you choose between the tools, which is useful and how will each affect the outcome of the design exchanges you plan? A commonly used method is to analyze the work done and to identify tools which support this type of work. In general, research on the effects of computer-mediation on collaborative work has concentrated mainly on social-psychological factors such as deindividuation and attitude polarization, and used qualitative methods. In contrast, we propose to examine the process of collaboration itself, focusing on separating those component processes which primarily involve individual work from those that involve genuine interaction. Extending the cognitive metaphor of the brain as a computer, we view collaboration in terms of a network process, and examine issues of control, coordination, and delegation to separate sub-processors. Through this methodology we attempt to separate the individual problem-solving component from the larger process of collaboration. There is a long history of research into the role and application of computers to communication and collaboration from which has arisen a variety of tools to facilitate work done in groups. Holtham [1994] traces this history from the 1960s through to the 1990s, from addressing basic issues of computer communication through commercial implementation and diversified applications of


The Heritage of Computer-Supported Collaborative Work
When classifying the results of research into computersupported collaborative systems, McGrath and Hollingshead [1994] identify three ideas which have spurred the investigation and application of computers to work: 1. improved task performance 2. overcoming space and time constraints 3. increasing information access The authors then categorize the systems into four categories of technologies that modify group processes (each with their own acronyms), namely, 1. the groups' internal communication system (GCSS) 2. the group's information base (GISS) 3. the groups' external communication systems (GXSS) 4. the groups' performance processes (GPSS) In subsequent discussion, McGrath draws little distinction between the internal and external communications (GCSS and GXSS), noting that for both the technologies of communication and fields of research are similar.For both internal and external communication, technologies to support collaboration at a distance are summarized in six groups (Figure 1).These technologies are contrasted to the experience of synchronous co-locational face-to-face meetings.Note that distal asynchronous tools support simultaneous but asynchronous exchanges as found in electronic meeting systems (EMS) [Nunamaker, Briggs & Mittleman, 1995], electronic brainstorming (EBS) [Gallupe, Bastianutti & Cooper, 1991], electronic bulletin boards (EBB).

LESSONS LEARNED
It is not necessary here to review the various directions and conclusions of the great wealth of research which exists but it is useful to identify key learnings which can illuminate the operation and success of a virtual design

Distal, Synchronous
Distal, Asynchronous Video / Audio interactive video non-interactive video Audio telephone conferences voice messaging Text / Graphics interactive computer conferences non-interactive computer conferences (e.g.e-mail) studio.Key items to be found: 1. Process structure benefits: The electronic meeting systems (EMS) investigated by Nunamaker and his colleagues [Nunamaker, Briggs & Mittleman 1995] have found that the use of an EMS will introduce a structured process which can improve decision making.The computer system through which the participants are interacting may demand a particular sequence or method of interaction, this method having been determined to be beneficial through earlier research or through participants of the session agreeing on a particular way of collaborating.Just as an agenda makes a meeting run smoother, so too does the interaction proceed better when a structure is imposed.

Greater participation:
The imposition of computers into communication between problem-solving participants permits more equal contribution from participants [Kiesler & Sproull 1993].The participants of computer-mediated collaborations are observed to have reduced inhibitions about participating.Likewise, group dynamics are changed, permitting those who are suppressed in face-to-face meetings to hold their own ground in a computer-based group exchange.

Better results:
Computer-mediated exchanges often lead to better results.As reported by Kraemer & Pinsonneault [1990], efforts are more focused on the task analysis, leading to increased depth of analysis and decision quality.They note that decision support systems (GDSS) lead to group members having greater confidence in the results and hence greater satisfaction with the decision, while GCSS (and presumably GXSS using McGrath's terminology) lead to reduced satisfaction and confidence if they are applied to groups too early in the group development process.

A HISTORY OF COLLABORATIVE SUPPORT TOOLS IN ARCHITECTURAL DESIGN
There is a lack of formal research in the application of computer-mediated communication in design processes.Most of the work done to date in the field of design has either focused on a transactional approach to design or anecdotal descriptions of experiences.The former suffers from examining the activities of drawing with no distinction between the actions which lead to the result and the result itself, while the latter suffers by not identifying and questioning the assumptions upon which the design activity is based.
Using the classification system established by McGrath and Hollingshead, we can classify some of the efforts to date.This is not an exhaustive categorizing of work to date, but examples are given to illustrate approaches.We note that most efforts to apply computers to design collaboration have been in the communication realms of GCSS and GXSS, perhaps drawn to this by the same attractions to "being there" which Hollan & Stornetta [1993] suggest has driven much telecommunications efforts in the past 100 years.

GISS
Some research has dealt with the technical issues which arise in implementing tools for sharing information [Saad & Maher 1995, Kalay & Squin, 1995].This is central to the work done by Kimura, Komatsu & Watanabe [1995] in developing the Interapplicational Collaborative Design System (ICDS) to merge data from the many participants in planning.Similarly, McCullough and Hoinkes [1995] describe the dynamic data sets created during collaborative urban design.

GPSS
Some work has been done on tools to allow cooperative solution of problems though typically as part of a larger project, such as the Model Shop described in Kusama, Fukuda, Park, Sasada [1996] and the central focus of the work described in Comair, Kaga & Sasada [1996].

Architectural Collaboration: A Cognitive Perspective
The human brain is a massively parallel processor that coordinates the activities of multiple sub-systems and, consequently, much of what we do can be considered a collaborative effort of these sub-systems.Our conscious experience of these activities, on the other hand, is quite serial.The question of how such parallel activities are coordinated has traditionally been referred to as the issue of control.One way of construing the problem of understanding collaborative work between designers might be in terms of extending the question of control to include a group of brains rather than just one.
In collaboration, each participant can be considered as an individual agent working in parallel with other agents to achieve a common goal.(The term "agent" will be used to refer to any autonomous, intelligent, behaving system, including humans and machines).The relatively limited lines of communication that individuals can use at any one time (e.g.talking/listening, reading/writing, drawing/looking) suggest that between-agent-processing can be treated as a different level of analysis from within-agentprocessing. Certainly the more the lines of communication between agents are limited (i.e. by communications technology), the more this is likely to be true.The present study will focus on the control issues related to collaborative problem solving within a human/human context of interaction.More specifically, we will model collaborators as agents with sets of problem-solving skills and sets of goals.
Control, in the process of design collaboration, will be construed in terms of meta-planning processes coordinating the activities of the collaborative agents.Once a meta-plan has been agreed upon, the participants set to work on the problem.Each participant receives certain tasks to do, works on them, passes on the results, and proceeds to the next task.The whole process is coordinated by the control structure provided by an iterative process of meta-planning.Ideally, the first meta-plan results in a solution to the problem but there are three other possibilities: 1) the system produces no answer, 2) the system produces a wrong answer, and 3) the system encounters a stopping problem.Case 1 would occur when the meta-plan was set up only to meet an intermediate goal while case 3 would occur when the metaplan was inadequate to meet either an intermediate goal or the final goal.In either case the participants would need to re-negotiate the control structure.The stopping problem is similar but more complicated.The stopping problem occurs when it is unclear if a problem space will result in a solution or will lead to endless calculation.The dilemma is whether to stop or wait for a solution.If a participant determines that a procedure is taking too long he could decide to stop and re-negotiate the control structure.This is essentially process of independent task planning which is executed separately by each collaborator.As will be seen below, this will turn out to be one of the most important components of collaboration.
It is clear that, in addition to the problem-solving process, collaboration will also involve personality, emotion, and many other social / psychological factors.We suggest that these do not play an important role in shaping the measurable outcomes of the design process.We will argue that these outcomes are primarily shaped by the skills and expertise of the participants -i.e., the knowledge component of the collaboration rather than the social or situational ones.Context effects, socio-cultural variables, and non-knowledge-level individual differences will influence many aspects of collaboration, but will not have a significant impact on the measurable outcomes of the process.These variables, which are unrelated to the taskspecific knowledge of each participant, may affect things like the degree to which the collaboration is enjoyed or disliked, but the real result of the collaboration, in this case, an architectural design, will be largely the consequence of the knowledge and experience of each collaborator.A long history of research in Cognitive Science supports this view (see [Newell & Simon, 1973], for an account of this perspective), and it is the goal of this research project is to test this hypothesis empirically in the context of collaborative design.
The general model of collaboration proposed here which will be evaluated in these studies is shown in Figure 3.The first step involves a process of planning how to execute the task in a coordinated way.It is a "meta" planning process in the sense that it is about how to break down the problem into individually manageable units as well as about how and when the collaborators should come together to integrate their individual efforts.This part of the collaborative process does not really deal with the design problem itself, that is, with the real content of the task, but only with how to approach doing it collaboratively.This process is followed by another cooperative stepnegotiation regarding specific aspects of the design problem.Following an initial negotiation (this process could just as well be referred to as interactive or joint decision-making), each expert participant separately engages in well-learned routine problem-solving guided by the meta-plan that was agreed upon and constrained by the jointly-made, taskspecific negotiated decisions.When the participants have completed their agreed upon components, they interactively evaluate the outcome and are then either finished or they iterate through the steps again.Additional meta-planning may or may not be required and the process may begin again following further task-specific negotiation.If this model is correct then the tools used to support collaborative work should focus on facilitating the meta-planning, negotiation and evaluation components of the process.Otherwise, the tools should be no different than those used for individual work, except for requiring a means to share the results.
Experienced designers working collaboratively on a problem should behave like typical experts in any other area of expertise.They should have larger chunks of knowledge which they can apply quickly and in a fairly error free way.They should be able to work forward from the initial state of the problem (novices tend to use strategies such as working backwards from the goal).They should be able to reason by analogy from a large base of well cross-referenced knowledge about the field.Experts also plan better and monitor their progress more carefully (see [Bedard and Chi, 1993] for an extensive account of expert/novice differences).That the best architectural practitioners place great emphasis on the initiation of design exercises is documented by Coxe [1989]: "The purpose of the (predesign) phase is to explore the program with the client to the point where there is common agreement on an idea and direction ... to cement the architect-client relationship and to establish project direction."Cuff [1991] also discusses the need for this kind of activity early in architectural projects.
The sort of cognitive processing demonstrated by experts on well-learned tasks allows us to characterize the process of problem solving with a reasonable degree of accuracy.The central hypothesis of this research is that collaborative work by experts will look very much like individual expert work.There are additional processes, those we have labeled as meta-planning, negotiation, and evaluation, but even these are interactive extensions of processes that individual expert problem solvers carry out anyway.In contrast, we would expect novice collaborators to be poor at setting up effective meta-plans, resulting in a rapid and repeated need to re-negotiate.Following Rowe's [1991] conclusions derived from protocols of architectural design, we see that the process is inherently episodic, characterized by movements between explorations of architectural form and more technical issues.The exploration of form is guided by organizing principles brought to the process by the architects and by the constraints of the project.As Rowe points out, a considerable effort is generally required to get the initial concept to work rather than dropping it and starting fresh, thus we would expect initial negotiations (at least by experienced architects) to focus on establishing agreement on a guiding concept (i.e.establishing complementary goals and shared belief systems).Following this, Rowe describes, "periods of unfettered speculation, followed by more sober and contemplative episodes during which the designer, 'takes stock of the situation.'"Rowe also notes that, "during moments of clear problem definition more straight forward procedures are used," followed by an evaluation of their success.In a collaborative project, we would expect each of these episodes to be marked by a negotiation and an agreement followed by individual creative problem solving and interactive evaluations of the solutions.The research proposed here will explore this model of collaborative design using cognitive modeling methodologies.

An Experiment in Design Collaboration
To test the usefulness of our model for understanding a design collaboration scenario we selected a design problem and two experts to collaborate on a solution.In this initial experiment we restricted our experts to using email for communication.The problem was to be solved using a computer-aided drawing system (FormZ) with which both were familiar; the CAD files could be shared by attaching them to email messages.The experts were video taped during the task, which lasted approximately an hour and a half; the emails and attached drawing files were collected at the conclusion of the session.During the task, one expert was assigned to play the lead role (i.e.project architect) and the other a consultant.In addition, one of the authors acted as the client and could also be contacted by email but had no means of viewing the drawings while the experiment was conducted.The design problem defined for this research is straightforward and able to be solved by someone with a basic design education.The first casting of the problem was formulated by Cheng [1994] as a design problem for a second year undergraduate design studio, to be completed individually by the students over a 73 hour period.One of the authors of this paper participated in the supervision and evaluation of the solutions provided by seventy second year students.The results from that use of the problem fell in the normal range of quality seen in a second year exercise.On basis of this experience, it was considered a satisfactory problem from which to create a simpler problem for use here.
For the purposes of this research, the problem was simplified further.Less was asked for from the participants, more information was provided in a simple reference format which could be immediately applied by the designers.The problem was also reformulated to express a need for collaboration.

THE DESIGN PROBLEM
The participants were presented with an A3 sheet of paper on which a site plan was shown (Figure 3) and a written problem definition as follows.
"Objectives: To resolve site access problems using basic rules of site design.You are work as a pair together to design a rest area and car parking with pedestrian access within a sloped site as described in the attached site plan.The site consists of an evenly sloping site with a 13 meter difference in height from a hospital entrance at the top to a bus stop at the bottom.A car park for six cars is to placed on the site half way up the slope with access from Middle Road.The design challenge is to provide 1. access from the bus stop to the hospital 2. access from the car park to the bus stop and the hospital 3. a seating area for up to six people and perhaps a play ground for children at an appropriate point on the site 4. routes which are not too steep 5. appropriate vegetation and landscaping to complete the design concept 6. a sense of arrival at each site access point While achieving these goals, you should try to: • minimize cut and fill • minimize contour changes • drain the site appropriately

RESULTS
The participants started immediately into the task.Email was exchanged and files passed, each working in FormZ or email when needed.However, our experts were unable to come to a consensus in the allotted time.According to our analysis this was due to a failure to recognize the limitations imposed by the restricted medium of communication early enough in the process.Our analysis also revealed that our experts were able, in the course of their work, to identify the problem as one of insufficient collaborative planning and become increasingly focused on this issue towards the end of their allotted time.
All email exchanges were collected and analyzed in terms of proposed model (see the transcript on the next two pages).Specifically, the messages were coded according to whether they referred to task specific issues, or meta issues concerning the nature of the collaboration.A meta planning communication was anything that referred to structuring the collaboration but that was not specific to the design problem itself (these were coded as MP for meta-planning).A task specific communication was any attempt at communication that referred to solving the particular design problem (these were coded as TP for task-planning).
Whether TP's belong in the negotiation box or in the Individual work boxes in Figure 3 is left as an open question until after the discussion of the transcript.Each MP and TP communication was further coded in terms of whether the participants were reporting information (reports), requesting information (queries), or recommending a course of action (suggestions).In addition the actions of the experts were coded as either individual work (IW) or evaluation (EV).Collectively, task-planning, meta-planning, individual work, and evaluation are broad categories describing the goal states of our experts.

INTERPRETATION
Several features stand out.The first is the ratio of task-Planning to meta-planning messages, 33 to 5. Overall our experts were much more focused on solving the task than on establishing a plan for collaboration.Another important feature is the fact that substantive MP messages do not begin to appear until near the end of the experiment.This parallels comments by the subjects themselves who were at first focused on TP issues and later, in the face of problems, increasingly focused on MP issues.
The attempts on the part of each subject to communicate with the other regarding specific aspects of the design problem which we have labeled TPs did not, in the end, resemble negotiations, but instead seemed to be more like individual work.Analysis of the transcript of the collaboration shows that each of the participant's attempts to communicate with the other was mostly self-initiated, possibly because they felt they had made progress or a change significant enough to report to the other.These actions did not resemble genuine Negotiation where the participants would be expected to refer to specific items of each other's design in relation to their own and come to an agreement for a joint solution.TPs looked much more like either progress reports or explanations of independently reached design decisions.If these results hold-up with a larger pool of subjects, they would suggest that there is even less genuine collaboration in the process of "collaborative design" than we initially hypothesized.
Suggestions for solving the MP problem focused around the limitations imposed by email (i.e.open a chat line, meet in person) rather than working within the email system.Individual work habits also introduced problems.Both experts preferred to maximize their FormZ window The main difference between our model and our experts' behavior came at the beginning.Instead of starting with MP issues, proceeding to TP issues and then to individual work, our experts began with individual work which led to TP issues, which were difficult to solve due to MP issues.Essentially the order was backwards (although the consultant did begin with MP issues he did not pursue it).However, it should be noted that our experts were only experts when in the individual work box, they did not have experience solving problems under these particular collaborative conditions.It was clear from the debriefing that they would pay more attention to MP issues had they worked for a longer period.Another interesting aspect of the debriefing was that our experts never voiced any complaints concerning the restrictions on their creative collaboration.
The process of working individually and then sharing the results seemed to occur naturally.When asked if a telephone call would have been sufficient to sort out their MP difficulties, the answer was yes.
In architectural terms, the work proceeded in a way which illustrated the sophistication of the participants.The Project Architect was the less experienced professional of the pair; he started into problem solving immediately, working against the deadline to come up with a solution (Figure 4).The person acting as consultant, however, had a few more years of professional practice behind him and started into problem definition and questioning the situation and constraints.
The initial collaborative efforts were misdirected as these two participants found themselves working to opposite purposes, the former to a solution, the latter to a problem definition.Thus the former came up with a drawn proposal quickly which was then amended when the Consultant's redefinition of the problem was received (Figure 5).As

Project Architect Consultant Client
To  [1989] notes, the more experienced architects appear to share this focus on problem definition prior to embarking on those tasks typically considered to be "design", such as drawing.Our premise that a collaborative project could be described in terms of our model was correct -advantagecan take it apart -We are not saying that our model captures everything that went on, but we are saying that our model captured most of what was important for the collaborationmore free lines of communication would require a finer grained analysis, but we believe it could also be characterized in this way.
It was also important for us to consider what was communicated in the drawings that were exchanged.For example, agreeing on the color scheme for the drawings can be considered a MP action in that it involved creating a mutually acceptable virtual work space but was incidental to solving the problem.In general, the drawings can be seen as largely the product of Individual Work and independent task planning.There was almost no actual negotiation based on the physical representations of the problems.

Implicit communications
Even in our very restricted communications environment the possibility of covert communications existed.An important issue for MP is the tone of the message.Our experts were polite and friendly, indicating agreement on this aspect of the working relationship.For example, the Consultant commented aloud during the task that he was attempting to word his response to the color scheme so as not to offend the Project Architect.
A second means of MP negotiation is in the use of the email.For example, the Consultant sent the Project Architect copies of his emails to Client whereas the Project Architect did not send copies of emails sent to Client on to the Consultant.In response, the Client forwarded the Project Architect's emails to the Consultant without prior permission; by his actions the Client was establishing that he wanted the emails to be shared.
These covert communications filled the same role which gestures and body language fill when talking face-toface.They communicate non-verbal information which, if the observer is aware of the coding, can extend the communications achieved.

Our Research in the Context of Others
The research described here flies in the face of assumptions made by several others who have worked in the field of computer-mediated collaborative design.Typically other research is driven by the need to recreate a "design space" in all its properties, without critically evaluating the contribution of these properties to design outcomes.This is the same problem which Hollan & Stornetta [1993] identify: "The assumption that the media and mechanisms of face-to-face interaction are actually the requirements for ideal communication is so pervasive ...The implication is that we are trying to find ways to communicate at a distance as if we weren't at a distance.But it is our contention that such an approach will always limit our thinking to replicating or imitating the mechanisms or one medium with another." An example of such work is that found in Tang [1991].
Here, the author identifies actions of "writing, freehand drawing and gesturing activities that occur when three or four people work around whiteboards or large sheets of paper," noting that "collaborative drawing tools should not be based only on what features computer technology offers...the design of collaborative technology needs to be guided by an understanding of how collaborative work is accomplished.By understanding what resources the collaborators use and what hindrances they encounter in their work, tools can be designed to augment resources while removing obstacles."From this study, the author concludes that gestures are as important as any other communication and that design of tools to support collaborative drawing activity should consider: • conveying gestures, maintaining their relationship to the drawing space; • conveying the process of creating and using drawings, with minimal time delay; • providing concurrent access to the drawing space; • allowing intermixing among drawing space actions and functions; and • enabling all participants to share a common view of the drawing space.
While it cannot be denied that the context within which an activity is carried out will affect the outcome, it would be difficult for any architect to claim that the color of the cocktail napkin was so important that it had to be reproduced for all future design activity.We are, as humans, adaptive to our environment (we learn to shut out the noises which interrupt us as we design) and adaptive of it (we find that shutting a window helps to control the noise).Although we exist in an environment with infinite levels of complexity, we solve each problem and make each decision in a much more restricted informational context [Simon, 1957].So it is in any collaborative communication -we adapt to it and we adapt it to our needs.Since our individual cognitive systems are not built to cope with the full complexity of the environment at any one time, we pick out what is relevant and necessary and proceed.As Dave [1995] notes about collaboration, participants learn to overcome the problems of the media, to adapt behaviors through preparation or action, to increase the "information to byte ratio".
Thus, when we read in Harrison and Minneman [1995] that descriptions of collaborative project reach a common conclusion: "That social processes are crucial; that these social factors are significantly affected by being physically distributed; and that design participant's social actions are altered by the technologies that connect remote locations." Our conclusion is different.The authors of this paper do not see this as a reason why we need to achieve "being there" through computer technology.Instead, we see the challenge as finding how to bring the technology under our control, whatever the technology, so we can continue to communicate.

THE ROLE OF VIDEO AND AUDIO
What then is the contribution of video and audio to the distal design process?For many starting up a virtual design studio, they are the most troublesome aspects, expensive to establish, frustrating in their performance [Dave 1995].
Others see them as central to the success of such distal collaboration.In Harrison & Minneman [1990], the authors note that video and audio can: "connect participants.Project teams can be sustained over distances and across organizational lines through live video images...The medium retains many of the vital qualities of face-to-face interaction (ambiguity, negotiation, visual communication) that are lacking in computers." It is not clear that these qualities (ambiguity, negotiation, visual communication)  For face-to-face interactions the medium is physically proximate reality...The framework of needs, media, and mechanisms also suggests a way to achieve a level of performance for communication tools that goes beyond being there...It...creates a framework in which it becomes meaningful to ask the question: what's wrong with (physically proximate) reality?" In our opinion, it is likely that they compensate by creating a more carefully constructed metaplan.It is not a foregone conclusion that this will result in a less effective process.Video may therefore not be a pre-requisite to successful design collaboration over distances.As McGrath [1994] also notes, "Videosystems, when first envisioned, seemed to offer great promise as convenient and low-cost alternatives to face-to-face meetings for groups whose members were geographically separated.The reality has proven less spectacular than the promise." For those involved in setting up virtual design studios, it has been a red herring.

The Next Stage
Our central research question concerns the role of individual work in the larger process of collaboration.Since this question is raised in the context of computer mediation for collaborative work, the relative effects of different channels of communication will be explored in terms of how they impact on the balance between meta task planning, interactive negotiation and individual effort.It will be important to understand the nature of the process in more detail since computer mediation would then need to be redesigned to support only those genuinely collaborative aspects of the task.Toward this goal, protocols will be collected from pairs of participants working on the same design problem (and under the same three communication conditions).
Using GOMS [Newell, 1990], the protocols will be analyzed to characterize the knowledge-level of the task.GOMS is an acronym for Goals, Operators, Methods, and Selection rules.It is a technique which yields "engineeringstyle" models of cognitive processing for certain kinds of tasks.A GOMS model begins with the definition of a toplevel goal which the user seeks to achieve, and a series of unit tasks that the user performs repeatedly until there are no tasks left.A goal is achieved by executing a method, which consists of a series of steps in which either a low-level operator is called to perform an action, or a subgoal is called to accomplish a subtask.An operator may be one of three types of things: perceptual, such as reading a display; motor, such as moving and clicking a mouse; or cognitive, such as making inferences from available data.
Methods are organized as a series of sequential steps to be performed to achieve a goal.A step may invoke a new goal to be accomplished, in which case the method for that subgoal is executed much like a call to a subroutine, or a step may invoke an operator, which contains implicit procedural and declarative knowledge that has not been further analyzed.A step may also invoke a memory operation of storing an item in working memory, recalling an item from working memory, or retrieving an item from long term memory.
In those cases where there is more than one method which can accomplish a goal, selection rules are written which decide which method is appropriate given the current unit task, the current state of the user's information, and the current state of external factors such as the display interface.Selection rules may also reflect a user's individual preference for one type of operation over another in various circumstances; however, the rules for choosing among methods should be clear in a well-designed interface.In GOMS, selection rules are tested in parallel, and, at any given time, exactly one of the rules must have a condition that is true.
Tasks which are amenable to GOMS analysis are those that involve significant routine content of an expert nature [Card, Moran and Newell, 1983].For a well trained architect, many aspects of the design task should fit this characterization.Recently, GOMS has also been successfully applied to interactive tasks and should therefore be useful for characterizing collaborative design activities [John, Vera, and Newell, 1994].
If, as predicted, the bulk of problem-solving is done individually, with collaboration consisting primarily of coordinating individual efforts, negotiation, and evaluation, then computer support for these tasks needs to be re-thought.It is also likely that some collaborative aspects of the tasks will be affected more than others by the communication platform.Individuals collaborating in solving a problem via an impoverished communication channel are more likely to plan further ahead and coordinate their individual efforts carefully up-front than people working face-to-face.Modeling the collaborative process using GOMS will allow us to observe these changes in collaborative problemsolving strategies at a fine level of granularity.

POINTERS FOR SETTING UP A VIRTUAL DESIGN STUDIO
Cognitive modeling methodologies such as GOMS have been used by interface designers to capture the mechanisms of action and interaction involved in routine expert behavior.Using this methodology, it is possible to evaluate the impact of different aspects of an interface in task-specific ways.In the proposed studies, GOMS will be used to characterize the interactive behavior of knowledgeable participants as they work on a design task under different communication-support conditions.The proposed methodologies are used to capture the collaborative design process in a way that yields information about productivity and performance of the subjects as well as about the knowledge-level mechanism involved in achieving these results.In other words, it yields information on the component elements of the design process, the basic cognitive building-blocks of design, thereby suggesting fundamentally new tools that might be created for interaction in virtual environments.
Specifically, this paper has argued that it is the interactive processes of meta-planning and negotiation which should be the focus of computer-mediated support.Other aspects of collaborative work are less interactive and should be supported as such.Thus the success of a virtual design studio depends not so much on the tools which are provided or the problem set, but more on the extent to which the participants are aware of the task they are getting into and the effort they put into collaboratively defining methods of work.

Acknowledgments
This research was supported by the University of Hong Kong under a grant from the CRCG.The authors are grateful for the assistance and support provided by the Departments of Architecture and Psychology and Ms. N Y W Cheng for use of her design problem as a basis for this research.

Figure 2 :
Figure 2: A Cognitive Model of Collaborative Design.
are essential to successful collaborative design, that there are not other signals or techniques which can replace the lack of video.The authors continue: "The use of real-time video connection can result in an intense task focus."Perhaps this intense task focus can be achieved without video too.The Xerox Park research, for example, point out the problems of having limited lines of communication in comparison to face to face interactions, but they fail to consider how people might compensate for this.As noted by Hollan & Stornetta [1993]: "Media are simply what mediates communication.