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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- Go with Java
- Ease of development
- 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
- 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
- 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
- How to always, automatically, capture
- 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
- How to show the relationship between
- 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,
- 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,
- Using access grid
- Ex: in UARC - CBE as a kind of glue
- 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
- 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
- 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
- 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
- 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.
to the main summary page