1 Introduction
This paper discusses our approach to the construction and organization of interactive content for educational digital libraries such as the NSDL (National SMET Digital Library http://www.nsdl.nsf.gov). The desirability of including active learning experiences in such libraries highlights the need for flexible interactive content. SMET (Science, Mathematics, Engineering and Technology) instructors are increasingly interested in incorporating interactive technology in their courses and a number of projects are providing support for this need. For instance, a number of projects (e.g. Roschelle 1999 and Birbilis 2000), including our collaborators at Brown (Laleuf 2001), are currently focusing on the challenge of developing flexible software components that will facilitate the development of high-quality educational software. Collections such as MERLOT (CSU CDL 2001) help instructors find and use these materials by both tagging the content for search and retrieval and providing peer review. However, the entry in such collections is currently an executable piece of software, and this leads to content that is difficult to adapt to the diverse needs of the educational community. For a particular piece of software to be useful, there must be good alignment between the goals of the instructor and the goals of the programmer who created the content. Even if source code is available, and the changes required to make the content useful in their particular classroom are small, instructors do not typically have the time or expertise needed to implement them. More generally, the current approach to educational software construction places most of the creation process in the domain of computer programming. This excludes many members of the educational community whose pedagogical and classroom expertise could be well used to create effective learning activities, but who lack the technical expertise to participate fully in the creation process.
Our goal is to redefine the line between those activities that fall within the domain of computer programming and those that fall within the domain of content authoring, to invite a broader and more diverse community to participate in the creation of interactive content. This is done by separating content from software in a manner that promotes flexible content creation, and by providing an authoring environment that capitalizing on users' familiarity with Web content. The result of the authoring process is a set of linked active content (Yaron 2001), which is similar in structure to a hypertext Web site but that supports flexible inclusion of simulations and visualization tools. The extraction of content from software also promotes better organized collections that may be more easily repurposed and adapted to local classroom needs.
This approach is implemented in CreateStudio (http://ir.chem.cmu.edu/create/), a development environment that allows users without programming expertise to create interactive educational activities by configuring and assembling learning objects. The system is based on open standards. It is straightforward for programmers to add learning objects to the authoring environment such as simulations or visualization tools for earth science, physics, biology or other content domains. Authors without programming expertise may then create activities that combine these domain-specific learning objects with learning objects that support cross-domain functionality such as text and multimedia. CreateStudio thus serves as a collaboration point between programmers and curriculum authors where collections of compatible learning objects can be flexibly combined to produce interactive learning experiences.
A key element of the approach is the extraction of content from software, where possible. This is done by having the software serve as a viewer for a particular type of content. For instance, a Web browser serves as a viewer for HTML content, which is interactive to the extent that the user may choose their own path through a set of hyperlinked text and images. With current Web technology, additional interactivity is achieved through plug-ins that serve as viewers for different types of content, such as movies or 3D scenes. These plug-ins typically have three aspects: (1) a file format, or content specification, such as avi movies or VRML scenes, (2) authoring tools for creating this content such as Adobe Premiere or Bryce and (3) a viewer that serves as the plug-in for the Web browser. The learning objects in CreateStudio share this property; they are software components that view a particular type of content, which has an associated file format and a means for non-programmers to create such files. For example, molecular viewers such as RasMol and CHIME that are familiar to science educators are clearly in this category.
Another key element of the approach is the extension of the hypertext link concept of Web development, to include passing of messages between learning objects. In current Web development, a plug-in may appear on an HTML page. There is typically little communication between the plug-in content and the overall HTML, such that the plug-in appears as a single word in the Web page. Due to this lack of communication between the plug-in content and the overall HTML, even those portions of the software, such as text and images, which could be handled with HTML must instead be embedded into the plug-in. This typically leads to monolithic chunks of content that are difficult to adapt and reuse. Although this active content often consists of subobjects with relationships, similar to a hypertext Web site, the limits of the technology prevent the substructure from being made explicit and connected to the encompassing HTML, such that it can lead to better organized digital library collections. This limitation can be largely overcome by allowing message passing between learning objects, without introducing the dynamic complexity that could result from more complex communication patterns. The only type of bug is a broken link.
2 Overview of CreateStudio Interface
CreateStudio is laid out with three main panels. As shown in Figure 1, the File panel, on the left, holds the XML files which store the content and configuration for a learning object. The names of the files are displayed in a list, similar to the way existing files are listed in other programs, such as Microsoft FrontPage.
The panel on the right is the main work area, where users build frames and create content. The frames in CreateStudio hold different objects and can be linked to pass information between them, much like the way frames work on Web sites.
The customizable tool panel is in the middle of the CreateStudio window. These tools change, depending on the content of the active frame. For example, if a text editor is loaded into a frame, the tool panel will remove any existing tools and replace them with the pre-configured text editing tools (see Section 4.4).
In general, the goals of developing an educational project in CreateStudio are to:
- determine the layout of the frameset
- create and name frames
- load content-specific editor
- load content from Collections
- link the frames
Creating a layout involves making empty frames of a desired size and shape, which will eventually hold the learning objects. We call the collection of frames on one page a frameset. To create a new frame, the user draws a box with the mouse in the main work area.
One standard format for a frameset includes two frames: an upper frame which might hold video or simulations, and a lower frame to hold text or image maps which might hold instructions about the top frame or enable navigation through the activity. The user then names each frame, using the same convention for naming frames as in Web sites (for example, upperFrame and lowerFrame in Figure 1).
Once a frame is created and named, the user adds content by selecting that frame and loading an editor (e.g. ImageMap Editor, TextEditor, QuickTimeVR Editor). The user can switch between editing the different frames by clicking on the title bar of the frame. The toolbar in the middle panel will change according to the content of each frame. Users can easily create new content for a frame by saving the current content and loading a new editor into that frame.
Generally, users will load content from Collections stored within the CreateStudio environment that are drawn from many digital library sources. For example, loading an image brings up a dialog box of the available local images. Users may also add their own images to the local collections. Text content can be created directly within the frame or copied into the frame, just as an in a word processor.
Linking the content of the frames enables the content in one frame to control the events in another frame. An image map might be used in one frame to control the behavior of a movie in the other frame. As shown in Figure 2, hot spots on an image map in the upper frame can allow students to select among different movies, such as different characters to interview in a murder mystery activity. To make the link between the hotspot and the corresponding video, the user creates a link using syntax described in section 4.3, such as fset://upperFrame.load(yervin.xml), where yervin.xml is the content file for the movie viewer.
Figure 2. CreateStudio authoring tool, shown while editing an image map in the upper frame to attach an extended link to the hotspot (click the image for a larger view)
Note that even though the different types of content require different viewers, the content XML file dictates what the appropriate viewer is, so a user/author never has to load a viewer. If the upperFrame contains a movie XML file, then a movie viewer is loaded. CreateStudio does this automatically when switched from Edit mode to Preview mode.
The process of designing a project for students can be iterative, so users can switch between preview and edit mode at any point. In Preview mode, users can view the project as a student would see it and can go through the project step by step, similar to the Slide Show component of Microsoft PowerPoint (see Section 5). It is also possible to save and return to a project at any stage of its design in order to compare various versions.
In summary, designing an interactive project in CreateStudio is analogous to using a flexible XML editor. For projects involving simulations, the user can think of CreateStudio as an editor that allows him or her to configure various parameters for, say, a combustion engine. The product of the authoring process is a set of linked XML files analogous to a Web site. As the user moves through the content, different pages are loaded into various frames. The difference here is that each file specifies its type of software viewer. This content also has extended links embedded within it.
3 Benefits of Linked Active Content
The discussion in the previous section illustrates how linked active content allows an instructor without programming expertise to guide a student's interaction with active content. For instance, with the two-frame structure in Figure 1, the lower frame can provide text that guides students' interaction with simulations and other active content in the upper frame. The combination of linked active content and image maps is surprisingly powerful in that it enables an instructor to create an interface through which students may interact with a simulation. For instance, in the application of Figure 3 the control panels to the right contain an image map with buttons labeled launch and reset. The image map editor in CreateStudio was used to make these into hotspots. When the mouse passes over these hotspots, bubble help appears to tell the student the consequence of clicking on the launch button. When the launch hotspot is clicked, a message is passed to the trajectory simulator that launches a rocket for a mission from Earth to Mars. The lower window contains an image map with "editable" hotspots that are created in a manner similar to a standard hotspot, but which accept text input from the user and pass this to the simulation.
Figure 3. Mars Simulation exercise with simulation frame (top left), control frame (top right) and parameter frame (bottom) (click the image for a larger view)
This functionality allows an instructor to create interfaces to simulations, and to alter these interfaces to change the focus of students' attention as they move through an activity. This supports a useful division of labor between programmer and instructor. The programmer need only create an interface that is understandable to the instructor, in the form of the types of messages that a simulation or other learning object can accept. The instructor then creates an interface for the student, taking full advantage of their pedagogical expertise and classroom experience.
Linked active content also allows educators to use images, video and other multimedia to place activities in contexts that can enhance interest and meaning for students. For instance, we are currently developing a murder mystery activity for introductory chemistry that combines videos of the crime and interviews with suspects, with QuickTime VR images that allow students to explore the crime scene and other locations. These QuickTime VR images contain hotspots that pass messages to our chemistry virtual lab (http://ir.chem.cmu.edu/irproject/applets/virtuallab/), a flexible simulation of solution chemistry. For instance, when a student clicks on a glass at the crime scene, a message is passed to the virtual lab, telling it to load a particular solution. The student can then perform experiments to see if the glass contains poison. A similar mechanism can be used to allow students to explore a river system, collecting samples and helping track down potential sources of pollution.
The above examples illustrate some of the power that arises from allowing message passing between objects. Considerably more flexibility could be obtained from more complex communication means, such as those available in a JavaBean assembly environment (Englander 1997). However, message passing has the advantage of limiting the types of errors that can arise due to "broken links". Such broken links should be easy for a non-programmer to identify and correct. Environments such as the BeanBox can help non-experts assemble software, but when things go wrong, the errors issued come from a Java compiler and require considerable expertise to understand and fix. Rather than start with programming as a paradigm and attempt to simplify it for non-experts, we begin with Web authoring as a paradigm and add functionality that increases power and flexibility, without large costs in complexity. Our hope is that this will lead to a powerful yet user-friendly approach to the construction of interactive content.
4 Architecture
The output of the authoring process in Section 2 is a set of XML files that contain linked active content. CreateViewer is a Java program that serves as a browser for this content. Most of the functionality required for the browser is already present in the Java Virtual Machine (JVM). The key underlying technology is dynamic class loading, which allows the JVM to load executable software (Java class files) on an as-needed basis. When the user browses to a particular XML file, CreateViewer examines the XML file to determine the software viewer associated with that content, and loads the appropriate class files. The dynamic class loading functionality of the JVM supports browsing through the executable content. Thus the CreateViewer is a small, thin Java program.
Dynamic loading of software objects is available in essentially all modern software systems, including .NET (http://www.microsoft.com/net/), so this approach can be implemented on other platforms. We have chosen Java for its support for Web delivery, its cross-platform abilities and potential, and its popularity in educational computing. Note that a port to a different platform would require porting only the software viewers and authoring tools; the content files would be unaltered.
A fundamental design goal is to provide the required functionality while imposing as few restrictions as possible and promoting extensibility where possible. The following is our current solution, although we are open to changes as we and others continue to work with the tools.
4.1 CreateViewer
The CreateViewer handles several responsibilities. It initializes a Java application or applet and creates the graphical panel on which the learning objects will be displayed. It is responsible only for this top-level panel. The frameset viewer handles the division of this panel into frames that can hold other content, as illustrated in Section 2. The frameset viewer is a learning object that is dynamically loaded by CreateViewer. This approach allows other developers to provide alternative frame and screen handling systems, such as floating windows or tabbed panes.
When an XML file is loaded, CreateViewer parses the file to determine the viewer associated with the content and loads the appropriate class files (see Section 2). It keeps a name registry of those objects that can accept messages via extended links (see Section 4.3). Finally, it serves as the top of a chain-of-responsibility system for passing messages between learning objects (see Section 4.3).
4.2 File Format
When CreateViewer loads a content file, it needs to determine the learning object that is used to view that file. We therefore require the file to be in XML format, and to contain an application resource locator (ARL) [see Note 1] to the appropriate learning object. Similarly, the CreateStudio authoring tool must determine the editor appropriate for the content, and so the XML file must contain an ARL to the appropriate editor.
Note that the constraint of XML formatting is not restrictive, since the XML file may link to other file formats, such as avi for movies or VRML for 3D scenes. In most cases, we have simply created an XML file with pointers to the viewer, editor, and a file containing the content.
4.3 Link Parsing and Message Passing
The CreateViewer must coordinate the passing of messages between learning objects. To make this maximally flexible, we allow programmers to add their own parsers to the environment. This is done through a "Chain of Responsibility" design pattern (Gamma 1994). The CreateViewer is at the top of the chain, and it examines the link to determine the appropriate parser. The parser is specified by the text preceding the first occurrence of "://", with all text after the first occurrence of "://" being passed to the parser. A link then has the form
A://B
where A is a text string that specifies the parser and B is a text string that will be passed to this parser. The parsers are dynamically loaded Java class files. On startup, CreateViewer reads an initialization file that lists the names and ARLs of the parsers.
To support dispatching of messages from the parser, CreateViewer keeps a NameRegistry that holds the names (as character strings) of Java objects that are able to accept messages, along with Java references (pointers) to these objects. Learning objects that are willing to accept messages must register themselves with the NameRegistry.
As a concrete example, consider the frameset learning object that orchestrates the frames upperFrame and lowerFrame in Section 2. The frameset learning object provides its own parser, which will receive all links that begin with fset://. The frameset learning object also registers the names upperFrame and lowerFrame with the NameRegistry, along with Java pointers to the corresponding frames. In the example discussed in Section 2, a text viewer contains the following link
fset://upperFrame.load(yervin.xml)
When this link is activated, the entire string is passed to CreateViewer which, based on the string fset, loads the parser provided by the frameset learning object and passes it the string upperFrame.load(yervin.xml). This frameset parser then accesses the NameRegistry to obtain the Java object corresponding to upperFrame, and calls its load method, passing it the string yervin.xml that specifies the file to load.
Java's support for introspection allows for the construction of generalized link parsers. Using introspection, a Java program may query a dynamically loaded learning object for a list of its methods (i.e. subroutines) and the data required by these methods. A parser can then be generated that can support links of the form
pars://target.action(data)
where target is the name of an object stored in the NameRegistry, action is the name of the method to be called on this object, and data is the parameters to be passed to this method.
We are currently working on a dialogue-driven authoring tool for this type of link, which will insulate the curriculum author from the link syntax. The tool will first present the author with a list of available targets, then present a list of the actions supported by the selected target, and finally query the author for the appropriate data.
4.4 Adding A Learning Object
The environment is designed to make it easy for programmers to add their own simulations and viewers. These learning objects consist of the following:
- File format for the desired content, including an XML file with tags that point to the viewer and authoring tool.
- Viewer that is loaded by CreateViewer to display the content. For the viewer to accept messages, it must register its objects with the NameRegistry of Section 4.3.
- Editor that is loaded by CreateStudio to allow editing of the content. This will ideally take the form of a tool panel that appears in the middle panel of CreateStudio in Figure 1.
- Custom link parser, if the general-purpose parser of Section 4.3 does not provide sufficient functionality.
Currently, a programmer must modify the Java source code to provide the above functionality. This can be a fairly simple task. For instance, the addition of the Jmol molecular viewer (Gezelter et al. 2000) as a learning object to CreateStudio required less than a day of coding.
Furthermore, using introspection, it will be possible to automate this process, especially for Java software that adheres to the JavaBeans standard (Englander 1997). CreateStudio can easily handle the creation of an XML file that tags the viewer and authoring tool and points to the file containing the content to be viewed by the JavaBean. The editor can be generated automatically by using introspection to determine the available methods, such as those that set relevant parameters for a simulation, and generating a form the author may use to set these parameters. (This is the approach used by JavaBean assembly environments.) The adapter design pattern (Gamma 1994) can be used to force the viewer to register its objects with the NameRegistry. This is done through a Java adapter class that couples the JavaBean to Java code that handles the name registration.
5 Closing Comments
The CreateStudio authoring environment and associated linked active content are designed to promote the creation of interactive content for educational digital libraries. By redefining the line between those tasks that fall within the domain of computer programming and those that fall within the domain of content authoring, this approach allows instructors without programming expertise to contribute more effectively to such collections.
The separation of content from software also leads to a number of advantages for digital library collections. In particular, it allows interactive content to be modified and adapted to the needs of a particular educational setting. Consider, for instance, instructors who would like to modify a certain activity to adjust it to the abilities or interests of their students. They may, for instance, want to change a particular section of text to provide a different explanation, or alter an image map that serves as an interface to a simulation. To make such a change, they need only load the content into CreateStudio, enter preview mode, and step through the application to the relevant point. They can then switch CreateStudio to edit mode, make the desired change, and save the results to a new set of linked active content.
A similar process allows an instructor to reuse portions of existing activities in their own projects. In addition to providing a more useful and evolving collection, such repurposing of existing content provides an entry point for new users, allowing them to become familiar with this new approach to authoring without needing to create a new project from scratch. Our hope is that this approach to the construction of interactive content will promote the growth of a vital community of both programmers and instructors, collaborating to improve education by making effective and motivating student activities widely available in digital libraries such as the NSDL.