🚀 go-pugleaf

This is to officially welcome you to the CSCAD mailing list
(CSCAD = Computer Supported Collaborative Arcitectural Design)

This message will also be posted to comp.groupware to announce
the mailing list.

I'm going to be the moderator of this group. Basically you send
e-mail to "cscad-list@libra.arch.umich.edu" and I will forward it
to all the participants. If you have any questions please do not
hesitate to send me e-mail. Until now, we have around ten participants.  
However, I'm getting new mail daily.

This group is meant to be a forum for the discussion of the technology  
that is needed to support/enhance collaborative
design in the field of architecture. I will start by including
a couple of messages that I exchanged with W. Michael McCracken:

I'm not sure what you mean by collaboration in architectural design.
I can guess two views; one that you are interested in the social/cultural
aspects of collaboration and how it relates to the field of architecture,
and two that you are interested in the tools necessary to support
collaboration.
The reason I ask, is that the Center for Information Management Research,
a joint center with the University of Arizona's MIS department, is
conducting research in the latter area.
Specifically, at Georgia Tech, we are starting the development of a
collaboration workbench.  The workbench is a tool to support collaboration
of any type.  What we have found so far, is that collaboration tools are
either of the groupware type (general informal collaboration, eg, Lotus  
Notes),
or application specific shared types (like shared editors or shared  
graphics
tools). 
What we are attempting to do is develop a general purpose tool that allows
the user to construct any single or multiple collaboration type.  That way
the natural occurences of collaboration are not precluded due to  
technology.
For example, a shared cad tool that can be created on the fly when you  
decide
that you need help on some particular problem.  Or a shared cad tool, that
has gdss type support when you are reviewing a design with a customer, and
you need to force decisions and capture that process. 
Anyway that's the idea.  Once we get the thing built (we have prototypes  
of
most of the underlying tools already built), we want to experiment with  
the
it, and see how unfettered collaboration really works.
Our philosophy (not based on much other than observation), is that design  
is
design, collaboration is collaboration, and decision making is decision  
making.
Sure there are different representations, different techniques and  
different
tools used to support different application environments, but why not look
at the problem as a need to support the activities of humans, and not  
necessarily
design application specific solutions. 
Sorry to go on like this, but I was trying to explain that we are doing  
some
work that may be of use to you, but you wouldn't see it in any references  
to
architecture, per se.
Michael McCracken, Director
Center for Information Management Research

----
I apologize for taking so long to reply to your message.
I agree that collaboration should be thought of in generic
terms and not in the context of a specific domain (If I understood
your message right!!). However, I found out that the forms/tools/
behaviours are related to what I call "settings." In a study of
an architectural office I found out that the artifacts, tools
and interactions and MO's were directly related to a perceived
sense of setting (meeting room, design studio, one's desk, office,
coffee machine, etc.) The designers/architects related differently,
used and created different artifacts. This convinces me that
general tools will eventually breakdown if they are not rooted
in the situation. Furthermore, the idea of creating tools on the fly
to suit the needs of a CAD problem is interesting, but I'm afraid
it is too optimistic to think that creating computerized tools is
to going to be any easier than molding a tool out of wood or plastic.
The electronic environment will have to be so advanced and flexible
as to predict the functionality required of these future tools and
be able to integrate them within the pre-existing world of tools.

Do you by any chance have any examples of people creating/adapting
tools to fit a novel situation that the original designer of the tool
did not think of? That would be of great interest to me...

Well, I think this discussion could form the beginnings of this
e-mail list. With your permission, I would like to start with
your e-mail message and then this one. I'm going to set up a group
alias and and e-mail address for submission of articles very soon.
I'll keep you updated.

Wassim.

----
You're close (at least I think you understood what I understood, etc.)
Let's start again, and see if you think this will work, remember I'm
testing this out with you as the guinea pig.
Given a variable setting (which you pointed out), people have a tendency
to interact in ways that they are familiar with.  For example, maybe
the chief architect on a project leans over shoulders to see how a
project is going, and calls informal meetings of a few of the designers
as he sees progress or problems.  These informal meetings could occur
around someone's cad station.  Or maybe he is a little more stuffy, and
he has daily project reviews.  Or maybe he is a hard ass and has weekly
full blown presentation style reviews.  All of those examples are
types of collaboration that are independent of design technology, but
are based on particular interaction styles.  My premise is that we
force interaction styles (by building tools to support particular
techniques around design tools), instead of constructing a layer of
interaction mechanisms that adapt to the interaction style of choice.
I'm not necessarily talking about intelligent tools here.
If we could build a layer upon which any tool you choose to use could
be run in a shared environment, or that I could erect other interaction
techniques around (without disturbing the core tool, be it design,
documentation, or whatever), then we have an unforced interaction style.
An example, based on the above interaction examples.
Informal leaning technique.  Why not allow a shared session of the CAD
stuff to occur, with full motion audio and video support so that the
informal guy could have his daily walk through even if he wasn't in
the office. 
The point I am trying to make is that the technology exists (always with
a few limitations) to not create specific environments that we think
are correct, rather to support whatever fits the current mode without
constraints.  Sort of like basing requirements on users needs, rather
than what we think the user needs.

Mike
----
End of forwarded messages...
What do *you* think?....
--
Wassim M. Jabi                            (313) 936-0229
Doctoral Program in Architecture, University of Michigan
2000 Bonisteel Boulevard  Ann Arbor  Michigan 48105-2313
wjabi@libra.arch.umich.edu             NeXTMail-friendly