Science of Collaboratories logo - link
 
 
 
An alliance to advance the understanding of collaboratories
Science of Collaboratories
   
   
 
The Tools and Technologies of Collaboratories: What We Are Using Today

 
 

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 breakout sessions.

Questions raised 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?

The facilitator 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 limited platforms.

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 apps.)

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 services.

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 within collaboratories
    • Hierarchies of collaboratories - larger groups of collaboratories splitting up into smaller collaborative groups
  • 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 many more.
    • 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 space
    • 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 a community?
    • 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 Borromean rings 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 target.

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.
    • NSF, DOE initiatives
  • 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 of researchers
    • 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 In Collaboratories

  • A lot of client side tools, developed in-house, being able to extend tools without breaking existing capabilities.
  • 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 groups generated:

  • AccessGRID
  • Apache
  • Browser
  • Chat Tools
  • Collaborative Data Viewers
  • Conference Call Servers
  • CourseInfo
  • CourseTools
  • CU-See-Me
  • Custom portal
  • DocShare: file sharing system, back-ended by DAV
  • EduPers
  • Electronic laboratory notebooks
  • Electronic notebooks
  • First-person shooters
  • GRID
  • GroupKit - Groupware prototyping
  • Habanero
  • Java Shared Data Toolkit (JSDT)
  • Labview
  • Listservs
  • Mbone (Multicast Backbone)
  • MUDs and MOOs
  • Netmeeting
  • Outlook I-calendar
  • Placeware
  • Rear View Mirror
  • SmartBoards/ shared whiteboards
  • Threaded discussion tools
  • Tomcat
  • Video bridges
  • Vitria (workflow)
  • VNC (virtual network computer) - AT&T
  • Web portal
  • WebCT (course management system)
  • WebDAV Protocol
  • WebEx
  • Websphere
  • WorkTools
  • Zope

(back to 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
  • Applets
  • Cameras (video cameras, web cameras, etc.)
  • CAVEs
  • CGIs
  • COM
  • CORBA
  • DAV standard
  • FTP
  • GRID services
  • MS Hailstorm
  • H.323, H.320
  • HTTP
  • Jakarta project
  • Java
  • Java messaging service
  • LDAP
  • MPEG2
  • Perl
  • PHP
  • RDF
  • Servlets
  • SIP
  • SOAP
  • SQL
  • SSL
  • TCP/IP
  • VOIP
  • XML

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
  • Databases
  • Directory services
  • Hardware
  • Laptops
  • Networks
  • PCs
  • PDAs
  • Satellites
  • Telephone
  • Web
  • 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 control, encryption, …)
  • Long-term / short-term
  • Managed/personal
  • 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)
  • Peer-to-peer/server-based
  • Persistence
  • Protocols / standards
  • Public / Private
  • Resource rich (PC) / resource challenged (pda)
  • Serendipitous / planned
  • Service / Technology
  • Simple&Robust/Feature Rich

back to the main summary page

 
 

 

 
 
         
    
  Home | About SOC | Workshops | Resources | News & Events  

University of Michigan Logo

University of Michigan

School of Information Logo

School of Information University of Michigan