collaboration and coordination in architectural design...

Ž .Automation in Construction 7 1998 465–473

Collaboration and coordination in architectural design:approaches to computer mediated team work

Mark D. Gross a,d,), Ellen Yi-Luen Do a,c, Raymond J. McCall a,d,Wayne V. Citrin b,d, Paul Hamill b, Adrienne Warmack a, Kyle S. Kuczun a

a Sundance Laboratory for Computing in Design and Planning, College of Architecture and Planning, UniÕersity of Colorado at DenÕer,Boulder, CO, USA

b Department of Electrical and Computer Engineering, UniÕersity of Colorado, Boulder, CO, USAc College of Architecture, Georgia Institute of Technology, Atlanta, GA, USA

d Institute of CognitiÕe Science, UniÕersity of Colorado, Boulder, CO, USA

Abstract

The paper reports on three projects at our laboratory that deal respectively with synchronous collaborative design,asynchronous collaborative design, and design coordination. The Electronic Cocktail Napkin and its mobile extension thatruns on hand-held computers supports synchronous design with shared freehand drawing environments. The PHIDIAShypermedia system supports long-term, asynchronous collaboration by enabling designers of large complex artifacts to store

Ž .and retrieve rationale about design decisions and the Construction Kit Builder CKB supports team design by supporting apriori agreements among team members to avoid conflicts. q 1998 Elsevier Science B.V. All rights reserved.

Keywords: Synchronous collaboration; Asynchronous collaboration; Coordination

1. Introduction: collaboration in architectural de-sign

In 1993 and 1994, instructors and students ofarchitecture at several universities around the world 1

collaborated briefly on two ‘virtual design studio’projects. Using off-the-shelf technology of the time—e-mail, CU-See-Me internet video, internationalconference calls, and exchange of CAD drawings,

) Corresponding author.1 Hong Kong University, Escola Tecnica Superior´

d’Arquitectura de Barcelona, University of British Columbia,Washington University, Harvard Graduate School of Design, andMassachusetts Institute of Technology.

images, and Quicktime animations—this ambitiousproject explored the possibility of bringing togetherdiverse members of an international design team

Ž .together to collaborate on a short term 2-weekproject. Central to the ‘Virtual Design Studio’ was a‘digital pin-up board’, an area where participatingdesigners could post and view drawings and textualcomments; video links and e-mail exchange providedthe media for direct communication media aboutdesigns.

w xA report on the project 1 makes clear that theprocess was not without technical difficulties: a sig-nificant amount of communication concernedscheduling and coordinating file formats; disappoint-ingly, little was devoted to discussions of design

0926-5805r98r$19.00 q 1998 Elsevier Science B.V. All rights reserved.Ž .PII S0926-5805 98 00055-7

( )M.D. Gross et al.rAutomation in Construction 7 1998 465–473466

issues. Although it is clear that many of the minortechnical problems that inevitably plague a forward-looking effort like the Virtual Design Studio will besolved in the near term, the project also reveals theneed for research on software and design practices tomake computer-mediated design collaboration real-ize its attractive promise.

William J. Mitchell, dean of the MIT School ofArchitecture and Planning, and a participant in theVirtual Design Studio experiments, identified fourdeveloping technologies that underlie the computer-mediated collaboration that the Virtual Design Stu-dio experiment heralds. These are: pervasive com-puter networking, digital video, the integration ofvideo with computation, and hand-held wireless digi-

w xtal communication 2 . Mitchell sees these compo-nents changing the prevailing paradigm incomputer-aided design from traditional computergraphics involving a single designer interacting witha machine to construct CAD drawings and models,to a process of computer-mediated negotiation amongmultiple players.

Mitchell correctly identifies key hardware tech-nologies that are making international design collab-

Ž .oration possible; most projects including ours incollaborative CAD do employ one or more of thesetechnologies. However, the Virtual Design Studioproject also makes it clear that effective designcollaboration demands more than merely connectingthe members of a team with the highest possiblebandwidth. Successful collaborative design also re-quires attention to the organization of design processand product, that is, to the methods and representa-tions used in design. In short, computer-mediatedcollaboration will not succeed on the back of tech-nology alone.

Therefore, to Mitchell’s four technologies, we addthree observations about their effective use in collab-orative design. First, the interface that a collaborativedesign system presents to its users is a critical deter-minant of its potential for success. Designers lackextensive and sophisticated computing experience;their productivity will correlate directly with theusability of the interface. Ideally, a collaborativedesign system should present as simple an interfaceas the designer’s familiar pencil and paper. However,it must also make it easy for a designer to access theextended capabilities that computer support can pro-

vide: constraint checking, simultaneous work withŽ .possibly remote other designers, filing and index-ing, iterative changes and versioning, etc. As draw-ing remains a primary means of communicationamong designers, we have begun there. In our dis-cussion of synchronous collaborative work, we dis-cuss drawing as an interface to collaborative design.

Second, as designers work, they produce a lot ofdata and it is essential to find ways to capture,structure, and index this data so that all members ofa team can use it. As one participant comments, ‘‘Inthe VDS project a mountain of files were generatedby participants from different universities. It was adifficult task determining which and how some of

Žthese files related to each other. Which floor plan. w xgoes with which section or surface model? ’’ 1

Ž .Renato Garcia, p. 34 . More is needed than a publicarea where collaborators can post their work. De-signers need to be able to quickly, easily, and insome cases automatically construct links and annota-tions among these postings that capture the relation-ships among the individual drawings, photographs,and comments that comprise the collaborative designdocument. We take these issues up below in dis-cussing our work on asynchronous collaboration andthe construction of digital design databases of arti-facts and argumentation.

Finally, a design team must coordinate its effortsexplicitly: the effective functioning of a team re-quires designers to agree to work in certain ways. Ata basic level, the team must determine protocols for

Žcommunication turn-taking, file formats, schedul-.ing . At the level of the design artifact, the team

must agree about areas of design responsibility—whowill make what decisions and what rules shall gov-ern the decisions designers make? We take up theseissues below, in describing our work on designcoordination.

In the following sections, we report on threeprojects that deal respectively with synchronous col-laborative design, asynchronous collaborative design,and design coordination. In each of these sections,we provide an overview of the project, directing theinterested reader to our more detailed reports on thework. We conclude with a description of severalcurrent efforts that suggest connections among theseprojects, and perhaps a way to incorporate them intoa larger framework for collaborative design.

( )M.D. Gross et al.rAutomation in Construction 7 1998 465–473 467

2. Synchronous collaborative design

Ž .Same time synchronous collaboration in designis perhaps the most obvious form of collaborationthat computers can support and extend. In traditionalarchitectural design settings, design team memberssit together to hear a presentation, discuss designissues, and sometimes, sketch a preliminary designthat can then be carried out in detail by one or moreteam members after the meeting. Traditionally, thesemeetings take place around a conference table, butrecently, technologies such as video teleconferenc-ing, fax, Liveboard, and computer-mediated meetingspaces have made it possible to hold meetings forsynchronous collaboration among design team mem-bers who are geographically dispersed. The earliestefforts to support synchronous collaboration in archi-tectural design employed video links between collab-

w xorating designers’ offices 3 ; several other recentprojects have focused on integrating live video ofdistributed team members with shared drawings and

w x w xtext 4–6 . Like others 7,8 , we have concentratedon freehand drawing because we believe it is anatural and familiar way for designers to interact,especially in the early stages of design.

The Electronic Cocktail Napkin is a program thatsupports collaborative freehand sketching and draw-

w xing on digitizing pads with pens 9 . It combinespaint and draw features: users draw whatever theywant, unrestricted by menus of graphic primitives yetmarks users make can be selected, dragged, resized,and rotated, and combined into groups or configura-tions. The Cocktail Napkin supports simulated trac-ing paper and underlays, constraint based drawing,

Fig. 1. Designers engaged in informal sketching with the Elec-tronic Cocktail Napkin.

Fig. 2. Collaborative drawing with a wired Mac and a wirelessPDA connected by a radio frequency modem.

sketchbooks, and a pin-up bulletin board. Unlikeearlier shared drawing programs, the Napkin alsoprovides trainable recognition, user programmableparsing, and contextual interpretation of diagrams asinput to simulation programs and visual libraries.Thus, diagrams and sketches are primary means ofentering designs into ‘knowledge based’ tools and

Ž .arguing about them Fig. 1 .The Cocktail Napkin program provides several

collaborative drawing modes. First, two designerscan share a single drawing surface—a digitizingtablet. The designers use digitizing pens that can bedistinguished by the software and the program tracksauthorship of different parts of the drawing. Thismode is similar to two designers sketching togetheron a cocktail napkin or the back of an envelope in aninformal brainstorming session. In a second mode forcollaborative drawing, the designers still share adrawing space, but each holds their own tablet andpen. The third mode involves two programs running

Ž .on separate machines, connected point–point overa local area network. In this mode, both designersrun a version of the program on their own machinesand the programs exchange drawing and editingcommands using a protocol we devised for graphicsinterchange. We have also built a version of thecollaborative drawing program that runs between a

Žhand-held wireless PDA personal digital assistant:.an Apple Newton and a host, or between two PDAs,

providing a portable digital sketchbook, connectedŽwith a central database or with other designers Fig.

.2 .


3. Asynchronous collaborative design

A rather different kind of support for collabora-tive design involves asynchronous work. Short-termasynchrony enables people in different time zones oron different schedules to participate at their ownconvenience, rather than coordinating schedules tohold an on-line design meeting at a specific time.Long-term asynchrony enables the collaboration ofdesigners over an extended design calendar and overthe life cycle of a product, allowing designers whojoin the team later to gain access to design rationaleof designers who participated earlier, but who haveleft the project or moved on to other issues. Tosupport long-term asynchronous collaboration, it isuseful to provide an archive or repository for designrationale and the means for designers to record thereasons for certain decisions and to retrieve rationalestored previously by others.

w xThe PHIDIAS hypermedia system 10–12 is anexample of support for long-term asynchronous col-laboration. PHIDIAS—Procedural Hierarchy of Is-sues Design Intelligence Augmentation System—en-ables designers of large complex artifacts to storeand retrieve rationale about design decisions. Storingand retrieving design rationale enables designers en-gaged later in the design life cycle to understand thereasons for what might otherwise be obscure deci-sions taken by earlier designers.

Commercial products such as Microstation’sTeamMatee and Autodesk’s WorkCenter for theWebw offer document and work flow management,including shared use of drawings, version and update

Žcontrol. TeamMatee uses ODBC Open Data Base.Connectivity to support check-in and check-out of

documents, and change notification of text files anddrawings, at the document level. Likewise, Au-toDesk’s WorkCenter helps design teams manage theaccess, cataloguing, tracking, sharing, and distribu-tion of project documents. By contrast, PHIDIASŽ .like all hypermedia systems is concerned with linksin a collection of design rationale, and has no con-cept of a document: PHIDIAS operates at the levelof words, sentences, and paragraphs. PHIDIAS isdesigned to handle discussion about design projects,not just to manage the design documents. In addi-tion, PHIDIAS does not attempt to manage workflowat all.

The PHIDIAS system is organized around HorstRittel’s scheme of an Issue Based Information Sys-

Ž . w xtem IBIS 13 : information about an artifact isorganized as a hierarchy of issues, answers, and

Ž .arguments Fig. 3 . PHIDIAS differs from otherw xissue based information systems such as gIBIS 14

w xand SYBL 15 in its granularity—it is a fine grainedsystem—and that it stores not only textual informa-tion, but also drawings, photographs, and sequencesof digital audio and video as parts of the designargument. Earlier work on PHIDIAS has resulted ina single-user system that can be used to enter newdesign rationale in the form of issues, answers, andarguments. It included a structured editor for textualdesign rationale, facilities for producing three-dimen-sional models and entering audio and video as nodesin the hypermedia design argument structure. Thecurrent PHIDIAS system has been extended to re-spond dynamically to queries received over theworldwide web, providing design rationale on-the-flyto Java-enabled clients.

PHIDIAS has been used to construct a large issuebase of design rationale about space-based habita-tion, providing NASA’s Man Space Information Sys-tem documents in an electronic format, structured asan issue base. To assist users in locating relevantinformation in this enormous issue base, the systemsupports ‘argumentative agents’ that detect overlapsin the concerns of different participants in a designprocess, notify these participants of overlapping con-

Fig. 3. The PHIDIAS HyperCAD system structures a database ofdesign artifacts and argumentation.


cerns, and enable and support sustained communica-tion among these people to deal collaboratively withthe overlaps. Three kinds of argumentative agentshave been devised: advocates, knowledge-based crit-ics that examine and critique partially-formed solu-tions; scouts, which watch for and report on newinformation entered anywhere in the issue base; andreporters, which report on activity in certain parts of

Žthe issue base for example, for attempts by other.designers to change parts of a design .

4. Design coordination

Orthogonal to the synchronous–asynchronous dis-tinction of collaborative design outlined above is theapproach of design coordination. Our Construction

Ž .Kit Builder CKB project explores this way ofsupporting team design under the premise that apriori agreements among team members can avoidmany conflicts that otherwise might arise and needto be resolved during designing.

Complex artifacts, e.g., buildings, are assembliesof many different systems, each with its own particu-lar characteristics, and each the responsibility ofdifferent design team members. For example, onedesigner might be in charge of laying out partitionwalls, while another is to design the electrical distri-bution system, and a third will be responsible forlaying out the system of heating and ventilatingducts. In a conventional CAD process, each subsys-tem layout will be done separately, then combined

Žtogether for example, on separate layers of a CAD.drawing and checked for interference conflicts ei-

ther by hand or using a 3D interference checker builtinto the CAD program. This process postpones thediscovery of conflicts until most of the design workis complete, and therefore, resolutions and repairsare likely to be ad hoc andror costly. Even if thedesigners were networked, sharing a single CADdatabase, physical interference problems could notbe detected until the second component is placed,and resolutions would still be negotiated in a one offmanner.

To avoid this sort of conflict, the design teammembers must reach agreements about the placementof physical components into the design in the firstplace. Before beginning to lay out the design, the

team must agree on allowable locations for the com-ponents of each system. As many of the systems arepervasive—ventilating ducts must reach all parts ofthe building—it is useful to establish a scheme ofthree-dimensional zones that can be allocated to thecomponents of the various systems. For example, azone that occurs every 12 ft is allocated to carry theventilating ducts. Many of the ad hoc interferenceconflicts can be avoided by using dedicated spatialchannels for each of the systems that must be laidout in the building. Any interference conflicts that dooccur will happen at zone intersections, where thecondition can be anticipated and a standard resolu-tion designed.

To support this scheme, each designer’s CADeditor must be programmed with the rules for place-ment and assembly of their particular system. TheHVAC designer who is laying out a system of ducts,fans, and vents works with a standard catalog ofcomponents that go together in certain ways, and thatŽ .according to the team’s agreed-upon rules can beplaced only in certain zones in the building. Byprogramming the CAD editor with these rules, theHVAC designer can proceed fairly independently ofother system designers, knowing that interferenceconflicts will be minimized and will only occur incertain locations.

We have built a program to demonstrate theseŽ . w xideas. Construction Kit Builder CKB 16,9,17 is a

CAD program that operates at two levels. At theŽ .lower layout level, it is simply a design editor in

which a designer can select components from acatalog and lay them out to make a design. However,the designer is restricted to placing elements only in

Ž .certain locations zones and assembling them inŽ .certain ways. At the higher coordination level,

Construction Kit Builder enables the design teamcoordinator to assign placement and assembly rules

Žto the components of each system for example,restricting ventilating components to one set of zones,

. Ž .and electrical components to another Fig. 4 .Design rules that enforce the placement of differ-

ent systems’ components in different zones, and theassembly of the components of each system areimplemented using algebraic constraints, which ap-ply locally when the designer lays out components.Placement constraints are attached to systems andinherited by individual components and assembly


Fig. 4. Construction Kit Builder provides a design team the means to express and enforce rules to coordinate the placement and assembly ofthe components of different systems.

constraints apply to specific pairs of components.The constraint machinery is simple propagation,though more sophisticated techniques naturally couldbe applied. But sophisticated constraint solving is notthe point. Rather, we aim to show how the layoutconcerns of a design team can be partitioned basedon simple a priori agreements about the placement ofcomponents, thereby sidestepping what otherwisemight later become thorny conflicts.

To be sure, other kinds of conflicts than spatialones occur in a building design process, for exampleoriginating from trade-offs among various functionalrequirements. Construction Kit Builder makes noattempt to represent functional requirements or in-deed any requirements other than rules about place-ment and assembly. In that sense, the program leavesall management of design goals and objectives in thehands of the layout designer. The management ofspatial layout rules could be augmented by tools thatsupport other aspects of designing. For example, apipe routing system could be used to suggest optimalpaths, or a structural simulation could ensure thatpositions and dimensions chosen for columns andbeams meet load requirements. But the aim of CKBis merely to manage the spatial constraints, and leavefunctional decision-making to the designer.

5. Current and future work

Several interesting connections between theseoriginally independent projects have emerged and weare exploring the potential for combinations, some

described below. For example, in HyperSketch, weexplore the use of freehand sketches as nodes in ahyper document. In Retrieving Cases with Diagrams,we look at how drawings can be used as queries tolarge design databases. And in Digital DesignSketchbooks, we combine our work on collaborativedrawing work a design archive to support asyn-chronous collaboration.

5.1. Hypersketch— drawings as nodes in a CADhyper document

We have observed that in the course of a designsession, a single designer may produce as many as ahundred sketches, generated sequentially. In teamwork, several designers may work at this activitymore or less in parallel, and come together from timeto time to compare notes and integrate their designs.Sketches are linked conceptually: often each succes-sive sketch made by a single designer responds tosome perceived problem or opportunity in the previ-ous drawing. In McCall’s HyperSketch prototype,sketches are stored as nodes in a hyper document,with links that indicate the sequence in which they

Ž .were made Fig. 5 . Additional links can also indi-cate relationships among sketches such as ‘designalternative’, ‘fixes problem in’, ‘elaboration of’, and‘abstraction of’. HyperSketch makes it easy for thedesigner to specify these and other relationshipsamong sketches. Members of a design team workingseparately can browse the sketches others have madeand establish labeled links between these sketchesand their own. The sketches themselves can be anno-


Fig. 5. In HyperSketch, designers’ freehand drawings are linked asŽnodes in a hyperdocument graph. Above: designers’ sketches

.made in HyperSketch; Below: hypermedia structure .

Žtated with text e.g., arguments about and comments.on the designs , and the resulting structure of linked

and labeled sketches then shared as a repository ofinformation about the design.

ŽCommercial redlining products e.g., Autodesk’sWorkCenter, Radian Systems ImageDOCS, and In-

.tergraph’s DMrRedline enable a designer to addtext and graphic annotations to drawing documentswithout modifying the actual file. Some productsŽ .e.g., Microstation Review support pen based inter-face to allow quick freehand annotations. The func-tionality prototyped in Hypersketch would add tothese products’ functionality full, typed link servicebetween hand-drawn annotations on various draw-ings, as well as links from a sketch drawing tosupporting design rationale documents.

5.2. RetrieÕing cases with diagrams

We have used the Electronic Cocktail Napkin tobuild a query-by-diagram retrieval scheme fordatabases of designs and we have used the scheme toindex case bases of architectural post-occupancy

w xevaluation studies 18 and on-line libraries of tech-nical data about heating, ventilating, and air-condi-

Ž . w xtioning HVAC 19 . For data in which spatialrelations or physical form is salient, designers mayprefer to construct queries by drawing diagrams,rather than constructing a textual query from key-

Fig. 6. In Retrieving Cases with Diagrams, sketches and diagrams are used to index relevant information from on-line design databases.


words. Our scheme employs simple visual book-marking: A designer first draws diagrams to indexitems in the case library. Later, those cases may be

Ž .retrieved by drawing similar diagrams Fig. 6 .In a large collaborative design database, sketches,

diagrams, drawings, and photographs will comprise asignificant fraction of the data. We can apply thevisual bookmarking scheme we developed for query-ing case libraries to design databases that are con-structed collaboratively by a design team. We seequery by sketch as a valuable addition to text basedsearch and retrieval for designers participating in alarge collaborative project to find and retrieve designinformation that others have stored in the database.

5.3. Digital Design Sketchbooks and mobile, wire-less, graphical communication

We have experimented with a wireless mobilesketchpad communicating with a wired host com-puter to support a team of distributed, collaborating

w xdesigners 20,21 . Each design team member workswith a Digital Design Sketchbook, a hand-held Per-

Ž .sonal Digital Assistant PDA . We are currentlyusing the Apple Newton Message Pad 130 with awireless modem. The Newton and a Macintosh run-ning the Cocktail Napkin program communicate us-

Ž .ing a wireless radio frequency modem connectionspeaking Appletalk. A web site for the design teamserves as a shared repository and design history fordrawings, written comments, and photographs, con-

Ž .tributed by each design team member Fig. 7 a .Drawings and text from the web site can be down-loaded to the PDA, annotated locally, and the de-signer’s marked-up version uploaded to the web site

Ž .for others to consider Fig. 7a,b and c .In our prototype, the mobile PDAs running our

SmartPad program communicate with the ElectronicCocktail Napkin software running on a ‘host’ Macin-tosh. When the Napkin program receives a drawingfrom one of the mobile PDAs, it saves the drawing

Ž .as a GIF file Fig. 7 b , and copies the file to aspecial directory on the web server. A CGI on theweb server polls this directory and whenever a newfile appears it adds the file to the design team’s webpage. A simple web browser running on the PDAwould enable a user to retrieve any drawings, pho-

Ž . Ž .Fig. 7. a Documenting on-site conditions; b Web server for thedesign team stores drawings, comments, and other data the PDA

Ž .provides; c Designer’s marked-up drawing on the PDA, up-loaded to the server.

tographs, or text that other team members haveposted; the present version can only return drawingsoriginally made on the PDA or the Napkin. In afuture version, we plan to replace the generic webserving software with a PHIDIAS-like server thatcan help structure the emerging design as the teamworks.


5.4. Summary

We have outlined three approaches to computersupport for collaborative design that we are explor-ing—shared drawing, an archive of rationale, andcoordination of decision-making. Correspondingly,we believe—drawing is a primary medium in manydesign domains, design tools should support not onlyconstruction of the artifact but also the argumentabout the artifact, and that computer tools shouldhelp design teams, as well as manage and workwithin explicit agreements about the design. Theinterplay between these three approaches, and theirexecution with various hardware and software tech-nologies—mobile sketchpads, Java clients and back-end servers, promise a fascinating, if fast-changing,research program in collaborative CAD.

Acknowledgements

We gratefully acknowledge the following supportfor the projects described in this report: NSF grant,DMII 93-1316, ‘Avoiding interference conflicts inarchitectural subsystem layout—a constraint basedapproach’; a NASA SBIR contract with JohnsonEngineering, Boulder, ‘Using hypermedia and theinformation superhighway to improve design ofspacecraft interiors’; NSF grant IRI 96-19856, ‘Backof an envelope’; a grant from the Colorado Ad-vanced Software Institute and US West AdvancedTechnologies, ‘PDA-Based architectures for graphi-cal interchange’; A University of Colorado Presi-dent’s Educational Technology Grant, ‘Toolkit fortechnology enhanced education’.

References

w x Ž .1 J. Wojtowicz Ed. , Virtual Design Studio, Hong Kong Univ.Press, Hong Kong, 1995.

w x2 W.J. Mitchell, The Future of the Virtual Design Studio, in: J.Ž .Wojtowicz Ed. , Virtual Design Studio, Hong Kong Univ.

Press, Hong Kong, 1995, pp. 51–59.w x3 S. Harrison, Computing and the social nature of design,

Ž . Ž .ACADIA Q. 12 1 1993 10–18.w x4 S. Bly, S. Harrison, S. Irwin, Media spaces: bringing people

together in a video, audio and computing environment, Com-Ž . Ž .mun. ACM 36 1 1993 26–45.

w x5 H. Ishii, M. Kobayashi, J. Grudin, Integration of interper-sonal space and shared workspace: Clearboard design and

Ž .experiments, in: S. Greenberg, S. Hayne, R. Rada Eds. ,Groupware for Real-Time Drawing, McGraw-Hill, London,1995, pp. 96–125.

w x6 S.A.R. Scrivener, D. Harris, S.M. Clark, T. Rockoff, M.Smyth, Designing at a distance via real-time designer-to-de-

Ž .signer interaction, in: S. Greenberg, S.Hayne, R. Rada Eds. ,Groupware for Real-Time Drawing, McGraw-Hill, London,1995, pp. 5–23.

w x7 S. Greenberg, S. Hayne, R. Rada, Groupware for Real-TimeDrawing, McGraw-Hill, London, 1995.

w x8 S.L. Minneman, S.A. Bly, Managing a trois: a study of a`multi-user drawing tool in distributed design work, Confer-

Ž .ence on Human Factors in Computing Systems CHI’91 ,ACM PressrAddison Wesley, New Orleans, LA, 1991, pp.217–224.

w x9 M.D. Gross, The electronic cocktail napkin—working withŽ . Ž .diagrams, Design Stud. 17 1 1996 53–70.

w x10 R. McCall, PHIBIS: procedurally hierarchical issue basedinformation systems, Proceedings, International Congress onPlanning and Design Theory, American Society of Mechani-cal Engineers, 1987.

w x11 R. McCall, P. Bennett, P. d’Oronzio, J. Ostwald, F. Shipman,N. Wallace, PHIDIAS: A PHI-based design environmentintegrating CAD graphics into dynamic hypertext, EuropeanConference on Hypertext, 1990.

w x12 R.J. McCall, P. Bennett, E. Johnson, An Overview of thePhidias II HyperCAD System, in: A. Harfmann, M. FraserŽ . ŽEds. , ACADIA Association for Computer Aided Design in

.Architecture , pp. 63–74.w x13 W. Rittel, W. Kunz, Issues as elements of information sys-

tems, Working Paper 131, Center for Planning and Develop-ment Research, University of California, Berkeley, 1970.

w x14 J. Conklin, M. Begeman, gIBIS: a hypertext tool for ex-ploratory policy discussion, Conference on Computer-Sup-ported Cooperative Work, Association for Computing Ma-chinery, 1988, pp. 140–152.

w x15 J. Lee, SYBL: a tool for managing group decision rationale,Conference on Computer-Supported Cooperative Work,ACM, 1990, pp. 79–92.

w x16 M.D. Gross, Avoiding conflicts in architectural subsystemŽ .layout, Concurrent Eng.: Res. Appl. 2 1994 163–171.

w x17 M.D. Gross, Why can’t CAD be more like Lego?, Automa-Ž .tion Construction 5 1996 285–300.

w x18 M.D. Gross, C. Zimring, E. Do, Using diagrams to access aŽ .case base of architectural designs, in: J. Gero Ed. , Artificial

Intelligence in Design ’94, Kluwer, Lausanne, 1994, pp.129–144.

w x19 E.Y.-L. Do, M.D. Gross, Reasoning about cases with dia-grams, Third Congress on Computing in Civil Engineering,American Society of Civil Engineers, 1996, pp. 314–320.

w x20 W.V. Citrin, M.D. Gross, Distributed architectures for pen-based input and diagram recognition, ACM Conference onAdvanced Visual Interfaces, ACM, Gubbio, Italy, 1996, pp.132–140.

w x21 W.V. Citrin, M.D. Gross, PDA-based graphical interchangeŽ .for field service and repair workers, Comput. Graphics 20 5

Ž .1996 641–650.

collaboration and coordination in architectural design...

Documents