Adaptability and interoperability in the field of highly interactive web-based courseware

Abstract

Developing and managing Web-based courseware has become a well-understood process. We all know how to create educational content, including interactive Java applets, and deliver them via the Web. Working groups are currently drafting standards for organizing learning objects in digital libraries. The vision is clear: developers will share their modules within repositories, and educators will select the best-fitting modules for their own courses, just in time, just in place.

This article examines related obstacles with interactive learning objects and outlines possible ways to overcome them. Even the creation of a single self-contained interactive module with didactical value is time consuming and expensive. Its use (and reuse) entails further requirements. Educators would like to adapt layout, appearance, or functionality to their curriculum. Learners would like to ask questions in discussion boards referring to specific configurations, and explore and share their own setups. How can we reuse highly interactive learning objects, particularly in terms of adaptability and interoperability?

We review how reusable software components and a scripting architecture allow for creating interactive learning objects that are adaptable in all aspects and interoperable with other learning objects. Next, we discuss how we may enable developers, educators, and learners—respectively, a courseware's “community”—to share efforts and collaborate in getting highly interactive Web-based courseware off the ground. Authors may define and modify scripts using online wizards. We present a prototype script database that is rated, annotated, and extended by community members, and close with showcases in the areas of Computer Graphics and Visualization.

Introduction

The field of highly interactive Web-based courseware embodies state-of-the-art concepts in science, math, engineering, and technology (SMET) education.

We usually accompany well-proven traditional teaching concepts such as the textbook, lecture, laboratory, homework, and exam with modern constructive concepts, i.e. exploratory/discovery learning [1] or microworlds [2]. Here, we concentrate on technical aspects; details of learning theories and their application to Web-based courseware can be found, e.g. in [3].

Highly interactive learning objects visualize complicated topics and relationships graphically and allow for continuous, bi-directional interaction with all essential parameters. The technical concept is a component-based software architecture [4]. Software components are reusable pieces of code [5] that can be plugged together to create educational modules, i.e. learning objects [6]. We will discuss aspects of our own architecture in Section 2.

Many projects create repositories collecting software components [5], [7] or learning objects [4], [5], [8], [9], [10] to enable the education community, among them developers, educators, pedagogues, and designers, to share labor and work together in creating the best-possible learning material. Working groups [6], [11], [12], [13], [14] currently standardize the technological base for digital libraries [15] with search and browse functionality, virtually spanned over various repositories all over the world.

At present, standardization efforts focus on non-interactive (text, illustrations, animations) and low-interactive educational learning objects (quizzes, click-maps, based on, e.g. HTML, JavaScript, or Flash). The complexity of highly interactive learning objects has not yet been fully recognized; they have been treated like their low-interactive counterparts. Therefore, our initial goal in this article is to provide some hints on how to include issues of interactivity and interdependencies of software components into a digital database. We will discuss an application of the learning technology standard Sharable Content Object Reference Model (SCORM) [14] in Section 5.

Apart from open questions concerning intellectual property, billing, and quality assurance, we face severe problems with a learning object's reusability. Our second objective is to leverage the use and reuse of highly interactive learning objects we witness as integral part of our Web-based courseware [4].

Even the development of a single non- or low-interactive object is time consuming and expensive. Authors struggle with specifying required metadata, making design and layout adaptable (e.g. using CSS or XSL), and creating self-contained, modular content. Nevertheless, educators will usually spend additional time to customize content in order to integrate a learning object into their courseware or curriculum.

As in the case of a highly interactive learning object, end users would like to adapt layout, appearance, and functionality to their needs. Style sheets are not used: developers pack software components and learning objects together with source code or employ pre-defined public properties with scripting functionality [10]. While the first approach excludes non-programmers, the second one heavily constricts adaptability.

A more suitable concept is to base ourselves on an open software architecture [16] that supports integrating, extending, and customizing software components by definition. Again, a scripting language represents the interface between the learning object's interior and those outside the developer group. We follow Roschelle [17] and characterize scripting as lightweight programming with a simplified programming language. The difference to the approach above is the fact that here it is not a single software component that performs scripts, but the architecture. Using architectural scripting, we may arbitrarily redefine a learning object's functionality or exchange any of its software components, which in turn enables us, e.g., to match a learning object's setup with the current paragraph or illustration of the learner's course book, or simultaneously visualize described properties and special cases. We will present our scripting architecture in Section 3.

We have now slightly moved from an object's adaptability to a related issue: interoperability. If we want to create a learning object that educators will actually include in their courseware, we have to ensure that it is not only adaptable to another context, but also interoperable with other learning objects.

A poorly implemented interoperability of learning objects reduces the actual profit of Web-based courseware. In particular, highly interactive learning objects appear isolated: we can neither control them sufficiently from their context (e.g. by modifying parameters or functionality) nor interlink them properly with other objects (e.g. synchronize a learning object with a guided tour).

Technical issues seriously constrain interoperability of Web-enabled learning objects. With (X)HTML, the publishing language for Web-based courseware, a browser plug-in represents the only possible way to overcome its low-interactive functionality. Some of the widespread plug-ins are Sun's Java Runtime Environment (JRE) and Macromedia's Flash MX; for educational reasons we base our approach on the first one. Others, such as SVG or X3D, are promising but new, and struggle with the Web community's acceptance. The current plug-in technology is another motive for scripting—it represents the only established communication model to work with all major browsers [11]. Next-generation Web-based courseware is likely to build upon Microsoft's NET Framework or Sun's Open Net Environment that promise to fulfill the long-term objective of interoperability.

While advancing towards the organization of highly interactive learning objects in digital libraries and assuring their reusability by scripting, we naturally face a third challenge. How may we support a courseware's community in authoring, customization, and personalization in the best-possible way? How may we benefit from community's work, e.g. include user-defined learning objects, components, or scripts?

Developers cannot foresee and implement all the desired functionality of a highly interactive learning object. A framework that covers all fields in SMET education exceeds the manpower of any developer group [5], [18], [19]. At first, creating highly interactive learning objects requires expertise in subject, programming, pedagogics, didactics, and design. Second, employing them in a Web-based courseware requires a team of educators, tutors, and administrators who are able to perform Web-based authoring and scripting. A decentralization of required knowledge might be the only way to guarantee a courseware's sustainability and continuous enhancement.

From learner's view, Web-based courseware must offer cooperative tools such as discussion boards, chat, or annotations [20]. In [21], we demonstrated how to generalize scripting to a multi-user architecture that allows for remote tutoring. Our students’ feedback reveals the need for cooperative tools that allow reference to specific configurations, or sharing their own setups. Some of our programming exercises result in new scripts, software components, and learning objects that extend our courseware. Of course, we would like to include their work into our system.

Database technology plays an essential role in the context of decentralization and distributed work. We usually organize all core data in databases and generate our courseware automatically, using templates and style sheets [21]. Online wizards [22] allow for distributed modification of core data; user input is versioned and, after verification of an editorial board, integrated into the underlying database. Lastly, a rating system (including access statistics and questionnaires) assures quality by maintaining profiles for authors, participants, and content.

We are all familiar with online wizards that allow for online modification of non-interactive content. In the case of highly interactive content, this task is still an unsettled challenge. Scripting, however, is already a well-known paradigm for changing Web content. Yaron [23] mentions that most members of the educational community are familiar with Web-based authoring such as using hypertext links or image maps. In Yaron's view, it is straightforward to go from hypertext linking to sending scripts to a learning object. Consequently, Yaron defines his own protocol for these kinds of links [19]. Therefore, we have developed online wizards for scripting together with a script database. We will present prototypes in Section 4.

Showcases of our courseware for Visualization and Computer Graphics in Section 6, and online at http://www.gris.uni-tuebingen.de/projects/vis may be experienced.