Science of Collaboratories logo - link
 
 
 
An alliance to advance the understanding of collaboratories
Science of Collaboratories
   
   
 
The Technology Issues Facing Collaboratories and Building a Collaboratory Technology Infrastructure: Today and Tomorrow

 
 

The third breakout session attempted to address two basic issues, both related to the challenges and opportunities in future development of collaboratory technology.

Questions raised to trigger discussion included:

  • What kind of mismatches exist between the reality of collaboratory technologies, and the ideal representation of these technologies?
  • What are the areas in which collaboratory R&D could make a difference? What advances are needed?
  • What would you recommend as deployable technologies to someone creating a collaboratory?
  • Is there consensus in our views?


The participants generated many recommendations for collaboratory designers. They are listed here, with the assumption that the advice will vary based on what kind of collaboratory is being built.

  • Don't build until you know what is already out there.
    • Some current technology does much of what is desired, document sharing, for example.
  • Build for the web
    • A nice feature is when any user can participate through a vanilla browser.
    • Making the access through the browser is nice, as the system can then be constantly updated.
    • There are benefits and risks to this, but consider providing at least minimal functionality via the web.
    • There can be many problems with standard software installs, and the web provides a "work around"
    • We can assume browsers and servers will still be around in 3-5 years.
  • Do things you would do in any normal development project.
    • Many of the issues that arise in collaboratory development are the same ones faced in any software development project.
    • Employing standard software development methodologies is a good starting point.
  • Practice careful analysis of the needs of the users
    • This should go without saying, but rarely happens.
    • Spend all the time needed to find out what the needs are
    • Consider rapid prototyping with many cycles and real users.
    • Make sure the development team has an understanding of the science that is being done.
      • The metaphor of the tools being developed needs to match with the metaphor of the work environment being supported.
      • Though one could argue that the development team only needs to make sure they understand the work process - not the intricacies of all the science that underpins it.
  • Find someone to be your technology champion and identify and work with the opinion leaders
    • Additionally, identify early adopters who will give feedback and be more forgiving.
  • Make it compatible with what your user base is currently using
    • Integrate into the user's environment, not the other way around.
  • Start with something you know will work
    • Make sure the initial technology will not scare your users off.
    • Then incrementally add services (possibly like plug-ins, on an as needed basis).
  • Make sure there is a low cost of entry, it is easy to install, and you use standard platforms, so they don't have to purchase much.
  • Ease of use is very important, as this will probably not be their primary tool
  • Build in logging capabilities from the start.
  • Build in a parallel back channel, so there is an alternative to talking on the primary channel, either for repair if there is a break down, or for discussion or announcement of less important information.
  • Pay attention to standards, both real (w3c) and de facto (IE5.0)
  • If building, consider something that can go commercial, or be used by a consortium of universities.
  • When deciding to use - or not use - a tool, consider its extensibility
  • Keep in mind new technologies
    • PDAs, etc.
  • Go with Java
    • Ease of development
    • Multi-platform
    • Will probably be a force in 3-5 years, even with Microsoft's C# around.
  • Go with Open Source
    • With the rise and fall of companies, one could think open-source initiatives might last longer than supported initiatives.
    • Organizational problems, as companies might not allow open development.
    • Support problems, as there is a tend to need good local support.
    • Promise and practice of contributions from the larger community is a big plus, especially for modular construction of collaborative apps.
  • Plan for how you will support your users. Make sure there are resources devoted to this.
  • There was a suggestion to reduce platforms, to insure software will work on all the machines in use.
    • Alternatively, tell users that they can use whatever platform they like, but that they have to install some universal plug in (like RealPlayer, or something like that).

· Longer-term research issues:

  • Distributed, collaboration-aware operating systems
  • Server vs. peer-to-peer services - how to design software that can do both, that can decide which it should use?
  • Can software intelligently make decisions about QoS? Can the collaboratory itself help decide what services to offer, and how to offer them?
  • Lots of login/authentication issues, as the security needs to be flexible enough to work with a variety of environments, working with a variety of authentication systems.
  • How to always, automatically, capture context.
  • As a collaboratory can be run on all sorts of tools (PC, PDA, cell phone, etc.), how can the views of the data be effectively modified, as one steps down to hardware with fewer resources?
  • Developing highly nomadic rapid response collaborations - such as in fire fighting in huge forest fires, where people are distributed over a wide geographical space (from the individuals point of view), and they need to be coordinated, but also there can be simulations of the fire running (at NCAR or something) where there is a lot of computing power, but there can be fast data transfer to the people in the field.
  • Converging over divergent views
    • If one does not see the same display (view) what are the implications?
      • How does one "point at" the same thing, as someone else, over different views?
    • How to show the relationship between different views?
  • Managing attention in collaboratories
    • Discovering areas of interest in all the data
    • Have agents find things of interest?

Participants also spoke of a need for a funding model that recognizes the need for building middleware. Middleware is one of those things that isn't necessarily commercially viable, and it isn't one particular person's problem. As a result there is a need for support of such efforts, from a funding perspective. The European Union is funding some projects that they expect to be "commercially viable", but this doesn't necessarily mean that they will make lots of money - it could mean it is used widely by universities. There is also a reluctance to fund any thing that needs maintaining over a long time.

The Glue - making the tools work together…

  • Main struggle of collaboratories is to put together a correct set of technologies, not developing the individual technologies. (Find video, whiteboard, remote instrument, chat, notebook that share a single security mechanism, logging/persistence mechanism, launching mechanism, etc.)
  • There aren't really any common glues
  • We need to make the glue to have the pieces work together.
  • Integration technologies
    • Directory services, security models, XML
    • Using access grid
  • Ex: in UARC - CBE as a kind of glue

Observations

  • The most interesting thing about a collaboratory is that the captured data might be mined and analyzed to discover "new knowledge"
  • Pretty cheap to save everything. Just save everything and work on creating tools to analyze that data. Conventions on note taking took a long time to develop
  • Unintended use - using a game for other interactive tasks
  • VOIP is problematic - lots of people are trying to do this - but they aren't very successful, lots of bandwidth/network problems, firewalls drop too many packets.
  • Granularity
    • B1 - Granularity of understanding
      • Ex: should one approach UARC as a Java Applet or a frame work?
    • Granularity of capture
      • Ex: Chat - how much do you log - when is too much logging taking place? Do you save enough to do sync-ed replay?
  • Social Issues, such as with group authority, chain of command, policies - these are areas that can cause difficulty.
  • That there is a presumption that the systems are likely to break down.
    • Schizophrenic attitude: we both expect it to work, and expect it to break.
  • Someone is always awake - different work environment.
    • Doing work in a collaboratory at night in North America, while there are people awake in Europe, is a fundamentally different space than working alone in a lab at night.
  • Users don't usually ask explicitly for things such as "context" - these needs are interpreted from what is asked for.
  • Nestor noted a reluctance in many researchers to do work with collaboratories, but these same people do imagine they will be doing this stuff a few years from now. (They are reluctant to be early adopters.)
  • People want a collaboratory because it makes their collaboration visible. They are sometimes empire building, as, if you have a new tool, you have some advantage over your peers.
  • In business, there is a concern over the ROI for IT, but the lesson is that if they don't have the right IT, they are seen as not being "with it," and are therefore less desirable.
  • New tools might be thought badly of if they don't have remote access built in.

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