A Framework for Collaboration in Architectural Design

A Framework for Collaboration in Architectural Design

The 1960s

• 1962: Douglas Engelbart “Augmenting Human Intellect: A Conceptual Framework”

1960 1970 1980 1990 2000

Let me mention another bonus feature that wasn’t easily foreseen. We have experimented with having several people work together from working stations that can provide intercommunication via their computer or computers. That is, each person is equipped as I am here, with free access to the common working structures. There proves to be a really phenomenal boost in group effectiveness over any previous form of cooperation we have experienced. They can all work on the same symbol structure, wherever they might wish. If any two want to work simultaneously on the same material, they simply duplicate and each starts reshaping his version – and later it is easy to merge their contributions. The whole team can join forces at a moment’s notice to ‘pull together’ on some stubborn little problem, or to make a group decision. Most points of contention are resolved quite naturally, over a period of time, as the developing structure of argument bears out one, or the other, or neither stand.

A History of Computer-Supported Cooperative Work and Design

• To understand the current framing of computer-supported cooperative design as a set of technologies that enable geographically dispersed users to work collectively one must trace the evolution of the field to the original ideas advocated by its pioneers.

• This dissertation traces the development of the field starting in the 1960s.

• It ignores the period 1970-1985 since most work was concerned with automating the design process, conceptual modeling and visualization of buildings.

• Due to the limited scope of this dissertation, the survey halts at 1995 due to the rapid expansion of the field. Most of the proposed systems derive from earlier work.

1960 1970 1980 1990 2000

The 1960s

• 1963: Steven A. Coons “An Outline of the Requirements for a Computer-Aided Design System.”

1960 1970 1980 1990 2000

The Computer-Aided Design System should be capable of carrying on conversations with, and performing computations for several designers at several consoles substantially all at once. In this way each designer can be immediately aware of what the other designers are doing, and thus avoid one of the truly severe problems of intercommunication that designers face today.

The 1960s

• 1963: Ivan Sutherland “Sketchpad: A man-machine graphical communication system.”

1960 1970 1980 1990 2000

Sketchpad has shown the most usefulness as an aid to the understanding of processes, such as the notion of linkages, which can be described with pictures … A Sketchpad user sketches directly on a computer display with a “light pen.” The light pen is used both to position parts of the drawing on the display and to point to them to change them.

Utopia

• Engelbart, Coons, and Sutherland set the research agenda for the next 40 years

• They dealt more with theories than with actual implementations and thus their solutions tended to be utopian

• They viewed design as a congruent set of problems that can be addressed with one system and one approach

• For example, Engelbart mistakenly believes that merging different solutions is an easy task and resolving conflicts can occur naturally

• Coons falsely believes that synchronicity and social-awareness are the only needed features in addressing the problems that designers face

Top: Sam dreams of soaring through the clouds. Bottom: Sam struggles for desk space.

(Brazil © 1985 Embassy International Pictures NV. All rights reserved.)

Dual Approach

• To challenge these utopian assumptions the research is conducted along two tracks:– Track 1: Continue to trace the evolution of computer-supported collaborative work since

1986– Track 2: Design and implement prototypes of collaborative systems

Computer-Supported Cooperative Design 1986-2001

• Most of the computer-aided design research efforts in the 1970s and early 1980s concentrated on the problems of automating the design process as well as the geometric and conceptual modeling and visualization of buildings (Jones 1970; Mitchell 1977; Turner 1988, Stiny 1989)

• The implications of technological augmentation to cooperative design had to wait until the technology caught up in the second half of the 1980s with the advent of hypermedia, the maturity of computer networks, and the invention of the internet.

1960 1970 1980 1990 2000

Tim Berners-Lee invented the World-Wide Web on this NeXT computer


• First Conference on Computer-Supported Cooperative Work (CSCW) in Austin, Texas in 1986

• CSCW 1988, Portland, Oregon: First definition of cooperative design as a type of cooperative work

– Susan Bødker, Pelle Ehn and others published a paper titled Computer Support for Cooperative Design in which they theoretically defined cooperative design as a type of cooperative work. However, in contradiction to Englebart’s unified vision of computer augmentation to group work, they warned in their paper against the generalization of solutions in one domain of cooperative work to another.

1960 1970 1980 1990 2000


• 1990: Bryan Lawson authors two chapters in his book How Designers Think titled Designing with Computers and Designing with Others

1960 1970 1980 1990 2000


• 1990: William J. Mitchell coins the term society of design inspired by Marvin Minsky’s 1985 society of mind

1960 1970 1980 1990 2000


• 1990-91:Carl Tollander publishes a chapter titled Collaborative Engines for Multiparticipant Cyberspaces in Michael Benedikt’s book CyberSpace: First Steps. In this chapter Tollander describes a collaborative cyberspace as metric space influenced by the actions of multiple participants. He defines collaboration as a “set of operations over a set of cyberspaces, in which a group of selective influences under the control of the participants direct the evolution of space.”

1960 1970 1980 1990 2000

Michael Benedikt


• 1992: Jerzy Wojtowicz, James Davidson and William Mitchell coauthor a paper in the proceedings of the Association for Computer-Aided Design in Architecture (ACADIA) titled Design as Digital Correspondence (Wojtowicz, Davidson and Mitchell 1992). It is the first paper in an ACADIA conference that discusses the potential of computers as aids for collaborative design. The paper discusses a case study in which students in two studios at institutions a continent apart were asked to co-design a project using a shared electronic bulletin board to post design artefacts (using the FTP protocol), review and exchange comments using electronic mail and speakerphone, and conduct an electronic, long distance jury.

1960 1970 1980 1990 2000

Virtual Design Studio Logo


• 1993: The field begins to expand rapidly• Some numbers:

– CAAD Futures 1993: A special session on cooperative design with 3 papers:» Maher, Gero and Saad» van Bakergem and Obata» Bhat, Gauchel and Van Wyk

– Conferences in Europe, especially those addressing Design Decision Support Systems and Cybernetics begin to focus on Collaborative Design

– CAAD Futures 1995: Two sessions, 14 papers total on the topic– ACADIA 1995 conference: Computer-supported cooperative design is formally

identified as a research topic that is solicited in the call for papers– ACADIA 1999: 9 papers on the topic– ACADIA 2000: 5 paper on the topic– ACADIA 2001: 4 papers on the topic

1960 1970 1980 1990 2000


• The field still has very few books dedicated to the subject. In 1995, Jerzy Wojtowicz edited a relatively modest manuscript titled Virtual Design Studio that included essays reflecting on the topic of conducting design studios at a distance

– The manuscript also included documentation of the collaborative Virtual Village Studio Project (VVS) conducted by Harvard University, University of British Columbia, MIT, and the University of Hong Kong. The project to date remains as one of the largest prototypical implementations of cooperative design studios.

• In 1996 William Mitchell publishes City of Bits. Discusses the nature and potential of an interconnected world

• Four years later, Mitchell publishes a sequel titled e-Topia in which he turns his attention to the evolution of the city under the influence of the various technologies especially e-commerce

• in 2000, Stephen Scrivener, Linden Ball and Andrée Woodcock edited and published the proceedings of the CoDesign 2000 conference held at Coventry University that included fifty papers on the topic at hand. The book is an indication of the maturity of the field and is a good survey of the various sub-topics and themes currently being pursued in this area of research.

1960 1970 1980 1990 2000

Then and Now

1963

“ The Computer-Aided Design System should be capable of carrying on conversations with, and performing computations for several designers at several consoles substantially all at once.”

- Steven Coons

2001

“ In order to collaborate during an architectural design process there is a need for a system, which provides for synchronous work sessions of multiple design parties.” - Martijn Stellingwerff and Johan Verbeke (ACCOLADE Book)

Misconceptions about CSCD

• Cooperative design is one thing

• The more the better

• We are all team players

• Two heads are better than one

• The open floor plan

Collaboration Hierarchy

Design Settings

Artifacts

Architects-In-Action

Place = Behavior

Lone Hero

Immersion

Hierarchy

Artifact

Gaze

Design Worlds, Collaboration, Hierarchy

Intended Mode of Use

Mode o

f C

reati

on

Artifacts

Drawing Pictures of Processes

The Basic Elements of Collaboration

Flow of Artifacts, Tasks, and Proposals

Common Protocols of Interaction: SYCODE

Ann ArborNeXT OS (Mac OS 10)

AppKit and Objective-CDisplay Postscript

Hong KongSGI

Pure CX Window System

Categories of Groupware

• Synchronous vs. Asynchronous

• General Purpose vs. Domain-Specific

• Private Channel vs. Internet Protocols

• Peer to Peer vs. Central Server

• This section describes two experiments:– Adapting domain-specific tools to a different domain– Adapting general-purpose tools to a domain-specific problem

• The problem: Synchronous Distributed Design Reviews

Background and Motivation

• Design reviews are one of the most important forms of pedagogical communication between design instructors and students (Cuff, 1993).

• Talking and Drawing are the two most fundamental components of a language of design (Schön, 1983)

• Justification for the design studio teaching strategy often relies on the aggregate studio culture created by successive shared and overlapping design conversations.

• Studio faculty occasionally travel, or support practices in two cities, taking them out of town on a weekly basis. Distributed design reviews would be a great boon.

• The ability to use the Internet to involve remote expertise at a minimum cost would significantly expand the pool of candidate reviewers.

A Matrix of Possible Design Review Settings

We Have The Technology

• High-bandwidth communication network (Actually, we just used a T-1 line)

• Mature collaboration software (Microsoft NetMeeting, Webex.com)

– Voice over IP– Shared Applications– Text Chat– Shared Whiteboard and Annotation– Video

• SmartBoard:– Large digitizing tablet/white board– Synchronizes with a projected image– One can write with virtual pens– One can erase with a virtual eraser– One can use finger to click on buttons

and drive the GUI– Result is a 2-D Projected Cybrid (Peter

Anders): A surface with an overlapping physcial and virtual condition.

The Six Million Dollar Man © MCA/Universal

http://www.scifi.com/freezone/audiofiles/bionic_man_theme.au

Modifying Gaming Engines

General-Purpose Groupware: Microsoft NetMeeting

General-Purpose Groupware: Webex.com

General-Purpose Groupware: Groupboard.com

SmartBoard

Video Signal

X,YPen/Eraser/MouseMouse Up/DownDouble-click

Rear-Projection Screens

Video

Top Ten Problems

1. Shadows. Need rear-projection screens.

2. Netmeeting/Messenger is platform-specific. (Webex.com is promising, but not free).

3. Audio Feedback Problems. Headsets or audio testing ahead of time.

4. Voice-Over-IP Latency/Lag. Faster network.

5. Security (Firewall) prevented collaboration. Needed to establish a secure Virtual Private Network (VPN)

6. Local jurors almost never went up to the board to sketch. Used laser pointer which remote juror could not see. Need multi-user wireless cursor/annotation control device.

7. Body language/gestures not transmitted. Video/Avatar/Telepresence.

8. Bandwidth limitations (animations/video). See #4.

9. Lack of familiarity. Introduce technology ahead of time.

10. Glare (Hotspot) from projector. See #1..

Top Ten Successes

1. Effective Discussion/Reviews

2. Technology Disappeared

3. Intuitive Interface1. Student stands next to artifact2. Student interacts directly with

artifact

4. Voice and graphics synchronized

5. Non-destructive sketching a boon

6. Students did not need to prepare more for a distributed review

7. SmartBoard worked for both co-located and distributed reviews

8. Set up is portable/moveable

9. Cost-effective, saves air travel costs.

10. Time zone difference was advantageous

The Ten Commandments

1. Start Early / Plan Ahead

2. Test. Test. Test.

3. Know Thy Neighbor

4. Use Back-Channel Diplomacy

5. Adjust Expectations

6. Keep it Cozy

7. Know Thy Software

8. Encourage Symmetry

9. Use Big Pipes

10. Have a Plan B … and C (aka Graceful Degradation)

Summary

• Despite inherent difficulties, distributed design reviews provide an invaluable opportunity

• Fundamental challenge is to understand the degree to which distributed reviews are, or are not, similar to traditional face-to-face reviews.

• Currently many distributed reviews occur at the same time (synchronously). Asynchronous web-based design reviews have been gaining popularity.

• Ergonomics of review space, lighting, acoustics, capture of information is important to an effective review

Domain-Specific Groupware

• Collaboration is more than meeting

• Collaboration is more than co-drawing

• Collaboration is more than shared control

• There is a need to invent a protocol of interaction for collaboration in architectural design

Three Web-Based Collaborative Systems

• Track 2: Design and implement prototypes of collaborative systems that address the following issues:

– Collaboration– Competition– Team Hierarchy– Access Privileges– Social Awareness– Information Filtering

The Three Stooges “Larry”, “Moe”, and “Curly”

Michael Bellesiles, Tim Lambert, Jayson Blair

Case Studies

• Creative design activity is multi-faceted and includes the activities supported by the systems described here. All systems described here use a three-tier object-oriented, web-based scheme coupled with a relational database for server-side storage. The first system integrates this technology with Java-based tools for synchronous web-based collaboration

WebOutliner

• Uses WebObjects and Java Technologies

• Object-Oriented– Model/View/Controller– Encapsulation– Polymorphism– Inheritance

• Hierarchical Objects (Spaces)

• Seamless Asynch & Synch. Collaboration

WebOutliner: Initial Screen

WebOutliner: Expanded Program

WebOutliner: Toolbar

WebOutliner: Editing

WebOutliner: Editing

WebOutliner: Item Detail

Synchronous Collaboration

Summary: Collaborative Space Programming and Design

• This tool allows members of a design team to collaboratively specify a hierarchical spatial program for an architectural project

• The represented artefacts have built-in intelligence that allows them to respond to user actions and manage their own sub-artefacts

• Supports synchronous collaborative design by linking each item in the spatial program to a detail page that allows file uploading, real-time group marking of images, and textual chat

• By being artefact-based, the system allows sub-groups to meet privately and work on parts of the overall shared workspace un-distracted by what others are doing

Prototype 2: Double-Blind Peer Review System

• This tool allows a group of participants to submit competitive entries for double-blind peer review

• The system allows the participants to register their entry and submit it anonymously using only a unique registration number

• Reviewers are invited and assigned entries to review online and are offered an online form that allows them to score the entry, make other recommendations and give public feedback to the authors of the entries as well as private feedback to the administrators

• While the same entry may be assigned to multiple reviewers, reviewers do not know who else is reviewing that entry or even other entries.

• This social-unawareness built into the system ensures fairness and lack of bias by reading other reviewers’ reaction to the same entry.

• The system illustrates that a common goal, the assembly of a set of successful entries, is sometimes achieved by competition rather than collaboration.

• The system clearly defines a hierarchy of participants (entry authors, reviewers, and administrators) and ensures social unawareness and privacy when needed

• Tested twice for ACADIA 2001 and ACADIA 2003



Prototype 3: Digital Asset Management System

• ViSTA, a Virtual Slide Tray Archive, is a digital asset management and display system designed for education

• The system enables instructors and students to search, select, sort and save in virtual sets (called trays) a database of digital assets

• Once registered using a password, the students’ ViSTA homepage automatically displays the courses they are registered for and the associated trays for that particular course

• The system illustrates the need for both asynchronous and synchronous modes of work as well as a clear definition of group hierarchy




Summary of Contributions

• The body of work in presented here:– Critically traces some of the early ideas and misconceptions that have filtered to

current thinking about these topics and refutes them based on additional literature review, participant-observer study, building and testing and analyzing software prototypes.

– Analyzes, categorizes and emphasizes the role of artifacts rather than place and scheduling as enablers for collaboration in architectural design.

– Distills a conceptual framework and set of basic representations that others can use to develop collaborative software.

– Refutes the notion that general-purpose tools are sufficient for collaboration and calls for domain-specific solutions to domain-specific problems by testing the potential and limitations of synchronous general-purpose tools.

– Illustrates the database schemas, algorithms, and interfaces needed to address issues such as hierarchy, competition, social unawareness, and information filtering.

– Implements several examples of domain-specific collaborative systems and deploys them in real-life situations. Systems developed by the author have been tested and used by hundreds of real users over the last 3 years.

– Refutes the notion that collaboration is one thing and thus can be solved by one integrated system. Rather, the assertion is that collaboration patterns are universal and thus software patterns can be repeated.

Concluding Remark

• Through a survey of the history of computer-supported cooperative work in architectural design, the conduct of a participant-observer case study, and the design and study of several example implementations, this work challenges the unified and integrated approach to supporting cooperative design. Just as large integrated CAD systems have failed to support design except in the rarest and most restricted of domains, integrated CSCD systems if pursued will fail to address the complexities and subtleties of cooperative design. Instead, this dissertation argues for a domain-specific and task-specific approach that solves one or a small number of problems at once. Doing so requires careful task and user analysis. That does not mean that solutions are not generalizable. On the contrary, the case studies illustrate how a fundamentally similar object-oriented framework can be re-used and readapted for solving different problems. By following a component-based approach, one can easily re-assemble a new system by selecting, modifying and adding standardized components. The breaking down of the design of the system into components is what will ensure its ability to adapt to change. Finally, the reusability of components like everything else will depend on good design

Documents

A Framework for Collaboration in Architectural Design