Providing collaborative support to virtual and remote laboratories

Virtual and remote laboratories (VRLs) are e-learning resources that enhance the accessibility of experimental setups providing a distance teaching framework which meets the student's hands-on learning needs. In addition, online collaborative communication represents a practical and a constructivist method to transmit the knowledge and experience from the teacher to students, overcoming physical distance and isolation. This paper describes the extension of two open source tools: (1) the learning management system Moodle, and (2) the tool to create VRLs Easy Java Simulations (EJS). Our extension provides: (1) synchronous collaborative support to any VRL developed with EJS (i.e., any existing VRL written in EJS can be automatically converted into a collaborative lab with no cost), and (2) support to deploy synchronous collaborative VRLs into Moodle. Using our approach students and/or teachers can invite other users enrolled in a Moodle course to a real-time collaborative experimental session, sharing and/or supervising experiences at the same time they practice and explore experiments using VRLs.

SECTION 1 Introduction

According to the constructivist learning theory [1], [2], people generate knowledge and meaning 1) when they share their ideas and experiences and 2) from the interaction between them. In this sense, web learning tools such as learning management systems (LMSs) have been recently modified to include communication channels allowing user-to-user interaction in web courses. In addition, experiential learning is the process of making meaning from direct experience [3]. This approach is especially important for scientific and technical courses, in which experimentation is a key issue for the learning process. Virtual and remote laboratories (VRLs) [4], [5], [6], [7] appeared to cover this necessity in distance education and to serve as a didactical complement for traditional face-to-face courses. However, even though constructivist web learning environments and VRLs already exist, there is still a lack of: 1) convergence and interoperability between both tools [8] and 2) real-time interaction between users when they work with VRLs [8], [9] and/or within an LMS. This paper presents a new approach that solves this scientific gap.

Currently, there are two different types of collaborative environments according to the moment when the student-student (or student-teacher) interaction takes place: asynchronous and synchronous [10]. The first ones allow data exchange in flexible timetables and remote access to web-based course materials to carry out activities in an asynchronous way. They use collaborative tools such as e-mail or forums for online communication. This is the typical approach offered by most classic LMS. However, this type of communication can cause feelings of isolation in students and reduces their motivation [11]. Furthermore, students do not receive instant feedback from their questions and cannot talk in real-time about results obtained in the learning activities. These limitations have been solved by applying synchronous technologies [12], as we have performed in the approach presented in the paper.

It is from the intersection of the three previous ideas (constructivism, experimental learning, and real-time interaction) that the concept of synchronous collaborative VRLs deployed into LMSs is born. Our approach implements this concept by means of two valuable software applications for e-learning and VRL development: Moodle and Easy Java Simulations (EJS). Moodle¹ is a widespread used LMS (more than 64 million registered users, according to its official webpage) that supports constructivist learning, offering its users communication and interaction facilities. EJS² [13] is a tool designed for the creation of discrete computer simulations. During the last few years, EJS has grown for helping to create web-accessible laboratories in control engineering education. With this objective in mind, recent releases of EJS support connections with external applications, such as LabView³ and Matlab/Simulink⁴ Hence, EJS not only is useful to create virtual labs, but also the GUIs of their remote counterparts [14], [15].

This paper describes an extension for Moodle and EJS the authors have developed to provide the following features:

1. Synchronous collaborative support to any VRL developed with EJS; i.e., due to our extension, any existing VRL written in EJS can be automatically converted into a collaborative lab with no cost.

2. Deployment support of synchronous collaborative VRLs into Moodle.

As a result, our approach not only supports the teacher's presentation or explication of course material by emulating a traditional classroom on the Internet. More interestingly, it also supports collaborative learning activities centered on students’ exploration or application of the course material through VRLs. That is, students working in groups of two or more, mutually searching for understanding, solutions, or meanings.

The remainder of this paper is structured as follows: Section 2 summarizes related work. Section 3 presents the preliminaries of our work, i.e., a brief description of Moodle and EJS, justifying their suitability to deploy and develop VRLs. Section 4 describes our approach, including its design objectives, and its implementation by extending Moodle and EJS. Section 5 sums up the experimental evaluation of our approach. Finally, Section 6 shows some conclusions regarding this work.

SECTION 2 Related Work

There is empirical evidence of the positive effects that collaborative features have to VRLs [16], [17], [18], [19], [20], [21], [22], [23]. Nevertheless, most of the online labs developed to date suffer from a lack of support for collaborative group work [24], [25]. To overcome such limitation, the following complementary approaches have been proposed:

1. Deploying VRLs into LMSs. Thus, VRLs take advantage of the LMS capacity to support the virtual interaction among participants (students and teachers) by means of both synchronous (e.g., chat, videoconference) and asynchronous (e.g., whiteboards, forums, mailing list) collaboration tools. For instance, [26], [27], [15] integrates VRLs into Moodle, and [28] into LADIRE.

2. Embedding VRLS into virtual worlds. Some researchers suggest that both entertainment and highly immersive environments promote effective learning. To do so, VRLs are embedded into virtual worlds that provide multiple communication channels between users and improve presence and awareness in the learning process. For instance, [29] integrates VRLs into Second Life, [30], [31] into the Sun Project Wonderland, and [32] into the game Half-Life 2.

3. Supporting VRLs to be handled by multiple participants at the same time. Under a simplistic approach, collaboration is limited to the use of communication tools such as chat or video-conference applications. Other approaches go beyond by supporting the simultaneous interaction of several participants with the same lab [31], [17], [34], [35], [36], [22], [37], [38]. This way, the proper VRL acts as the main communication medium among participants.

An important concern about VRLs is their high cost. Developing a VRL from scratch and creating its collaborative support requires a huge effort. Although software reuse alleviate this problem, it is not common for web labs. Gravier et al. [8] have surveyed 42 different remote labs finding that every project implements its own software architecture with no reuse. To promote software reuse, some authors propose general and reusable frameworks that add collaborative support to VRLs. For instance, Xing and Yao [39] describe an architecture for remote collaborative experiments based on the service-oriented architecture (SOA), Gravier et al. [21] provide a library based on Semantic Web technologies, and Bochicchio and Longo [40] propose a prototype system called Collaborative Lab as a Service (CLaaS), which manages collaborative web labs adopting the software as a service (SaaS) paradigm.

Our work encompasses many of the former proposals. It deploys VRLs into LMSs, it makes possible VRLs to be handled simultaneously by multiple participants, and it supports software reuse. The automated conversion of any EJS VRL into a collaborative lab has an enormous potential. For instance, the open source physics (OSP) repository⁵ [41] offers more than 400 simulations that can be transformed into collaborative ones with a single button click by using our approach. Moreover, a stable release of our open source code 1) has been checked, approved and published by Moodle⁶ 2) has been included in the last official EJS release 4.3.7, and 3) is being used in the UNEDLabs web portal⁷, which currently hosts 15 collaborative VRLs for 10 university courses.

SECTION 3 Preliminaries

Section 3.1 justifies why Moodle is an ideal tool to publish VRLs on the Internet. Afterward, Section 3.2 introduces EJS, explaining its suitability for the VRL development.

3.1 Moodle

VRLs do not provide by themselves all the convenient resources for distance education with all the implications this methodology involves. Specifically, students must carry out their practical activities in an autonomous way and therefore, if teachers want to facilitate their work, complementary web-based resources to the VRLs should be included. For this reason, for each VRL there should be available, not only a description of both the phenomena under study and the didactical setup of the experiment for remote experimentation, but also the tasks protocol that students must follow to achieve the proposed goals. Moreover, to assess the students progression, they should prepare a lab report with the data collected during the simulated and real experimentation that the instructors can correct. Moodle is a widespread LMS that can be customized to support such features. Fig. 1 shows an example of a Moodle course the authors have developed for a control engineering subject.

Fig. 1. A control engineering course in Moodle.

Regarding our proposal of synchronous collaborative labs, Moodle provides two built-in blocks which are very helpful for user communication: Online Users and Messages. Figs. 2 and 3 show a snapshot of each one. By means of the first block, users can see other connected users to know who they can invite for a collaborative experimentation session. With the second one, users can text each other while working together with a virtual or remote lab. An example of this is shown in Fig. 3 where the “Admin user” is working with user “Luis de la Torre’” in a collaborative session with a virtual experiment and has just received an instant message from him. In addition, Fig. 3 shows the VRL corresponding to a heat-flow experiment [42] developed with EJS and deployed into Moodle with the EJSApp plugin we have created.

Fig. 2. Online users block.

Fig. 3. Messages block.

3.2 Ejs

EJS is a freeware, open-source tool developed in Java, specially designed for the creation of discrete computer simulations. The architecture of EJS derives from the model-view-control (MVC) paradigm, whose philosophy is that interactive simulations must be composed of three parts:

1. The model describes the process under study in terms of a) variables, which hold the different possible states of the process, and b) relationships between these variables, expressed by computer algorithms.

2. The view provides a graphical representation (either realistic or schematic) of the process states; i.e., the GUI of the simulation.

3. The control defines certain actions that a user can perform on the simulation.

EJS makes things even simpler eliminating the “control” element of the MVC paradigm and embedding one part in the view and the other one in the model. Fig. 4 shows the EJS user interface.

Fig. 4. EJS user interface.

Applications are created in two steps: 1) the building of the model to simulate by using the built-in simulation mechanism of EJS, and 2) the construction of the view to show the model state and its reactions to the changes made by users.

From a practical viewpoint, developers can create advanced interactive applets using EJS because it provides a simplified program structure, custom model tools (such as an advanced differential equation editor), and drag-and- drop view elements that let developers work at a high level of abstraction, thus speeding up the creation process. Developers input the qualified information on the simulation that only a human can provide (e.g., math equations, the initial model state, the GUI's design) and the program takes care of all the computer related aspects of creating a finished, independent Java applet.

Although EJS was originally designed for developing interactive simulations in physics, during the last few years additional plugins/complements have been developed for helping to create web-accessible laboratories in control engineering education. With this objective in mind, recent releases of EJS support connections with external applications, such as LabView, Matlab/Simulink, SciLab, and SysQuake [43], [44], [45]. Hence, EJS not only is useful to create virtual labs, but also the GUIs of their remote counterparts.

SECTION 4 Collaborative VRLs

Moodle includes a good number of tools that provide asynchronous collaborative support (e.g., forums, the messaging system). Our proposal takes advantage of such features by deploying VRLs into Moodle. Moreover, we enrich Moodle collaborative support by providing a new feature: the synchronous collaboration among the VRLs included into a Moodle course. Fig. 5 shows an experimental session using all the provided features: virtual and/or remote experimentation, synchronous collaborative interaction and skype communication between users. Note that the laboratories of both users are synchronized, but only the session director can control the VRL (i.e., whereas the lab control panel of the session director is activated, the one of the invited user is deactivated).

Fig. 5. Example of two users participating in a collaborative experimental session.

4.1 Design Objectives

The following sections summarize and justify the main goals and features achieved by our system.

4.1.1 Supporting a Variety of Learning Paradigms

Our proposal supports emulating a traditional classroom. Moreover, it is flexible enough to support a variety of learning paradigms, including:

1. Reciprocal teaching [46]. Our system allows a user (either a teacher or a student) to start a collaborative session and invite other users. At the beginning of the session, the user that initiated it plays the session director role, the remainder of the participants are invited students. While, initially, the session director has the control of the lab (either virtual or remote), she/he may exchange the role with any of the invited students for reciprocal teaching.

2. Problem-based learning (PBL) [47]. PBL is a student-centered approach where students work in small groups to identify what they already know, what they need to know, and how and where to access new information that may lead to resolution of a problem. The teacher facilitates the learning process, building students confidence to take on the problem, encouraging students, while also stretching their understanding.

3. Cooperative work. According to Roschelle and Teasley [48], “collaboration” is distinguished from “cooperation” in that cooperative work “is accomplished by the division of labor among participants, as an activity where each person is responsible for a portion of the problem solving,” whereas collaboration involves the “mutual engagement of participants in a coordinated effort to solve the problem together.”

4.1.2 Maximizing Software Reuse

Building a VRL from scratch requires too much effort. Our approach supports converting any existing VRL created with EJS into a collaborative lab by just clicking a single button. Thus, VRL developers can be focused on creative activities, avoiding the routine ones.

4.1.3 Supporting Deep Collaboration

To learn new information, ideas or skills, students have to interact with each other and work actively on the course material in purposeful ways. Our approach complements the interactivity provided by EJS with synchronous collaborative support. Thus, rich learning contexts may be easily provided, where students are encouraged to practice and develop higher order reasoning and problem solving skills, instead of being distant observers of problems and solutions. Collaborative VRLs facilitate the intellectual synergy of many minds coming to bear on a problem and the social stimulation of mutual engagement in a common endeavor.

As VRLs are deployed into Moodle, which has several plugins to provide synchronous sharing of audio, video, and images (e.g., the Skype module⁸), our approach supports such type of synchronous collaboration. In addition, we provide a higher collaboration level. For each participant in a collaborative session, there is a running instance of the shared VRL. The state of all the instances is synchronized, i.e., whenever a participant acts over its VRL instance, the changes produced on the VRL state are propagated to the remainder of the participants’ VRL instances. For instance, Fig. 5 shows a collaborative version of the “Three Tank” VRL [49], which helps control engineering students to learn in a practical way many fundamental aspects of control processes. In the figure, two students work together to parametrize a proportional-integral-derivative (PID) controller to get an overshoot and a settling time smaller than 20 percent and 1,000 s in Tank 1 and 15 percent and 500 s in Tank 2, respectively. The areas in the Figure labeled “Virtual Lab” and “Remote Lab” visualize the lab state (i.e., the level of liquid in the tanks). Note that such state is the same for both students. Thus, although they are running two instances of the VRL, the students have the feeling of being working on the same VRL.

4.1.4 Supporting Cloud Storage

Our approach supports cloud storage, i.e., data is stored online on the LMS server (examples of stored data are open collaborative sessions, the intermediate running states of a VRL, students’ reports). This feature enables a number of valuable functionalities. For instance:

• Students’ work is available anywhere/anytime.

• A group of students may start a collaborative session using a set of computers connected to the Moodle server, interrupt the session, and later, using a different set of computers, take up the session.

• A number of activities may be automated, such as the backup of students’ reports, plagiarism detection and automated evaluation of students’ reports, analysis of session logs to measure students’ participation.

4.1.5 Usability

Our approach provides a high level of usability⁹ for all the existing roles in the development, management and use of VRLs:

1. The VRL developer creates VRLs with EJS. Using the EJS extension we have built, any VRL can be automatically converted into a collaborative lab by just clicking a single button.

2. The LMS administrator deploys VRLs into Moodle, controls user access to the deployed labs, and performs maintenance activities related to the labs (e.g., VRL backup and restore). Such functionalities are graphically supported by our Moodle extension.

3. The teacher and the students participate in collaborative sessions by using an adaptive visual interface. That is, to simplify the user interface and prevent errors, the interface dynamically changes to only make available the correct options for a given state of the collaborative session. For instance, a student visualizes the “participate as an invited student” button (see Fig. 7a) only when she/he has been previously invited to a collaborative session.

4.1.6 Scalability

Our approach is highly scalable, i.e., many collaborative sessions may be running at the same time. We have adopted a peer-to-peer (P2P) approach, which avoids that multiple collaborative sessions overload the server that host the Moodle portal and the VRLs. When a collaborative session begins, users just interact with the server by downloading the applet that implements the VRL they are going to use in the session. Then, an instance of the applet is locally run in each participant's computer. The instances communicate each other through a serverless collaboration over TCP and UDP protocols. Thus, the communication between the server and the participants’ computers is limited to simple messages of session creation, session pause, session close, and so on.

4.2 Moodle Support for Synchronous Collaborative VRLs

To support the one-click deployment of VRLs into Moodle, we have developed the EJSApp plugin presented in Section 4.2.1. Another plugin, named EJSAppCollabSession, that extends Moodle to support synchronous collaborative sessions of VRLs is described in Section 4.2.2.

4.2.1 EJSApp: Deploying VRLs into Moodle

The EJSApp module¹⁰ supports:

1. Deploying VRLs written in EJS. EJSApp supports the integration into Moodle of any kind of application developed with EJS (i.e., either collaborative or noncollaborative virtual or remote labs). EJSApp uses the new Moodle 2 feature File Picker, enabling VRLs to be uploaded not only from the user computer but also from a variety of repositories such as Dropbox and Alfresco.

2. Controlling user access to the deployed labs. EJSApp supports setting the start and end dates when a VRL will be accessible to the students, the minimum grade students need to get in other activities as a previous condition before having access to the VRL.

3. Backup and restore. EJSApp provides maintenance facilities for VRLs, packaging them into Moodle course backups.

4. Supervision and statistics. Access from Moodle users to EJSApp activities are recorded and can be used for performing statistics and supervising the time students spend working in each lab.

4.2.2 EJSAppCollabSession: Synchronous Collaborative VRLs for Moodle

A fundamental issue in a synchronous collaborative system is the floor control [51]. This term points out how the system components share the computational resources. The main objective of our proposal is to offer a shared VRL that can be controlled in real-time by different members of a virtual class (e.g., students and teacher) and to be able to share the same experiments like in a traditional classroom. In our case, the shared VRL is composed of an applet generated with EJS. Hence, there are two main kinds of components to coordinate: one session director's applet and some invited user's applets. The session director is responsible for starting, monitoring and closing a collaborative session. With our EJS extension, the session director's applet manages in real-time the virtual class and synchronizes all the invited user's applets. She has a list of invited users connected to the virtual session and can disconnect any invited user's at any moment. To have a suitable floor control, connected invited user's applets are locked and they cannot interact with the shared VRL in a first moment. They are only allowed to see in real-time what the session director is doing in the shared application. This way, the collaborative session avoids collisions of events which can cause unwanted and incoherent results. One example of this problem could be that the real equipment which controls the VRL becomes uncontrollable because of unsuitable user interactions.

In the following lines, the behavior of the EJSAppCollab-Session block is illustrated:

1. From the session director point of view, a collaborative session is composed of the following steps:

   1. The director creates a session (see Fig. 6a).

   2. The director selects, from all the collaborative VRLs that have been uploaded to Moodle, which one is going to be used in the session (see Fig. 6b). It should be noted that one VRL may be shared by several collaborative sessions simultaneously.

   3. The session director selects then the potential¹¹ participants to the session he is creating (see Fig. 6c), which are notified with i) an e-mail and ii) a Moodle message.

   4. The VRL is accessed in collaborative mode, i.e., the session director's applet manages the virtual class and synchronizes all the invited user's applets.

   5. At the end, the collaborative session is closed (see Fig. 6d).

2. From an invited user point of view, a collaborative session is composed of the following steps:

   1. The user accepts the director's invitation (see Fig. 7a). To prevent misuses of EJSAppCollabSession, its graphical interface changes to show just the valid choices available to a given situation (see Figs. 6a, 6d, and 7a).

   2. From all the received invitations, the user selects in which session she/he wants to participate (see Fig. 7b). Note that a course member can be invited to several collaborative sessions, but she/he can only participate in one of them at the same time.

   3. The VRL is accessed in collaborative mode.

   4. The user stops participating in the session when i) she/he decides to leave it or ii) when the session director closes it. In the former case, the user is free to enroll either to that session again or to any of the other current available invitations.

4.3 EJS Support for Synchronous Collaborative VRLs

Our EJS extension adds synchronous collaboration and support to any VRLs developed with this tool. This is done by TCP and UDP connections that periodically share and synchronize the VRL state of the session director with the VRLs of the invited users. The extension provides the session director, as an additional feature related to the synchronous collaboration, with the control panel shown in Fig. 8. This panel includes a list of the invited users connected to the collaborative session (e.g., Fig. 8 shows that “Luis de la Torre” is the session director and, “Rubén Heradio” and “Jose Sanchez” are the invited users). Using such list, the session director can perform the following tasks:

1. Supervising which users have already connected to the collaborative session to call the role before starting the experimentation.

2. Disconnecting any invited user at any moment.

3. Assigning the chalk to an invited user. With this feature, the session director gives permission to control the shared VRL to a specific invited user, by selecting him from the list. The chalk enables a student to manage the VRL, but not the collaborative session (i.e., the control panel is always commanded by the session director).

Fig. 9 depicts the communication framework that underlays the collaborative sessions. When a session begins, users just interact with the Moodle server by downloading the applet that implements the VRL they are going to use in that session (see dashed lines in Fig. 9). On the other hand, users participating in a session interact each other through a serverless collaboration over TCP and UDP protocols (see solid lines in Fig. 9). Thus, the communication framework we propose supports multiple simultaneous sessions without overloading the Moodle server.

Fig. 6. Synchronous collaborative session in Moodle from the session director point of view.

Fig. 7. Synchronous collaborative session in Moodle from an invited user point of view.

Fig. 8. Control panel of the collaborative session.

Fig. 9. A network of collaborative sessions.

Invited users’ applets are connected directly to the session director's applet in a P2P centralized overlay network. In contrast with server-based approaches, our e-learning system is focused in a serverless architecture. This communication method avoids delays caused by the server processing in the data flow because the communication engine is embedded in the Java applets downloaded by the users. In addition, the number of network connections can be substantially decreased because the session director's applet can manage the session, the floor control, and the data exchange having higher control over the invited user applets. As stated, the P2P network is centralized around the session director's applet. This last application is the central node of the collaborative class and contains a multithread communication module which manages the synchronization of all the applets that compose the shared VRL. Invited users’ applets are connected to the central node over TCP and UDP sockets performing a centralized network.

To synchronize in real-time all the applets connected to the virtual class a method based in Java object tokens [51] is used. Java object tokens are small update messages which contain a String object that defines the action to be performed by other applets of the same session. The small amount of sent information optimizes network utilization and reduces the connection delay.

Since all the applets must be in the same state at any time, it is necessary to synchronize them. The developed communication framework provides a transport service suitable for all update data: a TCP-based channel for reliable messages and a UDP-based channel for fast messages. The TCP channel is used to update all the variables of the application because the transmission of the values needs the reliability of an ACK-based protocol. The UDP channel is used to transmit the small changes in the user-interface and this requires to be quickly updated in the rest of the applets.

SECTION 5 Experimental Evaluation

In terms of number of students, the Spanish Open University (UNED), with more than 260,000 scholars, is the biggest university of Spain and the second one of Europe, next to the English Open University. To support their students, UNED is composed of a network of associated learning centers scattered around the world (more than 60 centers distributed across Spain, Europe, America, and Africa). Unfortunately, the geographical dispersion of the students makes impossible to provide the scientific courses of UNED with traditional labs at a reasonable cost. Since the nineties, the Department of Computer Science and Automatic Control of UNED has been very concerned about this problem and has been working in new ways to illustrate scientific phenomena that require costly or difficult-to-assemble equipment. The UNEDLabs web portal is the fruit borne by such work. It hosts a rich network of VRLs for students of UNED and other Spanish Universities. All VRLs in UNEDLabs have been developed using the approach described in this paper. This section reports the experimental evaluation of our work on a course of Experimental Techniques in Physics supported by UNEDLabs.

5.1 Participants

The experimental evaluation of our approach was performed on two consecutive academic courses of Experimental Techniques in Physics at UNED: 2010-2011 and 2011-2012. In both years, students were encouraged to carry out five voluntary lab assignments supported by the following VRLs:

1. A motorized rotatory laser to illustrate the Snell's law [52].

2. A motorized optical bench to estimate the focal of thin lenses [53].

3. A Hooke's law simulator [52].

4. A Geiger counter-based VRL to experiment with radioactive disintegration laws.

5. An RC Circuit.

Whereas the 2010-2011 course had 53 students and the lab assignments were individual (i.e., no collaborative support was available), the 2011-2012 course had 62 students and the assignments were performed in groups of two/three students by using the collaborative features described in this paper. Table 1 and Fig. 10 describe the data set of our experimental evaluation, which is composed of the number of lab assignments completed by the students and their grades on the course final exam¹².

TABLE 1 Data Set Descriptive Statistics

Fig. 10. Data set histograms.

5.2 Results

5.2.1 The Exam Grades and the Number of Completed Lab Assignments Are Correlated

The scatter plot in Fig. 11 depicts the relationship between the number of completed lab assignments and the exam grades for both courses. Since there are many data points ($53+62=115$) and significant overlap among them, points have been grouped into colored hexagonal cells. The color range goes from light gray (one single point) to black (when a cell groups 16 points). In addition, Fig. 11 includes the linear regression lines of 1) the courses 2010-2011 and 2011-2012 separately, which just take into consideration their corresponding 53 and 62 points, respectively; and 2) both courses jointly. Table 2 summarizes the correlation tests of the relation between assignments and exam grades. Since the $p$-values are minor than 0.01, the tests show that the correlation is statistically highly significant.

Fig. 11. Scatter plot and regression lines for the data set.

TABLE 2 Correlation and Regression Lines between Exam Grades and Completed Lab Assignments

5.2.2 Collaborative Labs Encourage Student Engagement

Table 1 shows that students who performed the lab practices in a collaborative fashion completed on average more assignments than the ones who made it individually (i.e., whereas the mean and the median for 2010-2011 are 1.53 and 1, respectively, for 2011-2012 are 2.79 and 3). Student's t-test of the number of completed assignments for 2010-2011 and 2010-2012 has $t = 3.4684$ and $p\hbox{-}{\rm value}\;{=}$ 0.0007417. So, the difference between using our collaborative approach and not using it is statistically highly significant. In addition, the Cohen's d is 0.6465427. Therefore, the difference effect size is moderate (${>}0.5$).

5.2.3 Synchronous Collaboration Increases Lab Assignment Performance

As Table 2 shows, the correlation factor for course 2011-2012 is higher than for 2010-2011 ($0.89>0.56$), and the slope of the 2011-2012 regression line is steeper than the 2010-2011 one ($1.28>2.69$). So it looks like students get better exam results when practicing with collaborative labs or, in statistical terms, it seems that the collaborative support moderates the effect that the number of lab assignments has over the exam grades [54]. To check such moderation effect, the two multiple regression models summarized in Table 3 has been used. Whereas, Model 1 just includes variables ${\rm NumberOfAssignments}$ and ${\rm HasTheCollaborativeFeature}$ to explain the exam grades, Model 2 includes the moderation effect encoded by the product ${\rm NumberOfAssignments} \cdot {\rm HasTheCollaborativeFeature}$ as well. To facilitate the interpretation of both models:

1. ${\rm NumberOfAssignments}$ is put in deviation form, i.e., every value $x$ is centered to the mean: $x_{{\rm centered}}\;{=}$ $x\hbox{-}{\rm mean}_{{\rm NumberOfAssignments}}$. Thus, the regression coefficient B1 is 0 when NumberOfAssignments is equal to its mean.

2. ${\rm HasTheCollaborativeFeature}$ is encoded as a) 1 for collaborative assignments, and b) 0 for noncollaborative ones.

Hence, the interpretation of the regression coefficients for Model 2 is:

• The estimated grade for a student that has completed the average number of lab assignments without using the collaborative feature is $B_0=3.9057$.

• The average return per lab assignment completed without using the collaborative feature is $B_1\;{=}$ 0.8017.

• The difference in grade between completing the average number of lab assignments using the collaborative feature and not using it is $B_2=1.4976$.

• The difference in the grade by completed assignments slope between noncollaborative and collaborative labs is $B_3=0.4703$.

The following points support the existence of a statistically significant moderation effect:

1. Comparing both models, the ${\rm NumberOfAssignments}$ coefficient $B_1$ decreases, i.e., it becomes less important when the interaction ${\rm NumberOfAssignments}\;{\cdot}$ ${\rm HasTheCollaborativeFeature}$ is considered. Besides, in Model 2 the moderation effect coefficient $B_3$ has $p\hbox{-}{\rm value} \;0.00754$, i.e., the interaction term is statistically highly significant.

2. Whereas Model 1 explains 62 percent of the variance in the exam grades, Model 2 explains 64 percent of the variance (i.e., $R^2$ is 0.6209 and 0.6446 for Models 1 and 2, respectively).

3. ANOVA model comparison for both models has $F=7.4083$ and ${\rm Pr}({>}F)=0.00754$, i.e., it is statistically highly significant that Model 2 estimates the exam results better than Model 1.

SECTION 6 Conclusions

Moodle and EJS are two free outstanding software tools for e-learning and VRL development, respectively. The work presented in this paper enriches both tools, supporting 1) the automated creation with EJS of synchronous collaborative VRLs, and 2) the deployment and management of such VRLs into Moodle courses. The approach satisfies a number of requirements, summarized in the following points:

1. It supports the synchronous collaboration among the users of a lab.

2. It supports a variety of learning paradigms (e.g., reciprocal teaching, problem-based learning).

3. It maximizes software reuse.

4. It provides the cloud storage of data.

5. It is highly usable by VRL developers, Moodle administrators, teachers and students.

6. It is scalable, i.e., a Moodle server may support many collaborative sessions running at the same time.

There is experimental evidence of the usefulness of our work. In particular, the statistical analysis reported in this paper shows 1) a correlation between the student exam grades and the number of completed lab assignments, 2) an increase in student engagement thanks to the collaborative system we propose, and 3) a moderation effect of our synchronous collaboration approach and the number of completed lab assignments.

TABLE 3 Moderation Effect Evaluation by Using Multiple Regression Models

ACKNOWLEDGMENTS

This work was supported by the Spanish Government under the CICYT Project DPI2007-61068 and the GITE grant of the Technology and Educational Innovation Vice-President Office of the University of Alicante.