As a physics teacher for almost two decades, I just take it for granted that when I design an experiment for my students, I don't need to worry about the design of an apparatus. I go to the laboratory preparation room, look at what kind of apparatus are there that I could use to illustrate the idea I would like to teach, hook the apparatus together, play with them a bit, get some sample data,... When I'm satisfied, I write a lesson plan, a laboratory manual or some other helpful handout. I bring these apparatus into the class and do my lesson.

[OK, I must confess that I don't make lesson plans all the time and sometimes I do make some simple apparatus to serve a special need! ]

A barrier to mainstream adoption of digital technology for educational delivery (for the Web in particular) is the authoring part of the exercise. Web technologies, such as HTML, tables, frames, JavaScript, Java Applets, ActiveX controls, Macromedia shockwave movies, push technologies, etc. come out too quickly for anyone to really understand what is happening let alone use them in an educationally responsible manner. Content experts are finding it very difficult to cope with the technology. Computer scientists don't have content expertise in all the courses offered by a University. The need for collaboration (or a "distributed team") approach is obvious.

The contrast between two preceding paragraphs, unrelated as they might seem, underlies the main aims of our "virtual apparatus" framework. Why can't an academic producing courseware (online or otherwise) work like a science teacher producing a laboratory demonstration? We could speculate that all the animation, display enhancement, student interactions, data capturing mechanism, navigation control...could be provided by a variety of "apparatus". The academic no longer pays attention to what makes an apparatus work. The academic can now concentrate on creating the best learning environment for the students. The responsibility for achieving all these apparatus resides with the technical experts working in collaboration with many academics in different fields of study. This division of labour encourages software reuse and is a powerful mechanism for overcoming the expensive nature of courseware development.

The first requirement of the "virtual apparatus" specification is that these "virtual apparatus" may be written in many types of technology such as Java Applet, ActiveX control and Macromedia shockwave movies. We want these "virtual apparatus" to work on the main desktop platforms: Windows and Mac. (Of course, a "virtual apparatus" implemented using ActiveX controls may not run across platform by the nature of the programming language.) We also want a web page populated with "virtual apparatus" to display correctly in different browsers (Netscape and Microsoft at the moment) without modification.

The second requirement of the framework is the separation of content from web functionality. Hence it is possible for a group of people interested in "virtual apparatus" to develop generic components. Content experts take these "virtual apparatus" and use them to deliver the content. The content "drives" the "virtual apparatus" using mechanisms such as parameters embedded on the web page, together with the "virtual apparatus", or as a separate entity stored on the server to be fetched by the "virtual apparatus".

Since our "virtual apparatus" can be written as Java Applets, ActiveX controls or Macromedia shockwave movies, we can solicit a wider scope of people as "virtual apparatus" developers. We shall provide classes (for Applets and Controls) from which "virtual apparatus" can be derived. We shall also provide behaviours in Director 6 to ensure a lower learning curve to use shockwave movies as "virtual apparatus".

It is important to note that in this framework the content and functionality are two independent concepts and should not be mixed. By enforcing the distinct nature of content and functionality, this framework supports the use of a database at the back end to drive more sophisticated web pages such as adaptive content pages. This requirement also enables a two-tier courseware development architecture with a production and consumption relationship. "Virtual apparatus" developers, who work with bits and bytes, produce "virtual apparatus" for content expert consumption. The generic "virtual apparatus" can be used by different content experts. On the other hand, the content experts can choose from a range of "virtual apparatus" from different developers, or may choose to develop the "virtual apparatus" themselves if they are willing to invest the effort and time! When we have sufficient "virtual apparatus" available, a significant part of courseware development effort would be reduced to a choose-and-pick exercise and hence, we believe, will result in a lowering of cost and raising quality.