Under the Hood: Interactive API
To truly tap the potential of deeply digital learning, curriculum authors need a common API for interactives. Currently authors can embed iframes in most content authoring tools. Our new interactive API allows the iframe and surrounding system to communicate with each other, enabling an even richer learning experience.
We’ve been building deeply digital learning activities for years, and we want to make it possible for more curriculum authors and teachers to create them, too. An activity consists of two parts: an activity authoring and delivery system (think simple LMS) and the interactives that are embedded into the system. Creating interactives often requires programming, so it’s not feasible for most authors, who instead look for existing interactives and build activities around them. If these pre-built interactives implement an API, then authors can customize, control and monitor them. However, if each interactive has a different API, such rich integration becomes cumbersome, requiring custom work.
We have started to build a common API for interactives to share. The first need we had for this common API was the ability for learners to take a snapshot of any interactive in an activity. All of our interactives now use Shutterbug (see “Under the Hood” in Fall 2013 @Concord) to implement this part of the interactive API.
The second need came from the Innovative Technology in Science Inquiry (ITSI) project. There are often several interactives on a single page of an ITSI activity. If all the interactives are running at the same time, the page slows to a crawl. To avoid this, ITSI uses the interactive API to ensure that only one interactive is running on the page at a time. Each interactive sends a message to the page when it starts playing, and each interactive listens for a stop command. With those two pieces the page can coordinate the interactives (see Figure 1 for the code).
In both cases the activity author just provides a URL for an interactive. The API is the same for all of our interactives, so the activity system takes care of the rest. This is just the beginning of an interactive API. In addition to snapshots and coordinating the running interactives, the API should also include requesting and setting the state, event logging, property setting and getting, and data export. These enable other organizations to use the interactives in new ways. Our Common Online Data Analysis Platform (see page 16), for instance, will be able to use the API so any interactive can be integrated without customized work.
The idea of a common API is supported by PhET, which is creating HTML5 versions of their simulations. We are planning to work together to make this API a reality. We hope to make add-ons or plug-ins that support this API for other LMS systems and to attract other organizations to support a common API, too. Join our mailing list at groups.google.com/group/cc-developers to learn more.
API: a defined way of communicating with another program, library or service
iframe: an HTML tag for embedding one page in another
interactive: a simulation or visualization that allows the user to interact with it (e.g., change variables, add or remove features, etc.)
Scott Cytacki (email@example.com) is a Senior Software Engineer.
This material is based upon work supported by the William K. Bowes, Jr. Foundation and the National Science Foundation under several grants (DRL-0929540, DRL-1316874 and DRL-1435470). 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.