R. F. Walters, B. B. Douglas, T. C. Leamy, W. Yaksick

University of California, Davis

RC (Remote Collaboration, formerly called Remote Technical Assistance) is a tool created at the University of California, Davis, to enhance interaction between humans using Internet connectivity. It combines a number of features not usually available in a single package. RC is based on client-server architecture, with a UNIX server that connects clients running on PC, Macintosh or UNIX platforms. Communication between users can be in pairs or groups, either synchronous or asynchronous. Users can communicate using a) dialog (chat mode) that can include non-English character sets such as Western European, Russian or east Asian; b) Annotatable images including screen snapshots; c) sound messages (compressed for transmission; d) shared viewing of web pages; e) a collaborative writing tool called textpad; and f) transmission of any kind of file. RC has been used in learning environments including second language acquisition, computer science, medicine and other fields. It is also effective in supporting collaboration of any kind between users who are separated in location and time. See home page: http://escher.cs.ucdavis.edu.

Today's business world exists in a global economy that must take into consideration differences in time zones, languages, and cultures. No longer is it acceptable to conduct business assuming that clients represent a homogeneous group who speak the same language, live within driving distance, and have similar expectations in terms of cultural conventions. A central requirement in this distributed work environment is effective communication between people who are spread throughout wide geographic areas. In such an environment, the opportunities to interact must adapt to a variety of schedules. Since today's technology is flexible enough to provide a wide range of options, the key to its effective use is designing a system that puts the communication needs first, then adapts the technology so that it serves those needs.

In teaching and learning, similar needs have arisen. College students are no longer the homogeneous 18-24 year-olds that lived on small campuses and devoted all their energies to seeking degrees in quasi-lock step. Instead, today's educational needs must target a widely different population, both in terms of age, background, schedules, and learning styles. The need for more effective communication in education is, however, remarkably similar to the same need in the business world.

We began our research in technology support of interaction in the teaching-learning domain. However, the tool that evolved during this design process has proven suitable for human interaction in a wide range of applications ranging from learning through collaborative research and on to remote consultation, planning, and design. Originally, we named this tool Remote TA (which could stand either for Technical Assistance or for a Teaching Assistant), and we expected to use it primarily as a means for students to contact instructors or teaching assistants to get help on projects. Almost as soon as we started to use it in language learning, however, we realized that one of the best applications of the tool was in having students interact with other students, rather than only with the instructor. The tool evolved rapidly into a means of communication that quite evidently could be applied to ever wider ranges of human activity. This process has led to greater demands on the technology, but always with the goal of having the technology serve a useful purpose in communication, rather than designing a technically powerful tool for which no immediate use was apparent.

In this report we present some key design components and illustrate the current status of RC. We also describe some features that we will incorporate in the next version, and we outline longer term goals for the continue evolution of this package.

The current version of RC was designed based on the following assumptions:

• The package was designed to run on the Internet, using communication protocols appropriate for that environment.
• RC works with a client-server architecture. The server controls access, links users, moderates all interaction, and can save whatever is needed for a given application.
• RC assumes a platform-independent interactive process, converting all forms of communication into a uniform standard for transmission between clients and server, and placing the burden of localized processing on individual clients rather than on the server.
• RC must be multimedia. At present, that means that text, sound, graphics, and files are accommodated. Live images of participants has not yet been included because the need was not great enough to justify the transmission bandwidth.
• RC must facilitate the use of non-English character sets. The methods selected for input vary with the language being used, but the ability to display other languages is an essential part of RC. It should be open-ended to incorporation of new "languages" such as special notation used in mathematics and chemistry.
• Provision must be made for a collaborative writing tool (which we call textpad). This feature should allow users jointly to create documents that can be saved, edited off-line and returned to the RC environment for further discussion and modification.
• There should be a way to share automatically web page sites, so that all participants can be looking at the same page.
• All of these features should also be available in asynchronous (messaging) mode, so that users can interact with each other when not on-line at the same time. The messages must be multimedia, multilingual, with options to attach files as well as sound and whiteboard messages which can then be annotated and returned.
• Finally, there should be a means of linking directly to other resources: web pages, locally stored information (e.g., CDROM files), and programs. These resources should be defined by the leader of a "class" or group, with the option to modify dynamically the resources displayed.

These features were incorporated into the current operating version. It has been used for instruction in second language acquisition, computer science, and medicine, but its applicability extends well beyond these domains. It is also useful as a communication tool for groups that are distributed geographically, allowing the to discuss a wide range of topics much more completely than either telephone or email alone. In the next section, we present a few samples of the modes of interaction available through RC.

The RC server maintains lists of groups working together currently called "classes," but these groups could be used for any distributed set of individuals with common interests. When an individual wishes to log on to RTA, they invoke the client on their local system, connected to the Internet. The following window illustrates the logon process.

Once the user code and password have been entered and verified by the server, the user is connected to the server. The next window that appears gives the user several options.

In the selection displayed, the server displays the names of all others connected live to the same class at the time. It also gives several options as to ways in which the user can interact with RC. Using the current window, the user can highlight the name of an individual and click on connect to form a two-way conversation. Alternatively, if a group exists, one can request to join the group, or, if none exists, one can create a new group.

Once connected, a user moves into the live dialogue mode. As shown in the next illustration, this package supports communication in non-English languages, of which two samples are shown here:

While we have not yet worked with many other languages, in principle any others are feasible.

This image illustrates the different modes of communication that are possible during the live interaction with others connected to the same dialog session. The first is a whiteboard, which can consist of a screen snapshot, a blank whiteboard, or a file retrieved from disk. The user wishing to share a whiteboard selects one of these options, then uses a click-and-drag motion to select the area transmitted. Here is an example of such a whiteboard.

As shown, users can annotate the selected whiteboard, selecting a color from the right side and a form of annotation (line, open or filled circle or rectangle, text or freehand) from the left hand side of the whiteboard. In this example, the user selected white to annotate the bottom two maps.

The sound option allows a participant to send a sound message which is first compressed, then sent to all recipients (including the sender) as a stored message that can be replayed as many times as required. The user clicks on the red microphone at the bottom and holds down while recording (there is no fixed limit on message length). Using the GMS compression algorithm reduces the sound to approximately one-tenth of its original size.

The next option allows any user to identify a Web page to transmit to other users in the same session. The user types the URL and sends it, which will either open that page on the recipients’ preferred browser or, if a browser is not already open, RC will open the preferred browser and direct it to the Web page selected by the sender. This is the limit of remote control allowed by RC. We do not feel that it is appropriate to take further control of a user's screen. Any user can use her browser to go to another location, or return to this one using the back key. Changes made locally by users are not reflected on other screens unless a new URL is sent through RC.

File transfer allows any type of file to be transmitted to all recipients. Word documents, spreadsheets, realtime animation and other files may be sent and then saved by the recipient for use with the appropriate software on the local system. This is an open-ended way of sharing files, but they are not controlled by RC, which only handles transmission of the files to remote locations.

The final form of interaction afforded during live dialog in RC is called textpad. This is a collaborative writing tool that can be created, edited, saved for further offline editing, and retrieved at a subsequent interactive session. The textpad window is shown below.

Any group member may request control, creating a queue of individuals wishing to edit the document. Once in control, a user must relinquish control before the next user is given control. (The group leader may take control without permission, but this option is not open to others in the group.) The queue of individuals requesting control shows as a pull-down menu in the window. The File option allows users to save or retrieve textpad files. External editing is done with ASCII text editors, as the control characters used in packages like Microsoft Word are not accepted in textpad files, although non-English characters are accommodated.

This summary of the on-line interaction illustrates the strength of RC as it now exists. In a later section, we describe some other features that we intend to add in the near-term future.

The second principal option provides asynchronous communication between users who may not be on line at the same time.

This illustrates review of a single message. Note that options exist to enclose whiteboard, sound, and files (in this case a word document) with the dialog. The message recipients are chosen by the sender. A recipient may annotate the dialog or whiteboard, add a new sound message, or append new files. It is also possible to delete any existing component of the message and to edit the text in the dialog portion as well as adding new text.

A third mode of interacting with RC is by linking the user to previously defined "content" that is pertinent to the group. In a course setting, this option might include a course syllabus, lectures, and other useful information available on the web or on other media such as CDROM disks. As in the case of the URLs sent during a live interactive session, the user needs only click on a content item and the computer is linked to the appropriate browser at the specified location. Special options are available; currently we have the option of not showing a given link if, for example, it is premature in a course to direct the student to an advanced assignment.

Management of an RC team (class, research team, or other group of people with common interests) is done through a management tool that allows the "owner(s)" of that group to define membership in the team as either "staff" (instructors or supervisors) or "students" (regular members), with some augmented privileges accorded to staff. In addition, the management tool permits the owner to define content links and their current availability, view dialogues of the group saved on the server, and manage the team files. Ownership is granted by a system administrator, after which the owner(s) can make any changes needed to the features described.

Since the architecture of RC is based on client-server design, with all communication going through a server, it is possible to capture and store any form of communication sent by a client to the server. While we have used this functionality sparingly, we envisage much broader use in certain types of applications. One example we have considered is the development of a user profile for the keystrokes used to enter a password. This could be used in subsequent RC sessions where authentication of the user is required (e.g., taking a test).

To date, the principal use of RC has been in second language acquisition courses, where students have been paired to carry out assignments that require them to interact with each other in the target language. These tasks may be done during a laboratory or remotely when students are in their own rooms. Reaction has been strongly positive to the opportunities afforded by this approach. Students find that the opportunity to use the target language to solve problems together gives them a real world type of practice in effective communication.

Another group of applications has been in computer science courses: an on-line programming class taught by one of the authors (Walters), and in supporting an independent study course "Introduction to Computers." These uses have concentrated on the use of asynchronous communication with complex messages (whiteboards, files) to convey more information that would be available using email.

Still other uses have been on an experimental basis by faculty at other institutions. At the University of California, Santa Barbara, a professor of German is using RC for several sections of her students learning that language. At Oregon State University, a professor is using the package for students who are not on the Corvallis campus to give them opportunities to work as a group with less frequent trips to the campus for group meetings.

These uses have explored a fairly wide range of RC features, and they have also identified new functions that should be added to the package. The "wish list" of new features has also been expanded by its use in several other areas. One involves its use by pathologists discussing images of microscope tissues among a group located in several cities across the country. Another proposed application is to assist an engineering design team in creating new space vehicles for NASA. Still another application being tested at this time relates to architectural design of a structure, with review by interested parties located on both coasts of the US. Participants in this experiment send elevations, floor plans, photographs of interior design options, and discuss them using sound and dialog. These applications, together with a growing set of proposed applications to other courses, have demonstrated the robust design of RC to serve a multitude of purposes while also identifying new features that would make it even more responsive.

The net conclusion is that RC is a tool that lends itself to a wide range of applications, with slightly differing emphases in utility for each. We have learned from our initial experiments, and we anticipate continued addition of new features as time permits.

RC has been tested in a wide range of areas, and is in use in some of them already. In almost every new experimental application, ideas have surfaced for additional features that should be added to RC. In this section we present our short- and long-term goals for extending RC to meet some of these identified needs.

Persistent Groups: "Teams"

For some time, we have recognized the need to provide a persistent interactive dialogue that is seamless between live interactive and messaging. We call this concept a "team," and have begun implementing its infrastructure already. Teams differ from the current interactive groups in that the group and its membership are pre-defined by the owner of the "class" and are persistent over time until removed. Members can connect live to the team, but if no one else is available, a member can add to the existing dialog, attach images, sound, or files, and edit textpad content. If another member comes on-line, the conversation becomes interactive. The dialog is saved, together with time-stamped annotations as to who connected, what items were attached, and when a whiteboard was saved in revised format. This approach is of great benefit to a wide range of on-going collaborative efforts, and we hope to begin testing it soon.

Imaging

Whiteboarding is a very powerful tool in its current form, with the ability to annotate in color a variety of images. Extended use suggests the need for several other features that would further enhance this feature. A high priority is to permit editing of annotations. To do so, we will create a separate layer of annotations that is saved separate from the whiteboard image itself. This approach will not only allow us to add, modify or delete annotations, but it will also permit use of the overlay function to superimpose two whiteboards on each other for purposes of comparison. The use of translucent overlays is useful for comparing images, but it also can serve in comparing edited versions of text documents. We intend to experiment with applying this approach to text comparisons as well. We also intend to permit multiple whiteboards to be displayed at one time, so that comparative discussions can be carried out with two or more images available to support the analysis. Another feature that we intend to add is the ability to link whiteboarding with programs generating animated or sequential images, so that multiple users in remote locations can view a simulation or animation as generated on a single system. We need to accommodate several different image formats (currently we use bmp files) either by converting them or providing different options for display of alternate formats such as jpeg.

Sound

The sound function in RC is very useful, with the ability to listen to messages more than once. However, in many cases, we have found that using telephone conversation in conjunction with RC is helpful, and the need for storing sound is not universal. We intend to incorporate live telephonic sound to our interactive sessions as an option, retaining the ability to store sound when needed.

For the present, at least, we do not plan to incorporate live video, since we believe that its utility is somewhat limited compared to the bandwidth required. Snapshot links from computer-based cameras will be included, but we intend to allow parallel operation of video programs (such as CU-See Me) independent of RC.

Expanded Notation

RC now supports western European languages, Japanese, and Russian. We expect to add many other languages as needed, including a longer term goal of accommodating right-to-left scripts such as Arabic and Hebrew (a longer range task). The process of incorporating different display and input mechanisms appears to be fairly straightforward, and we will add new languages as their use is needed on a prioritized basis.

We also recognize a need for incorporation of special symbolic notation such as the types used in mathematics, chemistry, and other disciplines requiring special character sets and extended display features (e.g., square root symbols encompassing mathematical expressions). We are beginning this process with the inclusion of mathematical notation, an immediate need in the instructional process.

Administration

Currently, RC permits owners of "classes" to create new classes, define the membership, add links to relevant content material, and review dialogs. There are numerous additional features that we would like to add, such as editing existing files, linking to databases, incorporating testing, and other such features. These have had a much lower priority in RC development, primarily because others are doing very well in creating these tools, whereas few are focusing on the interaction supported by the RC package. However, as RC matures, it will be appropriate to add these features in order to make it more complete. We consider this a longer range goal, however, in that the immediate needs for extension of RC’s interactive capabilities will take higher priority during the next phase of development.

We have identified another important need: the ability to link with other packages so that they can invoke RC, rather than just the reverse as currently provided. This option is being explored with some pilot examples such as allowing a web browser to bring up RC automatically. We expect to start testing this type of link in the short term future.

RC is solely owned by the Regents of the University of California. We are anxious to see its use expand and to develop collaborative arrangements whereby its continued development might be shared by other groups. We also recognize that continued support of an expanding product (as it is becoming) is beyond the interests of our development group and inconsistent with the charter of the University. We have opened dialogs with groups who might be interested in providing support for this package to others. Such support might take the form of providing a server for such institutions as may not be in a position to provide their own systems support, or it might entail providing training and assistance in installation and use. Whatever the eventual approach, it is clear that the long term survival of this concept requires identifying one or more groups willing to take on support for the package.

We have presented the evolution, current status, and future plans for the Remote Collaboration package. It has already proven itself to be a powerful tool in supporting remote interaction between humans in a wide range of activities. We anticipate that it will continue to evolve as it becomes more widely used, and we look forward to guiding that evolution for the next few years. We believe that RC can make a contribution to effective communication in many domains, and we look forward to assisting with its development as new applications appear for its use.

This research has been sponsored by the University of California, the U.S. Department of Education’s Fund for the Improvement of Post-Secondary Education (FIPSE), and through equipment donation from the Apple Corporation. A great many students, faculty and staff have been involved in the evolution of RC over the past five years, notably Randall Buechner, Paul Hirose, Brian Kennedy, Tim Leamy, Robert Blake, David Fahy, and a number of students who contributed important ideas and components of the evolving package. To each of them we express our sincere appreciation.

¹ This article appeared originally in For Business 2000 On-Line Conference. Available on-line at http://www.forbusiness2000.com/.

RTA is owned by the Regents of the University of California and is available for licensing to interested groups or institutions. For further information about the RC package, readers are invited to send email to walters@cs.ucdavis.edu.