Under the Hood: Weaving Collaboration into Code


While Concord Consortium activities have long encouraged collaboration between students, we’re finding new ways to build student collaboration into our software codebase. One goal of our Common Online Data Analysis Platform (CODAP) is to enable students to work in a dynamic shared CODAP document in which any student’s changes are instantly synchronized to everyone else’s automatically.

We’ve been using Google’s Firebase technology in online activities that require teams of students to solve simulated real-world electronics problems on a shared breadboard circuit on separate computers linked by the Internet (see “Under the Hood: Creating Multi-User Activities with Firebase” in the Spring 2016 @Concord). So we knew Firebase could handle synchronizing CODAP’s data.

By using new features in CODAP’s data interactive plugin API, we could add synchronization with minimal changes to CODAP’s internal code. The collaboration code is a plugin that listens for changes to CODAP’s data structures, and then uses Firebase to share those changes (Figure 1). With this approach, existing CODAP documents can be made collaborative by adding the plugin and resaving the documents.

function handleCODAPRequest(request, callback) {
  var success = false;
  var values = null;
  var resourceType = request.resource && request.resource.match(/^[^[]*/)[0];
  switch (resourceType) {
    case 'dataContextChangeNotice':
      var contextMatches = request.resource.match(/^[^[]*\[([^\]]*)]/);
      var contextName = contextMatches ? contextMatches[1] : '#default';
      success = true;
      request.values.forEach(function(action) {
        dataManager.dataContextDidChange(contextName, action);
      });
      break;
    case 'documentChangeNotice':
      if (request.values.operation === 'dataContextCountChanged') {
        dataManager.dataContextCountDidChange();
        success = true;
      }
      break;
}
Figure 1. Code snippet showing how the Collaboration Service listens to CODAP change notifications.

CODAP’s Collaboration Service plugin starts with a setup “wizard” built inside the plugin that the document author uses to set which parts of the document to make collaborative and how students will collaborate (all together or in subgroups). The rest of the collaboration code focuses on ensuring that each CODAP user is operating on the same data by using Firebase as the single source of truth on the state of the data.

Firebase can communicate to other instances of CODAP running in the same collaboration group.
Figure 2. Firebase can communicate to other instances of CODAP running in the same collaboration group. The collaboration code is a plugin within CODAP.

When a CODAP document that uses the collaboration plugin is first loaded, all shared data local to the document is cleared and then reloaded based on the current content of the Firebase database for that collaborative document. Any subsequent local change such as an addition, update, or deletion to CODAP’s data causes CODAP to notify the collaboration plugin, which then propagates the changed data to Firebase. Next, Firebase informs all other plugin instances that are open. These plugin instances then update their CODAP documents using endpoints in the data interactive API (Figure 2).

Using Firebase as the single source of truth makes the code easy to reason about, but comes with some tradeoffs. It works well for documents containing other CODAP data interactive plugins that generate small or infrequent data changes. However, it is not ideal for documents that generate large changes frequently, which cause the application to become less responsive while data is being reconciled in the local CODAP instance. We’re currently exploring ways to offload some of this work either by using newer browser technology such as web workers or extending the CODAP data interactive API to handle bulk requests so that the application remains responsive.

The goal is to make the technology robust, so collaboration can take place as seamlessly as possible.

Doug Martin (doug@zoopdoop.com) is a software developer who has worked on many Concord Consortium projects as a consultant.
Scott Cytacki (scytacki@concord.org) is a senior software developer.

This material is based upon work supported by the National Science Foundation under grant DRL-1620874. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.