(Formerly RTA)

Remote Collaboration (RC) was conceived as a means of using technology to enhance the quality of interaction between humans. It was originally applied in the domain of learning, with an initial emphasis on second language acquisition. It has evolved into a collaboration tool that lends itself to many different activities and disciplines, including distributed learning, distributed research, and patient care, to mention just a few areas in which it can promote interaction.

The purpose of this Mission Statement is to set forth the general guidelines under which RC was conceived and how it has evolved with usage. The statement covers initial design considerations and extends through to our current perception of the ways in which RC might prove useful in the future.

Learning is a process that should focus on the learner, not on the instructor. Learning is an active process in which the learner faces new concepts and endeavors to understand them and apply them to tasks that demonstrate the learner’s mastery of the concepts. Teaching, on the other hand, should be focused on helping the learner achieve mastery of concepts. These basic roles sometimes become clouded by pragmatic considerations. In a large class, the instructor cannot provide individualized attention to each student. Lectures are particularly unsuited to individualized attention. Even one-on-one interaction between student and instructor requires a teacher who focuses on the needs and learning modes of the learner.

Distance Learning (often considered as an either-or alternative to classroom learning) also suffers from a lack of interaction that often exceeds that of the large lecture hall, even though technology now exists that is capable of enhancing interaction, even when the people involved are separated both by time and space.

The Remote Collaboration concept arose from some basic pedagogic premises that were formed by years of teaching and facilitating the learning process in a university setting. It is based on three simple premises:

• Learning should be student-centered.
• Learning should be activity-driven.
• Learning should involve timely and informed feedback.

Today’s technology allows us to translate these underlying premises into realities that have far-reaching implications in the learning process. In designing RC, we considered the following additional premises which, while secondary to the underlying pedagogy, nevertheless represent powerful motivations to provide the type of interaction facilitated by RC.

• The Learning Process is often hampered by conflicts of time and place schedules. Learners and learning facilitators often have difficulty in meeting conveniently, resulting in unsatisfactory compromises.
• The growing need for more learning by more people is a powerful force governing the options available for design and delivery of learning today. University students are no longer ethnically homogeneous groups of 18-24 year olds. Demands for learning extend lifelong. New types of workers are needed; old job skills become obsolescent. The numbers of jobs requiring minimal education are decreasing; demands for higher levels of education are increasing. Population explosions further compound these problems, and budgetary considerations restrict options of building more and more classrooms and hiring more highly paid faculty.
• At the same time, technological advances, most particularly computers and the Internet, open the door for creative solutions not previously feasible.

RC grew out of these primary and secondary premises. We conceived of an environment in which the learner would be able to address topics in a fashion that was convenient in time and place, working either independently or with other students, and receiving timely feedback to resolve questions or evaluate completion of tasks along the way to achieving mastery of a subject.

On the conceptual level, we wanted to provide access to information at a time and place best suited to the learner’s needs. We also wanted the information available to be flexible in content, using whatever means of presentation best fit the content and the learning characteristics of the recipient. We felt that some form of interaction, either live or asynchronous, was essential to the learning process. We wanted the learning situation to drive the use of technology, rather than vice versa. We felt that this mode of learning should be available to learners with different levels of skills and with different technological environments.

The initial goal was not focused on a single domain, since the concept was applicable to learning in most domains. While the specific learning needs might vary, the overall requirement of providing a variety of forms of learning content would be applicable to all domains in differing degrees.

Our initial design was also based on one more fundamental principle: we realized that we did not yet fully understand the process which we wanted to facilitate. We were reasonably certain that our design would require significant modification with use, so we were constrained to build a system that would enable us to make changes frequently and as painlessly as possible.

These, then, were the factors that lay behind our initial design of the RC package. They led to a basic approach that has proved flexible enough to evolve as our understanding of the learning and interaction process deepened. In the next section, we translate these design considerations into the working model that guided our implementation.

From the outset, RC was based on several important implementation decisions, described below.

• The package was designed to run on the Internet, using communication protocols appropriate to that environment.
• RC is built using a client-server architecture, with the server moderating all communication between clients. Moderation should include restricting access to authorized members of a class, full control of the messaging, and preservation of dialog generated during the interactive process.
• To the fullest extent possible, RC should be platform-independent, running on different hardware and under different operating systems as transparently as possible.
• From the outset, RC was designed to provide multimedia forms of communication between users. Initially, this criterion meant that we would have sound, graphics, and text. It seemed best to have store-and-forward sound, and to include graphics in the form of screen snapshots.
• An early element incorporated into RC was the provision for non-English character sets to be available in the interactive process.
• RC should provide a collaborative writing tool (which we call textpad).
• There should be a link to course content. In its initial form, this link should provide a user-friendly link to Website URLs.

The RC package originated in about 1994, with two computer science graduate students working on the client and server portions. Their theses, completed in 1995 present the details of the initial implementation (Buechner, 1995, and Hirose, 1995). The package continued to evolve, with some support from the University of California, and it received its first operational tests in language learning courses during 1996-1997. In mid-1997, FIPSE (the Fund for Improvement of Post-Secondary Education) approved a three-year grant for the period October, 1997 through September, 2000. This support led to extended field testing of the package and continued improvement of its features.

A number of interesting issues arose out of the initial uses of RC, leading to several modifications in its design. Sound presented an interesting problem of cross-platform incompatibility: sound is stored and played on Mac, PC and UNIX platforms. each with different formats. Since we were using a UNIX server, it was considered best to create conversion modules for the other two platforms, so that all sound transmission over the net was in AU format, and the clients translated that format into the local dialect. We also realized with use that sound messages were very large indeed, unacceptably slow over modem connections.

Image use opened other interesting extensions to the original design. Not only were there some format problems similar to those encountered with sound, but the ways in which people wanted to use images grew as the opportunity to use images effectively grew.

Accessing other resources related to the class became an important consideration that grew beyond the simple URL approach adopted in the first design.

Finally, the numerous demonstrations of RC to a wide range of potential users greatly expanded our vision of the system. These and other findings from applied use of RC led to a second phase of design, with expanded vision for the most effective use of the concept in an increasingly broad number of fields.

While none of the earlier design constraints were discarded, the overall goals of the program were expanded, leading to a vision of remote collaboration that extended well beyond the original projected use for RC. We discovered that communication between pairs and groups of students was just as important as communication between students and instructors. We learned that the tool was readily adapted to other types of collaboration, including research and consultation. Users wanted to have more flexibility, and we realized that this desire would stay with us during the life of the project.

Early efforts to extend RC were ad hoc, although the basic goals still controlled the priorities established for RC’s extension. We believe, however, that it is appropriate at this stage to define a new set of goals for the RC mission, based on experience gained to date and the many helpful suggestions offered by those who have used the system.

Two important factors have expanded our view of the ways in which RC might be used. The first relates to the rapid expanse of technology, communication, and computer use in today’s society. Communication bandwidth has expanded greatly, and continued expansion of bandwidth appears assured over the next five to ten years, making possible the transmission of volumes of information hitherto considered impractical.

The second factor that contributed importantly to RC’s growth has been the ever increasing visibility of the package, leading to fresh viewpoints from user groups who had not previously encountered such a tool, but who immediately saw ways in which it might be used and enhanced.

From these two factors, coupled with its continued use in second language acquisition, came a new set of design criteria as described below.

Applicability of the Remote Collaboration Concept

RC was originally designed to solve problems in the learning environment. Since communication between individuals separated by time and space is a general problem, the tools that promote communication in the learning environment are also applicable to other domains. The most obvious areas where such collaboration would be helpful are in collaborative research and collaborative design. RC has been proposed to be used in both of these settings. For collaborative research, we have proposed a project in neuroanatomy (Jones, 1999). In the area of distributed collaborative design, we have proposed applying RC to a project involving space ship design (Alvarado, 2000). These and other explorations into expanded use of the Remote Collaboration package have led to new design considerations. We describe each expanded area below.

Graphic Support

Images play an important role in collaboration of many types. Some of the features that have been added to earlier design considerations are:

• Provision for multiple whiteboards visible on a screen simultaneously.

• Ability to display images from files.
• Ability to edit annotations: add, modify or delete individual components.
• Ability to overlay a translucent image onto one that is opaque for purposes of comparison (this feature applies to textual images as well as graphics).
• Addition of free-hand drawing in addition to lines, ovals, rectangles and text
• Modification of display provision to permit snapshots of an evolving screen sequence (animation, results of a model, etc) to be shared with users in a group. User-defined parameters would control frequency of update of the image transmitted.
• Some form of cut-and paste will probably be useful in certain applications.
• Image compression should be an option available at user direction.

Continuous Collaborative Group Support

Many projects extend over a period of time ranging from days to weeks or longer. While RC offers group discussions that can be saved, other features are needed to make this collaboration more effective. After some reflection, we added the following elements to the Remote Collaboration design:

• Pre-definition of a persistent team: A team has a continuity that extends beyond interactive sessions. In the learning environment, an instructor may be defined as a de facto member of such groups.
• Seamless continuity between synchronous and asynchronous communication: Team members will be able to log on, connect to the predefined team, review and edit previous work, and add new materials. If another team member joins the live interaction, they can communicate live; otherwise, single members can contribute in an asynchronous mode.
• Preservation of team transactions: The record should preserve timestamped dialogs, whiteboard, sound, file, and textpad materials generated by the team. Timestamps should document when team members connected and disconnected from the interactive process.

This form of communication parallels in some respects a laboratory notebook, with the important extensions that it is multimedia, shared, distributed and can link to other resources as appropriate. It is more like a continuous record of the evolution of a concept: design, assignment, or project.

Sound

The value of stored sound is sufficiently important that it should be retained. However, in many cases, a live dialog may also serve a useful purpose. RC users should be able to combine these elements, using the option that is most appropriate for the given situation. Sound compression is essential wherever possible.

Links to Other Resources

In its first implementation, RC provided two ways to access other resources: during interactive sessions through the transmission of a URL to other participants; and through the content button linking to web pages outside an interactive session. While web page access is an important component to access, there is a need for seamless access of many other resources. CDROMs are used in many domains to store course content and large databases. Programs may be executed to give users a better understanding of the concepts under investigation. In some settings, automatic invocation of testing software would be desirable. RC should provide easy access to items such as these.

A second functionality urged by users of the current RC package is that of invoking RC from other packages. We recognize the benefits of this approach, and need to explore it in greater depth.

This report summarizes the guidelines under which RC has been evolving over the past five years. At this stage, in early 2000, it appears that the project will be expanding significantly, so this review of design considerations my prove useful as a planning document. Comments are very much needed to improve this document, as we will need to distribute it more widely once we agree on the overall design.

Alvarado, Sergio (2000), "Coaching Technical Teams: An Intelligent Distributed Environment for Collaborative Space System Design," proposal submitted to National Aero-Space Administration, February, 2000.

Buechner, Randall (1995) "Design and Development of Remote Technical Assistance," MS Thesis, University of California, Davis. 102 pages.

Hirose, Paul T. (1995), "Remote Technical Assistance Project Client Design and Implementation," MS Thesis, University of California, Davis, 84 pages.

Jones, Edward G. (1999) "Informatics of Human and Monkey Brain Atlases," proposal submitted to Human Brain Project, National Institutes of Health, October, 1999.