To be submitted to Program Chair, Ed-media 98 AACE@virginia.edu

Submission type: Full Paper

Title: Supporting component-based courseware development using the Virtual Apparatus Framework

This paper reports on the latest development of "Virtual Apparatus Framework", an effort at the University of Melbourne to mainstream digital transformation of curriculum. We discuss the component approach to education courseware development, the current implementation of VA framework (communication model, and the scripting model), and describe some application scenarios. In particular, this paper is to be the reference point of version 1.1 of the VA framework.

Jeremy Roschelle and James Kaput, (1997) recognized the need of component software for education as "a mean to escape the consistent pattern of failure" in educational software development. They argued that today's "standard architecture for educational software as large, monolithic stand-alone applications is in structural conflict with educational institutions... Education institutions are typically minimally funded to develop software…Autonomy is of central value so that project leaders are rarely willing to pool programmers to engage in large collaborative software projects... Finally, there is no or little incentive to distribute the final product. Project leaders are generally satisfied at the stage of 'proof of concept'". They proposed that "educational software development must rise to three fundamental challenges:

1. Increase re-use, reduce cost.
2. Integrate diverse capabilities.
3. Enable broad marketplace participation."

Part of the answer to meeting these challenges is to employ component software techniques.

There are several authoring systems that support components sourced outside of their own environments, such as HyperCard, Director and AuthorWare. However these systems are principally designed and mostly used as closed proprietary environments. The "Virtual Apparatus Framework" (VA framework) described in this paper is our effort at The University of Melbourne aimed at mainstream digital transformation of curriculum. The VA framework creates an environment for inter-operability of the key client-side Web technologies of Shockwave, Java Applet and ActiveX and is open to others in the future.

The Education Object Economy (first started on 15^th June, 1997) is an effort to build a community of people working together to improve the quality and availability of web-based learning materials. They have collected over 1000 Java Applets on 7^th October, 1997 and became one of the largest resources for independent Java Applets. We have reservation on the amount of re-use that can be generated by this effort if these Applets (representing hundreds of thousands of men-hour's work) remain to be stand-alone and unable to inter-operate. These applets, within our framework, are not considered as educational components which can participate in an efficient development of courseware basing on inter-operability and re-use.

With the advent of the Web and the potential it offers, we have identified the web browser as one of the major environment in which next generation of courseware will be delivered. We also identified a number of limitations on web delivery [Ip and Canale, 1996a]. The concept of "virtual apparatus" as a means to provide interactivity on a web page was discussed and demonstrated at ASCILITE 1996 conference [Ip and Canale, 1996b]. We have, since, brought the implementation forward to a stage that we are now able to put components built using different technologies (such as Java Applet, Active X controls & Macromedia Shockwave movies) on the same page and have also enabled inter-component communication by using scripting on the web page. This support of different technologies will embrace most technical personnel available in higher education institutes whose existing skill can be capitalize without retraining.

In order to reach the largest possible student population, web-based courseware should be able to run correctly on different common desktop platform using common browsers. Our prototype implementation can be run across different browsers and across different desktop computing platform (currently we are testing our implementation using Netscape navigator 3.0+, communicator 4.0, Microsoft Internet Explorer 3.0+ and 4.0 running under Windows 95, NT and Mac OS). However, we see no obvious technical reason why our framework cannot be used in standalone situation independent of the web. For standalone application, a browser can still be used. Alternately, any container capable of hosting scripting can be used.

Our design of the VA framework also matches the current academic work environment by recognizing the need of specialisation, economies of scale and scope and continuous improvement of courseware. [Ip et el. 1997]

As a technical support layer for building courseware, VA framework has been designed with sound pedagogy in mind. It is designed to meet the challenges facing higher education today. [Ip and Canale, 1997b]. It can support different content models.(See [Fritze and Ip, this volume] for an application of this framework in a major project in The University of Melbourne. Other content models will be described in a later section of this paper.)

The inter-operability of the apparatus is enabled by a communication model within the framework. The messages in most component models are user interface (UI) related, such as mouse clicks, keyboard pressed etc. On the other hand, the messages generated by an apparatus in our framework is a message related to the instructional content (referred to simply as content hereafter). These messages are routed between different virtual apparatus via a standard switching mechanism called VAmessenger existing on the top of a page. It is easy for an author to tap into this switching mechanism and "watch" the messages that have been passed in order to grasp a view of the usage of the courseware under-development.

Technology is changing very quickly. In fact it seems that any standard based on any one particular technology, will almost become obsolete by the time implementation takes place. VA framework avoided this pitfall by making it extensible. We are "riding on the technology wave". By adding wrappers around the technology and requiring the developer to establish communication via a standard code of practice, we are able to embrace different technologies as they become mature.

The last but not the least design issue is that VA framework is a mechanism for providing interactivity on the client-side of the delivery. It must also support innovative features on the server side such as dynamic adaptation of content depending on student performance history and/or background. Separation of content from functionality is the key feature that enabled this. By providing customisable templates of interactivity, the author can "plug in" different version of the same content to meet different learning needs on the fly by appropriate server side technology.

We recognize that there may be three different types of virtual apparatus differentiated by the way instructional content is related to the functions provided by the virtual apparatus:

• Some virtual apparatus are generic and content-free, such as a data logger. A data logger may continuously monitor the performance of a learner and store the information. The information may be used for immediate feedback purpose or for future analysis in the view of improving the courseware.
• Some virtual apparatus is content-rich, such as a simulation of a particular scenario. The virtual apparatus contains the instructional material. The other virtual apparatus support may be required such as a data logger to monitor the performance, or a pedagogical apparatus to provide scaffolding support for constructive learning paradigm.
• Other virtual apparatus may be generic but content-dependent, such as a question shell object [See Fritze and Ip, this volume]. These virtual apparatus requires a mechanism to load the instructional content in order to function effectively.

While the first two types of virtual apparatus can be implemented as Version 1.0 virtual apparatus. Additional support is necessary for the third type of virtual apparatus. Specification version 1.1 is an extension to the virtual apparatus specification 1.0 and defines a standard mechanism to support the generic but content-dependent virtual apparatus. Virtual apparatus developed in accordance to version 1.0 and version 1.1 are inter-operable. The content is expressed in a tagged format and is referred here as VAScript . The specification covers three parts:

• the format of the educational content (i.e. VAScript), and
• the compulsory parser behaviours to handle the VAScript. (Note, a parser should be implemented within the virtual apparatus in order to process the content.)
• support on the browser (using browser scripts) for the VAScript.

The following is the technical specification of VAScript. For more detail, refer to [Ip and Fritze, in preparation].

VAScript Syntax

A VAScript is a tagged document in the form of an XML document with the following notable features:

• The second level tag must be in the following form:

Compulsory Parameter supported by Version 1.1 virtual apparatus

Compulsory Behaviour supported by Version 1.1 virtual apparatus

Virtual apparatus conforming to virtual apparatus specification 1.1 must implement the following methods:

The built-in parser must support the following:

Browser Script support for Version 1.1

When a page contains one or more virtual apparatus meeting this specification, it must implement:

The Learning Engines Project described by Fritze and McTigue (1997), outlines particular forms of interactive objects that can be independently produced and combined into useful learning scenarios. These objects correspond to visualisations, simulations, dialogue shells and interface extension components. The dialogue shell object takes the more important role acting as the controlling agent, creating in effect a dialogue with the learner that can involve other objects. The shell derives its content from a VAScript.

NALSAS model (using peer-to-peer relationship)

Other project, the NALSAS project in our unit, takes a different content model. All the components on the page communicate via vaMessenger and none of the component is in a master position. The flash card, sound player and Pinyin input are version 1.1 virtual apparatus and have their own script. When the page is requested by a student, the server generates three scripts correspondingly. When the student clicks on a "start" button on the tool bar, a message is sent by the tool bar apparatus to the vaMessenger. Using logic written within the vaMessenger, flash card, sound player and Pinyin input receive a command to use their first item in their script. Flash card displayed a Chinese character briefly. Sound player plays the sound corresponding to the flashed Chinese character and the Pinyin input is expecting the student to type in the correct pinyin of the flashed character. After a correct input, Pinyin input send a message to this effect and vaMessenger asks all the other components to advance to the next element in their script. The synchronization is established by index attribute in the second layer tags of the respective scripts.

Another interesting point about the NALSAS project is that while the flash card and sound player are shockwave movies, the tool bar and the pinyin input are Java applets. They inter-operate on the same page using VA framework.

Flexibility in adding data-logging functions as needed

A data-logging apparatus is an invisible apparatus. When the author deems fit, it can be activated by setting a line in the VAmessenger to send a copy of all the messages to the data-logger. In an online environment, the data-logger can establish a direct database connection to the server (e.g. via JDBC using a data logger written as a Java Applet). In an offline situation, another data-logger (e.g. written as an Active X control) writes the data into a local storage. As long as both data-logger has the same VAinfo (i.e. they support the same methods and have the same properties), changing from online to offline delivery implies changing one line of the code. In some situation, it can be automatically generated by the server side component.

Adaptive content delivery using a back-end database server

The functionality provided by the virtual apparatus on the page can be easily customized by a content author or an instructional designer, for example in the flash card example above, by allowing or not allowing the Chinese character to be flashed twice. Similarly, coupled with a back-end database, the content, sent to the virtual apparatus as VAScript, can be adapted according to the performance and/or background of the student easily. This flexibility is enabled by the concept of separating function from content.

While the flash card described above is rather didactic and may fall into the category of practice and drill, imaginative use, such as the Learning Engine, is also supported by the VA framework. The time and effort invested in creating the Interactive Graph Object, for example, can be re-used in different subject area by setting up the IGO using different script. At the same time, IGO can inter-operate with other simulation (in the form of another virtual apparatus) without any additional work on IGO itself. The potential of inter-operable educational object is great and VA framework is a step towards harvesting this potential.

<!ELEMENT VAScriptName - - (SecondLevelTagName)+>

<!ATTLIST VAScriptName

LoadState (auto|preload|incremental) #IMPLIED>

<!ELEMENT DentalScript - - (patient)+>

<!ELEMENT Patient - - (PersonalInfo | tooth+)>

<!ELEMENT Personal - - (Name | age | health)>

<!ELEMENT Name - - (#PCDATA)>

<!ELEMENT Age - - (#PCDATA)>

<!ELEMENT health - - (good | average | poor)>

<!ELEMENT tooth - - (surface+)>

<!ATTLIST tooth

toothPos (#PCDATA) #IMPLIED>

<!ELEMENT surface - 0 (status|material)>

<!ATTLIST surface

surfaceID (#PCDATA) #IMPLIED>

<!ELEMENT status - - (#PCDATA)>

<!ELEMENT material - - (#PCDATA)>

<DentalScript loadstate=incremental>

<patient >

<PersonalInfo>

<name> Joe B.</name>

<age>45</age>

<health>good</health>

</PersonalInfo>

<tooth toothPos=1>

<surface surfaceID=1>

<status>caries</status>

<surface surfaceID=2>

<status>filled</status>

<material>amalgam</material>

</tooth>

<tooth toothPos=12>

<surface surfaceID=3>

<status>caries</status>

</tooth>

</patient>

</DentalScript>