Science of Collaboratories logo - link
 
 
 
An alliance to advance the understanding of collaboratories
Science of Collaboratories
   
   
 
Capabilities Needed by Collaboratory Users

 
 

The second breakout session focused on the needs of the users of collaboratories. Questions raised to initiate conversation included:

  • What capabilities do your users need to collaborate successfully?
  • What capabilities are not currently supported?
  • What do you expect your users will want to do collaboratively 3-5 years from now.

One breakout session grouped user's activities into different general types, such as observation, publication, instrument building, accessing resources, finding others to work with, socializing, coordinating the "invisible work", etc. Within these general types of interactions fell the various particular services, or functionalities, the users of collaboratories might need. Other groups used different ways of organizing lists. The combined result is shown below. Items from the discussion that appear to focus more on how collaborative software should operate (versus what capabilities it should provide to users) have been collected in a second list.

  • A place to keep notes, encapsulate data, viewers, etc.
  • Access Control
  • Ambiguity in access control (mirroring the informal/dynamic/fuzzy nature of rules in the real world)
  • Annotation ability
  • Announcements and notifications
  • Application sharing
  • Archiving
  • Authoring credit, intellectual property
  • Awareness of people, events, schedules (awareness system)
  • Awareness/notification of anything interesting happening in any collaboratories I am involved in (not wanting to waste attention until something of interest arises)
  • Calendar systems
  • Capture and replay - Automatic context capture and retrieval
  • Capture and replay - capturing lectures
  • Capture and replay - capturing live events
  • Capture and replay - multi-scale records
  • Chat
  • Collaborative browsing of large data spaces, each with different views
  • Collaborative games
  • Collaborative operating systems
  • Collaborative workspaces
  • Conferencing - audio/video
  • Connectivity
  • Course management
  • Customizable portals
  • Data acquisition
  • Data analysis and interpretation
  • Data entry
  • Data integration
  • Data mining
  • Data sharing
  • Defining context
  • Digital Libraries
  • Directory services
  • Disconnected service
  • Discussion tools
  • Distributed authoring and editing
  • Document/file sharing
  • Dynamic mobile awareness - for wherever one is and wherever one's colleagues are.
  • Electronic workspace where collaboration is an option
  • Email
  • Expertise finding
  • Facility management
  • Find people who also do 'X'
  • Group-to-Group communication
  • Haptic force-feedback
  • Increase in awareness with no increase of surveillance
  • Indexing sessions - using logged chat at a point of entry into the session
  • Informal collaboration (support for serendipity - spontaneous meetings, introductions, etc.)
  • Information about people and resources
  • Information repositories
  • Instant messaging
  • Instrument control
  • Integration into current work environment and toolset
  • Intellectual property management
  • Interface to remote instruments
  • Internationalization
  • Interoperability
  • Knowledge management
  • Large-format presentations - 3 screens
  • Large-screen, beyond desktop, beyond web
  • Launch remote computations
  • Live video streaming
  • Local version - disconnected services
  • Location technologies
  • Logging
  • Login facilities
  • Meeting support
  • Messaging
  • Metadata
  • Multimodal interaction (e.g. voice + gesture + text)
  • Multi-tasking
  • Persistent chat - to get earlier messages when you join a chat
  • Personalization
  • Presentation support
  • Providing application services (ASP) for collaboratories
  • QoS Control (e.g. email doesn't stop crucial experiments)
  • Resource information services
  • Resource naming
  • Resource scheduling (ex: instrument time)
  • Role-aware functionality
  • Scheduling
  • Search capabilities
  • Secure connections
  • Security
  • Security management
  • Seeing where information has been
  • Seeing who receives info
  • Selective sharing of information and resources
  • Session translation
  • Shared authoring
  • Shared data viewing
  • Shared visualization
  • Simulated worlds
  • Single security, single logging abilities
  • Small and light hardware - to carry to remote locations
  • Spontaneous encounters
  • Storage facilities
  • Summarization (e.g. highlighting record of collaborative interaction so it doesn't take 8 hrs to watch.)
  • Summarization services ("what happened in the collaboration in the last 7 years?")
  • Support for sustaining collaboration through the transition between formal and informal connections (e.g. "meeting in the hall after the real meeting")
  • Synchronization tools
  • Synopsizer of system resources
  • Tele-control
  • Tele-observation
  • Tele-operation (remote control - instruments, cameras, etc.)
  • Third party introductions
  • To do/ task list
  • Tracking how data is used and altered
  • Translation
  • User ability to administer their own appearance in the system
  • Versioning (journaling)
    • Pedigree - tracking status of data through all points of simulation/modeling - who has touched it, what's been done, all metadata
    • Auditing - need to track who has used what.
  • Video conferencing
  • Video link
  • Virtual environments (3-D virtual labs, shared worlds, public spaces, shared spaces)
  • Virtual Reality
  • Visualization tools
  • Visibility - knowing who has access to information
  • Voicemail
  • Web-based collaborative services
  • Whiteboarding - shared online whiteboards
  • "Who knows what?" service
  • "Who uses what?" service
  • Workflow management - of the process of mounting slides
  • Workflow management - of the publication process
  • Workflow management - of data through creation, analysis, visualization steps

back to the main summary page

Operational Requirements:

  • Ability to synchronize local versions of software
  • Accessibility
  • Common component framework
  • Ease of use
  • Easy installation and use
  • Graceful degeneration (fallback support) - having teleconferencing, if the video conference doesn't work
  • Help - facts documents, contextual user manuals
  • Instrumentation of environment itself
  • Make A / V management as easy as text
  • Management of user's profiles, roles, groups, etc.
  • Multi-cast
  • Resource updater
  • Simple session management - people in sessions, tools in use?
  • SysAdmin tools
  • Time zone management
  • Treat capture as a service that can be layered on other things that are happening - most are currently custom designed

There was a general recognition that the capabilities desired from collaboratories (and in turn the technologies needed) will vary based on the attributes of the group collaborating (size, etc.).

A number of participants mentioned the importance of having the ability to deal with large data sets, as collaboratories tend to have the side-effect of generating large data sets of conversation, where the participants, their dialog, and the subjects of their dialog (often in the form of shared data) can all be in dynamic fluctuation. Useful access to this data is a needed service that doesn't seem to be fully realized when it comes to such large data sets. People mentioned wanting to have access to not just the artifact, but the artifact history as well, including who transformed it, how they transformed it, and what stages it has gone through.

One approach to surfacing the functionality needed in collaboration was to define what the basics of collaboration might be. Mentioned was the need for:

  • some sort of visualization capability
  • a way to talk about what is being shared
  • flexibility in the communication that is supported
  • control over the view one sees, and the view seen by others
  • the ability to point to shared items, and to select things
  • means for more than one person to interact at a time

There was also talk of what capabilities are important, but are not currently supported:

  • Knowing were information is going and where it has been
  • Controlling where information is going
  • Superior ease of use
  • Lightweight awareness
  • Allowing "real-life" quality social interactions
  • Co-analysis of data
  • Integration of functionality (interoperability)
  • Multi-modal, seamless environments

This exposed the general challenges to providing these services, including making the systems easily accessible, finding how to increase awareness without increasing surveillance, and managing the control of (and knowledge about) the dispersion of information.

Security issues, from firewalls to organizational impediments, are recognized as standing difficulties.

In trying to understand the different capabilities desired by business collaboration versus academic collaboration, some distinctions were proposed:

  • Business
    • Known end-point activity
    • More closely coupled, faster orientation, emphasis on tracking people down
    • Motivation is to reduce novelty and increase efficiency - trying to get economies of scale by repeating what worked.
    • A given organization is likely to have a homogenous set of computing platforms
  • Academia
    • Hypothesis based activity
    • Data intensive - driven by how the data needs to be analyzed, codified, etc.
    • Sometimes the number of people involved in a common goal is fewer than in business - meaning that there is more of a tendency to solitary work.
    • Motivation is to increase novelty all the time (or possibly jeopardize funding).
    • An academic setting is more likely to operate a heterogeneous mix of computing platforms.

Someone raised the question, "will this help me get new funding?" An alternate question was, "will this help me do better science?"

One group began its session by trying to understand who the collaborators are. Where remote instruments are used, sometimes the researchers are collaborating just as much with each other as they are with the operators of the instruments.

Thinking about what elements of the collaborative process could be supported by workflow management - "Experiment" might be very amenable to workflow, where as, "Discovery" may not. There was a cautionary remark that very few workflow systems work well in business, as the processes involved are much more complex than people tend to think.

Someone asked if we even really need to meet face-to-face. They said there is some evidence that junior people can collaborate on the basis of face-to-face meetings of their supervisors.

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