The first breakout
session focused on surfacing what tools are currently used
and why. The stated goals of this session were to:
- Compile a list of the tools currently
used in building collaboratories, in order to get a map
of the current tools and technology landscape.
- Shed some light on the current
involvement of the collaboratory community in the development
of the tools they use.
- Build common ground for the following
to initiate conversation around this topic included:
- Which tools did you make that weren't
used? Which tools that you didn't make would have been used?
- Based on your real-world experiences,
what have been the biggest mistakes you have made in choosing
tools and technologies in collaboratories you have built?
- What are categories and conceptual frameworks
that you use for organizing and thinking about these issues?
also brought up questions about the role of the collaboratory
community in the development of the tools and technologies
used in the community, such as:
- What tools and technologies are we 'driving',
or 'spinning off', which are we 'using'?
- Which specifications or standards are
reaching into our development? What's their relative importance?
- Would it be valuable to have a 'Collaboratory
Open Source' tool list and what would be on it?
An observation arose that we need to be
aware of the various levels of granularity the group could
focus on. For example, with UARC, should we mention the Java
Applet, or the higher-level framework?
Some talked about tools developed in-house
vs. those commercially developed. Developing tools in-house
often allows for the tools to be extended, without breaking
the existing capabilities. On the other hand, in-house efforts
suffer from rarely having the resources to maintain the tool
beyond its initial development, whereas commercial tools are
hopefully externally maintained, and upgraded. Efforts to
be platform neutral rules out a lot of commercial tools that
might already have the desired functionality, but only on
A problem mentioned with commercial tools
is that the company that develops the tool does not necessarily
have the "business interests" of the users in mind
- the business drivers of the company developing a commercial
tool are not those of most collaboratory researchers. This
has been known to result in a company dropping their support
of an aspect of the tool that was key to the operation of
one of the groups using the tool. (For example, in the case
of Internet2 and Microsoft, Microsoft dropped their support
of MPEG2, while Internet2 relied on MPEG2 for some of their
Discussion of these tools often hit upon
the subject of interoperability between tools. Chat tools
were an example of a functionality implemented with many variations
(AOL/Yahoo/MS instant messengers, Ytalk, MOO, etc.), and getting
them to work together is a significant issue. Habanero was
brought up as a means of getting quick and easy sharing amongst
tools ("collaboratizing applications"), but it does
not necessarily give "deeper sharing" where everyone
is able to work on different parts. Collaboratory tools were
also seen as not generally infrastructure compatible (one
uses Habanaro, one uses Group Kit, etc). And there is a standing
need for means of single security and single sign-on.
The workshop participants came together
for a group discussion after the breakout sessions. The group
quickly noted that it was unclear how to appropriately distinguish
between tools and capabilities, and between capabilities and
Defining what was meant by the term "collaboratory"
was a topic the participants kept returning to during the
workshop. Points raised included:
- Can you have a collaboratory that
is used only by individuals?
- What if people use a tool, one-at-a-time,
and then talk about it?
- Seems there can be collaboratories
- Hierarchies of collaboratories -
larger groups of collaboratories splitting up into smaller
- People are often in multiple collaboratories
- People can participate in multiple
roles by way of collaboration. They can be a leader
in one, an observer in another, and a participant in
- People drift in and out of groups,
drifting into clumps that have varying degrees of persistence,
size, rate of formation and dissolution, etc.
- Question of whether the classroom
is a collaboratory
- Abowd doesn't treat classroom as
collaboratory, but would when technologies move to meeting
- Hardin thinks distance education
is a collaboratory
- The DOE tends to see collaboratory
as access to an instrument (microscope, radar, whatever)
- What is the collaboratory and
what is the pre-existing community?
- Is it the job of the collaboratory
to create a community, or does the collaboratory assume
- If you make the job also making
the community, that makes it that much harder
From this difficulty with defining exactly
what a collaboratory is, arose the observations that the technologies
commonly used in collaboratories were not necessarily serving
a need that was specific to a collaboratory, but were meeting
a more "general human need." Further, the collaboratory
community was not usually creating new technologies, but instead
finding uses for technologies already out there. There was
the sense that this was a chicken and the egg situation, where
it was uncertain whether the tool was developed and the use
emerged, or if the need gave rise to the tool.
Someone proposed that the job of the collaboratory
community might be to create "ease of use" amongst
these tools, and that one of our major roles is "system
integrators." But there was concern in the group that
there is more to the community's role than system integration.
There was mention that our role was to play steward to the
collaboratories - taking care that all the elements of the
were given attention. Others said that system builders build
for what we need now, where collaboratory builders are charged
with building what we need in the future - more of a moving
Discussion turned to what is "best"
for collaboratories. Should a collaboratory aim to exploit
the tools available on the market? Is there any sub-set, standards,
or specification that this group could agree on? Ideas included:
- Seeing the development effort
from collaboratories as a middleware initiative.
- Pushing for NSF funding for some
sort of organization that would take care of needs that
wouldn't be met by commercial entities
- Encouraging a business to develop
robust tools, something that can be hard for a small group
- A "Red Hat"-like
bundle of collaborative software.
- An open source collection
of modules and tools that could be shared and developed.
- A start-up servicing the
needs of the collaborative community?
- Build a common platform
- Develop the functionality
and allow customizable interfaces.
Then there was continued discussion
on whether scientific researchers have significantly different
needs than the business/software development community. And
as the option of reliance on commercial tools resurfaced,
someone offered that commercial tools do 90% of what they
want, but there is no way to add the additional 10%. They
felt this was a long-standing dilemma.
Tools Being Used
- A lot of client side tools, developed
in-house, being able to extend tools without breaking existing
- Java in UARC, HTML, in SPARC
- More synchronous than asynchronous.
- On the back end, folks are able
to do a lot more with outside tools (Servlets, image processing,
databases). More control on the server.
Tools Which Were
Built But Never Used
- Distributed Meeting Capture System
- A web interface that allowed users to search meetings
they've been at. Required explicit actions (a new skill)
to set anchor/index points, not clear why anyone would want
to review meetings, does work well if someone is explicitly
tasked with creating index points (like a court recorder).
- Federal Emergency Management
system. The tools were only used in emergency situations,
and thus put too taxing a demand on people's recall, so
people fell back on what they knew.
- Usenet - physicists wouldn't
use it because it was too passive and time consuming.
What follows is the list of tools the different
- Chat Tools
- Collaborative Data Viewers
- Conference Call Servers
- Custom portal
- DocShare: file sharing system, back-ended
- Electronic laboratory notebooks
- Electronic notebooks
- First-person shooters
- GroupKit - Groupware prototyping
- Java Shared Data Toolkit (JSDT)
- Mbone (Multicast Backbone)
- MUDs and MOOs
- Outlook I-calendar
- Rear View Mirror
- SmartBoards/ shared whiteboards
- Threaded discussion tools
- Video bridges
- Vitria (workflow)
- VNC (virtual network computer) - AT&T
- Web portal
- WebCT (course management system)
- WebDAV Protocol
the main summary page)
Some items mentioned seemed to fit better
into the category of "technology" vs "tool"
as some of the items were the things which the tools were
composed of. Here is a list of the technologies mentioned
during this breakout session:
- AccessGrid Hardware
- Cameras (video cameras, web cameras,
- DAV standard
- GRID services
- MS Hailstorm
- H.323, H.320
- Jakarta project
- Java messaging service
Still other items mentioned seemed to be
better described as being infrastructure components. Here
is a list of the infrastructure components mentioned during
this breakout session:
- Cell phones
- Conference bridges
- Directory services
- Web servers
- Wireless networks
The participants also listed the various categories that these
tools could be divided amongst, or the dimensions upon which
they vary. Here are the categories/dimensions mentioned during
this breakout session:
- Always on / session oriented
- Asynchronous / Synchronous
- Custom Built Application / Off-The-Shelf
- Degree of anonymity
- Degree of configurability
- Degree of interactivity
- Degree of domain independence
- Developer/end-user tools
- Formality or fidelity of session capture
- Functional capabilities / Technologies
- General purpose / special purpose
- Informal / formal
- Information sharing / interactive collaboration
- Level-of-sharing (pixels/events, view/control)
- Level of security (authentication, access
- Long-term / short-term
- Natural, invisible / intrusive
- One-to-many, many-to-one
- One-to-one / Large group (measuring
session or community size)
- Open source / proprietary
- Person to resource (information, program)/
person, instrument (facility)
- Protocols / standards
- Public / Private
- Resource rich (PC) / resource challenged
- Serendipitous / planned
- Service / Technology
- Simple&Robust/Feature Rich
the main summary page