The Virtual School: An integrated collaborative environment for the classroom
Philip L. Isenhour, John M. Carroll, Dennis C. Neale,
Mary Beth Rosson, Daniel R. Dunlap
The increasing availability of high-speed network access in school classrooms presents the opportunity for a range of collaborative activities. Over the past six years, the Learning in Networked Communities (LiNC) project at Virginia Tech has developed and evaluated a number of collaborative technologies in middle and high school classrooms, supporting interactions both between students working at the same time (synchronous collaboration) and between students working at different times (asynchronous collaboration). Much of the effort has gone into designing the Virtual School, a Java-based environment that integrates tools for synchronous and asynchronous communication and collaborative authoring.
In this paper we describe the types of collaborative activities that students working with these tools have engaged in and the problems that the classroom presents for designers of groupware (multi-user software). We then describe the extent to which existing groupware technologies address these problems. Finally, we present an overview of the components that make up the LiNC Virtual School environment and discuss experiences with using the environment for classroom group projects.
Collaboration in the classroom
Our testbed consists of six science classes at four area schools, involving students in grades six through twelve (11-18 years of age). Students in these classes have used a variety of conferencing and collaboration tools to engage in peer mentoring, carry out joint research projects, and work with expert mentors from the community.
In one set of activities, high school students guided middle school students through a week-long exercise on the scientific method. Each team collaborated to develop an experiment, gather data, and analyze the results. For example, one team examined whether people could determine candy flavors while blindfolded. The students used video and audio conferencing to discuss the design of their experiment. Shared authoring tools were used to document their procedure, record and share data gathered at each school, and then produce a final report describing their results.
In a larger semester-long activity, students collaborated to explore a physics topic in depth by building and testing models. For example, teams studying aerodynamics designed, built, and tested kites. Teams studying simple machines constructed a robot. Remote team members interacted through video conferencing roughly once each week, and communicated through email and collaborative authoring tools at other times. In some cases, teams divided the labor required to produce a single model. In one group, different components of a robot were constructed at different schools and then brought together near the end of the project for integration. Other teams divided the labor in simpler ways, with team members at each school building and testing different models. A team investigating the physics of bridges built and tested a different model bridge at each school and compared their findings.
Five of the teams working on the longer activities also interacted with university professors and other expert mentors from the community. The mentors were provided with the same software as the students, allowing them to communicate with the students and track team progress. One mentor met face to face regularly with students attending a nearby middle school, while only interacting electronically with remote team members on the other side of the county. In other cases the mentors only met with their teams in person near the completion of the project, and in still other cases mentors relied entirely on the software for all interactions. An analysis of these relationships and their outcomes is presented in Gibson, et al. (1999).
Ongoing projects include an activity in which eighth grade students are mentoring sixth grade students on principals of simple machines using commercially available construction kits. Conferencing tools allow both sides to help each other build increasingly complex machines, while collaborative authoring tools provide a medium for exchange and discussion of questions about the physics behind the machines.
Most of the teachers with which we worked had made extensive use of group projects in their curriculum prior to the introduction of tools for cross-classroom collaboration. The communication and shared authoring tools developed by the LiNC project were intended to expand both the size and the diversity of the pool of potential collaborators for these projects. The diversity across age and across location expands the pool of ideas that each student is exposed to, and demands further development of skills for negotiation and communication of ideas. Cross-classroom collaborations are likely to involve both synchronous and asynchronous interactions, and therefore encourage development of planning and coordination skills that are not required for intra-classroom collaborations. Finally, distributed groups can take advantage of unique resources at each location. For example, the group studying robotics had access to their mentor's robotics lab at Virginia Tech, as well as to robotics equipment at one of the high schools.
Issues and challenges
The classroom presents constraints for software design not usually present in home and office environments. Contention for limited computing resources and limited time are issues that computer-based classroom activities typically face. Collaborative, cross-classroom activities such as those described above compound these issues by creating dependencies between two or more frequently chaotic classroom environments.
Contention for machines
Within a single classroom there are typically considerably more students than computers. This encourages educators to develop activities that permit small groups of students to work together at a single computer, but the sharing of machines raises considerable technical issues. Most hardware and software do not explicitly support this mode of use. In particular, common tools for collaboration such as email and video conferencing packages assume that only a single user will be logging in from a given machine. In cases where users manipulate both private and group data, provisions need to be made for protecting private data when multiple users are working at the same machine.
In the classes with which we have worked, there have usually been five to six times as many students as computers. When establishing project groups, teachers typically have two or three students working at each machine. Hands-on science activities distributed across classrooms lend themselves to this arrangement, since work tasks can often be distributed across the various group members. For example, one student can be operating the mouse and keyboard while other (co-located) team members work on models or carry out steps in an experimental procedure.
Roving and dislocation
The public nature of computers both in classrooms and in school labs also greatly increases the likelihood that students will be using different machines over the course of a project. Computers in schools often endure greater “wear-and-tear” than those sitting on office desks, and repair cycles for school computers will tend to be longer. As students routinely outnumber computers, different subsets of students are likely to be using the computers on different days, and overlaps between these subsets will frustrate attempts to permanently assign students to specific computers. This unpredictability contrasts with typical office use, where user-to-machine mappings are relatively fixed and predictable. Such disadvantages resulting from the lack of predictability have significant implications for groupware. Conferencing packages that rely on the user to know the remote network address (e.g., host name or IP address) in order to initiate a connection introduce difficulties since addresses can change from session to session. In practice, many tools solve this by providing a separate directory service for locating and connecting users: Conferencing software announces a user's availability (and address) to the directory service, which then makes this information available to all other present users.
The management of locally stored data as students move from machine to machine introduces even more critical issues. While document files that users explicitly save (e.g., reports and drawings) could be stored on central file servers accessible to all machines, maintaining preferences and configuration data introduces more difficult problems. For example, many email programs store mail server, user name, password, and other settings on the machine's local hard drive, typically in one or more files that the user is not intended to interact with. Although this design choice works well in the case of home or office use, these packages require re-configuration for the current user at the start of each session when used on classroom or lab machines. Attempting to maintain per-user configuration data on floppy disks has proven to be problematic. Students forget or lose the disks, and even if stored in the classroom, the disks can be misplaced or damaged.
The tight time constraints of classroom activities magnify problems with software reconfiguration and similar startup tasks. Students will often be limited to 30 to 40 minutes of computer access in a given class period. When students from different schools are working together, differences in class scheduling can diminish overlap and result in even smaller windows of opportunity for synchronous interaction. As such, minimizing startup overhead is even more critical for classroom use than, for example, in office environments where users are likely to be at their computers for a greater proportion of each day.
Time constraints on synchronous interaction can often be predicted, and thus collaborative activities can be adjusted accordingly. However, much more significant disruptions are produced by less predictable events such fire drills, illnesses, and bad weather. Other events like test administration and field trips may be predictable to collaborators in one class but will cause problems if not communicated to remote collaborators. These disruptions tend to produce interaction patterns that defy the type of scheduling typical of workplace settings. Such erratic interaction patterns reinforce the need for smooth transitions between synchronous and asynchronous modes of collaboration. If students in one class discover that their remote collaborators are unavailable during a given class period, shifting from one set of tools for synchronous interaction to a different, dissimilar set of tools for asynchronous interaction wastes valuable activity time.
Tools for communication and collaborative authoring
Grudin (1994) describes a typology of groupware systems across categories of space and time. Collaborators can be working in the same place, different but predictable places, or different and unpredictable places. Similarly, collaborators can be working at the same time or at different times that may or may not be predictable. Given the time constraints and unpredictable nature of the classroom, collaborative activities between classes require tools that support all of these modes.
Email remains the most widely used Internet communication tool, providing a lightweight means for asynchronous person-to-person or intra-group communication (Sproull and Kiesler, 1991). Products such as Lotus Notes (Lotus Development Corporation, 2000) integrate email with other asynchronous collaboration tools for tasks like scheduling and participation in on-line forums or discussion groups.
Text chat systems, such as Internet Relay Chat (IRC), support simple synchronous communication. More recently, instant messaging systems such as AOL Instant Messenger (America Online, 2000) have become popular. These systems augment text chat functionality with "buddy lists" that show when specific users are logged in and available for chatting. Conferencing tools such as Microsoft's NetMeeting (Microsoft, 2000) provide higher-fidelity synchronous channels, with support for real-time video and audio conferencing, application sharing, file transfer, and shared whiteboards. The rich information provided by audio and video conferencing often carries a high price, both in terms of network bandwidth requirements and user interface complexity.
Network configuration can also be problematic. The school system that we work with uses a firewall, a machine that restricts connections between computers on the school system's network and the Internet. Most desktop video conferencing packages do not support connections across this type of firewall.
Tools for synchronous collaborative authoring typically take the form of application-sharing packages. A collaborator opens a word processor (or other single-user program) on their machine, and the application sharing software then broadcasts a live image of the application window to other collaborators, routing remote keystrokes and mouse actions back to the program (Garfinkle, et al., 1994). This approach has the advantage of working with a large number of existing applications, but it also has a number of disadvantages. For example, at the end of the session any saved files are only available to the user who started the application. They must then be distributed to other collaborators by some other means.
The World Wide Web enjoys widespread use as a medium for content dissemination, but authoring of web content is still primarily a single-user activity. A notable exception is the type of structured asynchronous authoring afforded by web-based forums. These systems frequently support threaded discussions similar to discussions in USENET newsgroups or the Issue-Based Information System (IBIS) (Yakemovic and Conklin, 1990). Web-based forums may also support collaborative creation of less structured content collections, such as collections of stories (Rosson, et al., 1996). Regardless of the degree of structure imposed, these types of systems generally support "authoring by extension", where previously added content is static and collaborators annotate, respond to, or otherwise extend existing content. While useful for many tasks, this functionality does not easily support collaborations attempting to create and refine a single, coherent piece of content.
Systems such as Basic Support for Cooperative Work (BSCW) support asynchronous collaborative authoring by providing centralized repositories for shared documents, along with support for activity awareness and coordination (Bentley, et al., 1997). Although tools like BSCW are gaining popularity, document sharing among collaborators is often done in a more ad-hoc fashion. Use of email attachments and shared file servers are two common means for transferring document drafts. These practices expose significant awareness and coordination issues. It is difficult to determine who has copies of a document, who is currently editing a document, and which changes different authors have made. File transfer methods that do not store the shared document on a widely accessible server also present problems when collaborators work at unpredictable locations, since document versions may be stranded on remote computers.
Used in concert, the various tools for synchronous and asynchronous collaboration present additional difficulties. Such tools tend to be closed, monolithic systems that require separate logins and configurations and, once running, have different user interfaces. The complex transitions required when moving between tools for editing, conferencing, and document sharing present a significant barrier to widespread use of all but the simplest groupware tools (Greenberg and Roseman, 1998). The time constraints and schedule unpredictability of the classroom environment serve to compound these issues.
The need for easing the transition between synchronous and asynchronous activities has long been recognized. Traditional text-based MUDs (Multi-User Domains) (Curtis and Nichols, 1994), environments based on MOOs (object-oriented MUDs) like Collaborative Virtual Workspace (Spellman, et al., 1997), and tools like TeamRooms (Roseman and Greenberg, 1996) attempt to address transition costs by integrating synchronous and asynchronous tools.
The LiNC Virtual School
The LiNC Virtual School is a general-purpose suite of integrated synchronous and asynchronous collaboration tools developed in the context of the classroom environment. It uses an open, component-oriented approach that has allowed integration of components developed in-house, third-party components adapted for collaborative use, and, where practical, external third-party packages controlled from the Virtual School (Isenhour et al., in press). In this section we describe the components of the current Virtual School implementation that support communication and authoring.
Students launch the Virtual School by double-clicking an icon on the desktop and entering their user name and password. By selecting their names from a list of the authenticating user’s project group, co-located group members can indicate their presence. This approach provides a way for remote users to see who is present without requiring each team member to log in separately. Security is not compromised, because only those operations available to the authenticating user and all other users who claim to be present can be performed.
After successful login, the session overview window appears (Figure 1). This window contains a user list showing the name, icon, and school for each team member. Team members not currently in the system are shown in italic with gray icons. For members who are present, the user list also includes the address of the machine from which they logged in, the time at which they logged in, and the length of time that they have been idle. This gives students a quick snapshot of their team's current status.
While the user list encourages students to focus on their remote team members, the Virtual School also provides an option to view a list of all users currently logged into the system. Figure 2 shows this list during a typical project session. The name, icon, project group, school, machine address, login time, and idle time are shown. Students have used this view to locate and contact system developers for immediate assistance or to report problems, as well as to check the status of absent or non-responsive remote team members. Students in one class can see if any of their remote team members' classmates are on-line, and then use the chat tools (described below) to inquire about absent collaborators or the status of possible computer problems.
Above the user list are buttons for accessing the three primary communication channels used in the Virtual School. For synchronous communication, the Group Chat button opens a text chat tool (see Figure 3). This tool, like Internet Relay Chat and instant messaging products used on the Internet, allows an arbitrary number of users to communicate synchronously by sending text messages.
Unlike many other text chat systems, the Virtual School chat tool supports content persistence. Previous messages are implicitly saved and restored when the chat tool is opened. This feature has proven to be a significant enhancement, allowing team members to review past discussions of task decomposition and delegation. Providing automatic persistence offers a significant advantage over systems that require chat sessions be explicitly saved to the local disk, since users will often not recognize the importance of a conversation until after it has ended. Finally, this type of implicit persistence supports late joiners, allowing them to catch up on missed conversation. This reduces overhead in instances where different team members' class period schedules only partially overlap.
Private chat functionality is also available. In the current implementation of the Virtual School, content of private chat sessions is preserved as long as at least one participant in the chat is logged in, but it is discarded once both parties leave. Given the structure of the collaborative exercises that have been undertaken using the Virtual School, essentially all project-relevant chat conversation occurs within the group chat. If, however, users feel that the content of a private chat needs to be preserved, they can copy it out of the private chat window and save it in a notebook (described below).
Where video cameras are available and network bandwidth allows, the Video Conference button will launch a third-party conferencing package, directing it to a user selected in the user list. This select-and-click approach to launching video conferencing saves considerable startup time, particularly in the classroom environment where users on both ends of the conference tend to use different machines each session. We are currently using Microsoft's NetMeeting conferencing software, which provides synchronous application sharing in addition to video and audio conferencing.
Given the unpredictable nature of synchronous collaboration in the classroom, email remains a critical communication channel. The Virtual School includes a standards-based email client for sending and receiving mail and attachments. As with video conferencing, students may select one or more users from the user list and then click the Email button to send a message. The email client also includes address book functionality to simplify the composition of messages to individual team members or to the entire team. The direct integration of the email client represents another effort to reduce overhead by eliminating the need to launch and log into a separate email program.
Notebooks are the central component of the Virtual School, serving as containers for content created either by individuals or collaboratively by teams. Each notebook is divided into sections (see Figure 4), and each section can contain a different type of data. The most commonly used section type supports basic HTML-style formatting of text and images. Other section types provide more structured editors for specific kinds of content. Bibliography sections allow users to collaboratively build lists of external references. Project planning sections support hierarchical decomposition of project tasks with start and end dates, descriptions, and status information. Outline and Gantt chart visualizations of the tasks are available to give both students and teachers an overview of progress on a project. Whiteboard sections support collaborative drawing and image annotation. The notebook architecture is extensible, allowing section types to be added as new viewer or editor components are written or adapted for collaborative use.
Notebooks support both synchronous and asynchronous modes of interaction. Any number of users can view a notebook simultaneously, and any one user (or any group of users working at a single machine) can take control of section for editing by clicking a button on the notebook page. Other users with the notebook open see a small red lock icon on the section tab when this happens and can also see who is editing the section. Changes made to notebooks are periodically sent to other users, allowing remote team members to discuss changes as they are being made. If a user is working in a notebook and none of his collaborators are present, or if they are present and then leave the system, the local behavior and functionality of the notebook do not change.
Aside from fluid transitions between synchronous and asynchronous collaboration, the relaxed synchronization of the notebook's view produces a very different user experience than collaborative use of a word processor under control of an application-sharing package. With an application-sharing tool, all collaborators see exactly the same view of the document. The word processor is running on only one collaborator's machine, with all other users seeing a live snapshot of the application window. While this type of strict WYSIWIS (What You See Is What I See) is useful for some tasks, it does not allow collaborators to view or modify different parts of the shared document at the same time (Stefik, et al., 1987).
Because contributions to shared notebooks can be made both synchronously and asynchronously, tracking each team member's contributions can be difficult for users. Verbal communication about past, present, and future changes to shared content is supported through email and conferencing facilities. The notebook also supports explicit annotations describing changed content and includes automatic tracking of contributions. Teachers or team members may insert annotations anywhere in the notebook. Annotations appear as small star icons, and color is used to distinguish between teacher and student annotations. Moving the mouse over an annotation icon causes a small "tool tip" window to appear showing who added the annotation and when it was created. The icon may be double-clicked to reveal the full annotation text. The notebook’s "Show authorship" feature allows each contributor's text to be shown in a different color. We presently support this form of authorship coding by either user or school. Coding by school is useful for activities where multiple team members are working together on a single computer and taking turns at the keyboard.
Authorship coding provides detailed information about who has contributed what within a given notebook section. To provide higher-level, coarse-grained information on recent modifications, the session overview window includes a Notice Board that logs recent changes to shared data. Students can use the Notice Board to find out which notebooks and sections have been changed by other team members. Double clicking on a Notice Board entry opens the changed section, and the authorship-coding feature can be used to find specific changes and contributions.
The Virtual School server integrates an HTTP (Hypertext Transfer Protocol) server to which any standard web browser can connect. This interface supports secure, automatic publishing of notebook content. Students and teachers can use a web browser to log in and securely view all of their notebooks from anywhere on the web. For notebooks representing finished work, students can assign a public URL to the notebook, allowing unrestricted viewing by anyone. The server generates the web versions of notebook content dynamically, so notebook sections retrieved over the web always reflect the latest work. The automatic web publishing capabilities have proven useful as a means for teachers to review student work from machines that have slow network links or that lack the capability to run the full Virtual School client.
When a user logs into the Virtual School alone, she has access to the notebooks belonging to all project groups that she is a member of, along with any private notebooks she has created. When several users log into a single machine, they only have access to notebooks common to all members. Teachers have full access to all student notebooks. Notebook content is stored on a central server and retrieved on-demand. As a result, students can access Virtual School content from any machine without having to transfer data.
While students have the ability to create new, blank notebooks for themselves or for their groups, it is often useful for project notebooks (those notebooks that will contain the final deliverables for the project) to have some project-specific initial structure. The Virtual School supports this in two ways: a configurable help menu and template notebooks.
The notebook’s help functionality can be configured by the teacher. While our original intent for help content was to provide targeted assistance for using the features of the notebook itself, it has proven more useful as a means for distributing assignment descriptions, model illustrations, and other immutable project material that would traditionally be photocopied and physically distributed.
Teachers can also create templates that define initial structure and content for the project notebooks. Template notebooks can simply contain pre-defined sections for required parts of the project report, or can contain more detailed content in the form of instructions, outlines, lessons, and challenges. Once created, a copy of the template notebook is given to each group. The content originally added by the teacher can be distinguished using the "show authorship" button, but is not protected. This approach carries some risk of tampering, but also allows students to extend the original content. This feature has proven useful in peer mentoring activities, where mentors have added new questions and refined lessons and instructions based on knowledge of their remote peers.
The Virtual School is deployed primarily on machines running Microsoft's Windows 95 operating system. The software will also run under Apple’s MacOS and various implementations of the UNIX and Linux operating systems. Like the client software, the Virtual School server software is written in Java and will run under Windows, MacOS, and UNIX. We presently run the Virtual School server, along with email, web, and directory servers, on an Intel Pentium II-based workstation running the Solaris operating system from Sun Microsystems. All communication between the clients and server uses standard Internet protocols.
Experience with the Virtual School
Evaluation of collaborative software is a difficult task since related actions may be distributed across both time and place. Concurrent with the development of the software has been development of techniques to evaluate the effectiveness of the design and assess outcomes on students and teachers (Neale and Carroll, 1999). In this section we discuss results of our evaluation that became relevant to the development of the software. This includes discussion of the extent to which the challenges presented by the classroom have been addressed by the Virtual School software and the types of learning activities that have emerged over the two years in which the software has been actively used. We then describe some of the issues that still need to be addressed.
Revisiting the challenges
One significant success has been the Virtual School features designed to address contention for machine access by supporting multiple users at one machine. Students readily grasped both the intent and mechanics of the group login feature, but access to an individual user's email when multiple users are logged in at one machine remains problematic. A practical solution to this would require each user to authenticate themselves before retrieving email, leaving the process of logging into the Virtual School itself unchanged.
Features supporting student movement from machine to machine over the course of a project have also proven successful. Students regularly work on different machines from week to week, frequently to avoid (real or perceived) hardware problems. Centralized storage of notebook content, perhaps the most critical feature that supports roving users, has proven so successful that one teacher has used the Virtual School for non-collaborative assignments, specifically to avoid issues with student work being lost or tampered with on local hard disks or floppies. To be truly successful for this purpose, students will need to have access to the Virtual School software from their home computers. While technically feasible, we have been hesitant to support this because of limited resources for supporting diverse hardware and software configurations.
A significant side effect of the high student-to-machine ratio is the unavailability of a machine for the teacher: A "spare" machine is never available. However, the teacher must also supervise both the set of the students working on the computers and the set for whom computers were not available during a given class period. Therefore the lack of teacher access to a dedicated machine is not likely to compromise teacher-student interactions. We have spent considerable effort designing features into the Virtual School specifically for teachers, which, we are learning, the realities of the classroom will likely prevent them from using, at least during class time. A more serious concern is the loss of awareness of synchronous interactions. Teachers are forced to give more one-on-one time to students when they work in small groups. This makes it difficult to keep track of learning and progress for the classroom as a whole. Because much of distributed group work is computer-mediated, even greater demands are placed on teachers to track learning and assess outcomes.
Integration of communication and authoring tools, along with the click-to-connect interface, has succeeded in significantly streamlining the process of checking email, accessing shared data, and setting up conferencing connections. In the absence of operating system or network problems, logs show that during a typical session students can enter the system, find and open relevant notebooks, check their email, and start a chat session in less than two minutes.
Group project structure and outcome assessment
By accommodating a variety of synchronous and asynchronous collaboration needs, a flexible virtual environment was created. Access to this flexible environment allowed for diverse implementation in classroom group learning. Teachers were able to focus on a wide variety of learning goals including those addressing technology skills, cooperative learning skills, as well as particular science subject skills. As a result, a number of different types of learning arrangements evolved in the instructional use of the Virtual School.
The organization of the student projects ranged from very open-ended explorations of particular science topics to much more structured projects where specific answers and products were required. Typically teachers introduced the tools to the students through short-term experimental design projects lasting about a week. Long-term projects lasting several grading periods usually followed. These were activities led by student groups that researched a set of principles or engaged pre-developed materials adapted to the Virtual School environment.
In the course of projects, students assembled collaborative products that could take a variety of shapes from simple textual questions and answers to electronic multi-media portfolios of the groups' work. While each project in the end developed and produced some kind of product that represented their work, teachers focused largely on the students' group-learning processes rather than just assessing the product of their collaborations.
The focus on collaborative learning process meant that awareness and iterative evaluation and feedback during the collaborative process was of primary importance to teachers and thus to developers. Group-work involving the technology made process feedback and evaluation particularly difficult, and many of the system requirements that emerged as the Virtual School was used sought to address these problems. For example, the authorship–coding feature was designed to permit teachers to track student progress across remote groups and allow some basic sorts of individual accountability to be applied to the collaborative notebook work. In addition, the logging of user activity provided a means of giving teachers rich information about the students’ collaborative learning process.
New activities and tools
Additional collaborative classroom activities that make use of the Virtual School are currently starting or being planned. Several of the teachers we have worked with will be setting up the same type of semester-long physics projects that were done in the Virtual School during previous years. Expanding beyond science curriculum, a new project is linking a group of elementary school children responsible for their school's on-line newspaper with a group of high school students who will serve as writing mentors.
New collaborative components are being added to the Virtual School. Collaborative charting tools are being designed that will allow team members at different locations to quickly visualize and compare datasets. Support is being implemented for embedding simulation applets to allow peer or expert mentors to demonstrate concepts. Finally, file sharing tools are being added to allow team members to manage documents created in other applications.
The components of the Virtual School are also being adapted for systems to be used outside of the classroom. MOOsburg, a graphical virtual environment modeled on the town of Blacksburg, Virginia, USA, replaces the text-based interaction typically found MOOs (object-oriented multi-user domains) with interactive components based on the same collaborative software architecture as the Virtual School (Carroll et al., in press). In addition to new kinds of collaborative objects being designed specifically for MOOsburg, the Virtual School's notebook, chat, and user list components are being reused in this environment.
Enhancing awareness support
Technical problems still consume considerable amounts of valuable activity time. While "crashes" of various kinds are largely unavoidable with the current generation of desktop operating systems, we believe that the Virtual School can be enhanced to provide awareness of potentially wasteful actions. Awareness of network-related problems is perhaps the best example of this. Intermittent network congestion problems in one of the schools we work with rendered video conferencing nearly unusable, with severely degraded audio and decreased system stability. On days that this problem manifested itself, students tended to spend a large portion of their class time tweaking the audio settings, even though they were quite familiar with text chat. Providing information about network congestion might encourage more efficient use of tools and time given system constraints, and also ease frustration over slow notebook updates and other network-contingent glitches.
Beyond providing awareness of environmental conditions like network congestion, enhanced support for awareness of synchronous and asynchronous activity within the Virtual School remains an open issue. The fact that students are typically only engaged in synchronous collaborative work in the Virtual School about one day per week would suggest that additional asynchronous awareness mechanisms, elements of the interface that indicate past activity of remote collaborators, should allow the students to work more efficiently. The notice board, annotations, and authorship coding provide this kind of asynchronous awareness information, but these features have seen limited success. The students have explored each of these features, but it is not clear that the students were given sufficient training in their use to allow the awareness tools to become integrated into the normal routine of Virtual School work.
Overburdening users with awareness information is undesirable, but it is possible that our current awareness mechanisms are simply too subtle. Unlike many components of the Virtual School, features designed for awareness support generally have no analog in single-user software. Hence making these features more salient, and providing additional training for both students and teachers, may increase their use and give us more feedback for refining the existing features and for designing new ones.
We have presented the Virtual School software environment, discussed the constraints that shaped the design of the software, and described experiences with the software over several years of classroom deployment. Significant issues and challenges remain, but we believe that the Virtual School demonstrates a successful approach to providing powerful synchronous and asynchronous collaborative capabilities, supporting a range of learning activities, within a classroom environment.
Additional information about the LiNC project and the Virtual School can be found at http://linc.cs.vt.edu/.
The LiNC project is partially supported by the National Science Foundation, the Hitachi Foundation, and the Office of Naval Research. Corporate sponsors include Apple Computer, IBM, and Sun Microsystems.