Multimedia Education Unit
The University of Melbourne
Parkville, VIC 3052
Multimedia Education Unit
The University of Melbourne
Parkville, VIC 3052
This paper introduces a conceptual
model of "virtual apparatus" for designing virtual experiments
with the emphasis on minimising the technical burden on the teacher
by using generic programmable objects. A virtual apparatus is
a reusable software component which non-programmers can set-up
and modify using a forms based interface. Some virtual apparatus
behave like real world objects such as a beaker or pulley and
provide a simple and intuitive interface for the teacher. Like
its real world counterpart, a virtual apparatus can be used by
a teacher and students in an experiment. Other virtual apparatus
may be hidden, performing monitoring functions to provide feedback
to the teacher as well as providing a mechanism for moving the
simulation from novice to more advanced levels. For this concept
to be viable over Internet, these apparatus must adhere to a strict
set of open and common software specifications to ensure inter-operability
between virtual apparatus from different sources and perform across
different computing platforms.
Virtual experiments, or simulations,
are highly valued teaching and learning tools. Virtual experiments
are not exact duplicates of their real-world counterparts, and
therefore can provide educationally valuable features not available
in real world experiments. Some early adopters recognise this.
In his introduction of his virtual Physics laboratory at the University
of Oregon, (Bothun 1996) states:
"In the interest of providing
students with truly interactive texts, ... These experiments are
meant to be conceptual interfaces to the equations of physics
and/or represent interaction with data that simulates a real physical
experiment. The whole purpose is to shape student-driven inquiry
and to lead students through the discovery process which is what
science really is."
He goes on to say that:
"Some experiments duplicate
what could be done in the lab (eg. the virtual circuit) while
others can't really be done in the lab even though they are relatively
straight forward (eg. Newton's Second Law applet). "
An experimental study of Newton's second
law requires a frictionless experimental environment and a point
mass, ie an object with mass but without volume. The best analog
in real world can never compare to the simplicity and elegance
of a virtual experiment of this kind.
Another interesting example of a virtual
experiment is a simulation of a nuclear power plant (Eriksson,
1996) where the user tries "to keep the reaction stable when
component failures occur!".
Running the risk of a learner-operator
causing a serious mishap in a real nuclear power plant just for
the sake of learning how to control the power plant properly is
clearly an unacceptable level of risk.
There may also be a resource-related
rationale for using virtual experiments. For example, some virtual
experiment sites may have saved the lives of many frogs (Eriksson,
1994; Kinzie, 1994). The images of the frog in the first web site
are computer-generated and the second web site takes another approach,
in which photos and movies are used to follow an actual frog dissection.
So too, the visible human project (US
National Library of Medicine, 1995) may provide source material
for virtual experiments such as fly throughs of organs simulating
medical procedures such as colonoscopy (Kaufman, 1995)
As the level of interactivity offered
by a web-based education system develops higher levels of sophistication,
the learners' expectations will simply grow at a faster pace.
It is becoming more and more difficult for educators to cope with
the ever-increasing demand to author interactive on-line course
materials. This paper looks at a model which may minimise the
technical demands placed on teachers wishing to explore the benefits
of virtual experiments.
2. Technology overview
To create a reasonably responsive virtual
experiment, a compromise has to be made to balance the requirements
of communication and computation. In general, when the computation
power is provided by a server, the demand on communications will
be high. One example of using the server to provide the computation
is the virtual frog experiments above where a powerful server
is used to process the requests from the clients and return the
images in a generated html page. This approach is suitable in
situations where the main processing cannot be provided by the
client's machine (eg a large amount of image rendering, creation
of on-demand movies etc.) This approach also generates a lot of
traffic on the network and the response time is usually unpredictable.
When sufficient computational power
is provided by a local client machine, there will be less demand
on communications. One example is the virtual Physics experiments
at the University of Oregon. The examples cited above are implemented
using Java and/or JavaApplet. The simulation is an application
by itself and is running at the client-side. All we need to view
and work with the simulation is a Java-enabled browser such as
Netscape 2.0 or above. The initial download may take a while,
thereafter, the processing is all done by the client machine and
hence is independent of the network traffic conditions. At present,
a fairly high-end desktop machine would be necessary to provide
sufficient computing power.
This paper focuses on a model of implementation
assuming that the computation power is provided by a client machine,
but connected to the Internet for initial data requests and download.
The complex technical requirements
needed to create interactive virtual experiments are some of the
major hurdles that educators need to overcome before we can see
mainstream adoption of this concept. We believe that all the examples
quoted above are supported by competent support personnel and/or
are major funded research projects. To take this technology into
mainstream education, we need to make the creation of the content
3. Educational Overview
In real world experiments, apparatus
are typically acquired from some apparatus manufacturers. A teacher
would design an experiment basing on the apparatus available.
The instruction to the learner will typically describe how the
experiment would be set up using the available apparatus, how
these apparatus would be manipulated to alter some of the experimental
conditions, how to watch and take note of the changes and how
to interpret the results. Such didactic instructions would not
be very motivating and provide little room for the learner's own
A more learner-centred approach would
be to give a set of guidelines (not exact experimental procedures)
and ask the learners to design and work through the experiments
themselves. However, there are logistic limitations of such an
approach, eg the safety concerns of experiments designed by learners,
the availability of the physical apparatus, the amount of supervision
that the teacher can realistically provide to a number of learners
doing different experiments.
If we take the scenario into a virtual
environment, some of the limitations no longer apply. For instance,
there should not be any real concern of safety even if the experiment
is explosive. The virtual explosion will hurt nobody and cause
no real damage. The availability of the apparatus is now only
limited to the computer resources available. The same virtual
apparatus can be used by as many students as allowed by the software
license agreement. Since the safety issue is no longer of prime
importance, the supervision shifts from ensuring safety of the
students to more educationally oriented objectives such as the
feasibility of the experiments, the actual learning outcome, the
motivation level of the learners and scaffolding support to the
4. The Virtual Apparatus Model for Authoring
of Virtual Experiment
The virtual apparatus model is based
on the component model in software engineering. Virtual apparatus
are software components that can be dynamically combined together
to create a virtual experiment. There are three major components
in this model:
ï virtual apparatus
ï virtual experiment work bench and
ï the software glue.
In technical terminology, the virtual
apparatus are Component software, the virtual workbench is the
components container while the software glue is the scripting
language available to that software platform. The current implementation
will be based on Java and the Microsoft's ActiveX technology using
Internet Explorer 3.0 as the default web browser. However it is
just a matter of time for Java Beans from Sun Microcomputer Systems
or other component software vendors to come up with alternative
solutions which can offer similar functions. The virtual apparatus,
however, should meet additional requirements if we are aiming
at a reusable, friendly and workable model.
The virtual apparatus should share
some of the qualities people are already familiar with in physcial
apparatus, in particular they can:
ï be manipulated easily,
ï assemble together to form new experiments,
ï reflect behaviours of the real
Teachers designing a virtual experiment
would typically create a virtual experiment work bench which is
a web-browser supporting this technology (currently, Microsoft
Internet Explorer 3.0). A number of virtual apparatus would be
selected from some repository and put on the work bench.
Some of these virtual apparatus would
be visible and hence will be rendered by the browser software.
Others would be invisible and used in other ways as described
to link the apparatus events together.
The experiment workbenches can be saved
as html web pages together with some other textual information
and can be accessed by learners. When the learner opens such a
web page, the web-browser would download the required virtual
apparatus if they were not already on the client machine. The
learner interacts with the virtual experiment by clicking, dragging
and so on. This interaction fires up events by the virtual apparatus.
The events are passed to the scripting language and processed.
Other virtual apparatus may receive messages from the script and
respond accordingly, creating the necessary response to the learner's
5. Software Requirements for virtual apparatus
Some of the requirements appearing in
the following list are already implemented as part of the Java/ActiveX
specification. They are listed here for completeness:
ï Each virtual apparatus should be a logical computational unit, a file by itself at this moment. To allow and encourage reuse of the same virtual apparatus, the apparatus should not be unnecessarily dependent upon other virtual apparatus. Each of the virtual apparatus shouldsupport use on its own.
ï A virtual apparatus should have a functional part (that mimics the behaviour of a real-world counterpart) and for those virtual apparatus that are visible, a visual interface (the graphical representation of the apparatus). The functional parts are public functions exposed by the software which the script can use. The initial behaviour of the virtual apparatus should be controlled by a set of parameters set by the virtual experimental work bench during initialisation.
ï A virtual apparatus should expose all its public methods and variables for easy authoring in authoring mode. In run mode, this feature must be turned off. However, there is no automatic method of doing this. Our suggestion is to use a software key. If the key is present, the virtual apparatus should recognise that it is in authoring mode, otherwise it is in run mode.
ï One of the (standard) methods should provide a comprehensive description of the functions of the virtual apparatus. This requirement is necessary to dynamically create a search interface for any repository of virtual apparatus.
ï A virtual apparatus should be
able to raise events to the virtual experiment work bench and
accept calls after initialisation.
The virtual apparatus will be implemented
as a "class", in the Java programming language, in that
it describes the visual interface and behaviour of a type of apparatus.
The local machine should be able to instantiate working copies
of the apparatus from the same file. This is again advantageous
to the network model we are referring to. When the same class
of apparatus is used more than once in an experiment, the client
machine needs only to download one copy of the apparatus and the
virtual experiment work bench will create various copies of the
apparatus locally without incurring further network traffic.
The virtual experiment work bench is
a container for the virtual apparatus and should be able to communicate
with the virtual apparatus at two levels: receiving events generated
by the virtual apparatus and sending commands (or altering the
parameters of the virtual apparatus) after initialisation. Currently
ActiveX of Internet Explorer 3.0 supports this requirement.
The observable experiment parameters
are not set by the virtual apparatus, but by controlling how the
virtual apparatus behaves. This is done by scripting. The scripting
language can set and/or alter the properties of the virtual apparatus,
respond to events initiated by some other virtual apparatus and
pass messages on to other virtual apparatus. By using simple scripting
language, such as VB script (which is a subset of the Visual Basic
Language), teachers can assemble a virtual experiment more easily
than creating one ab initio.
For the "virtual apparatus"
to go from concept to becoming a viable solution, it must undergo
detailed design and development and become widely accepted. The
creation of an automatic central registry would ease the distribution.
The central registry would provide the following services:
ï categorise the virtual apparatus to facilitate searching
ï provide developer information
ï provide version control
ï digitally shrink-wrap the virtual apparatus. By shrink-wrapping the apparatus, the user is guaranteed that the file(s) which are downloaded have not been modified or virus affected subsequent to submission by the original developer.
ï provide license control so that
the developer can control the distribution of the virtual apparatus
and may be rewarded for thiseffort.
At the time of writing this paper,
Microsoft announced the general availability of J++, its version
of Java programming which also supports the ActiveX specification.
We envisage that by the time this paper is presented, we will
have a working demonstration of the ideas presented in this paper.
It is clear that there will be a continuing
demand for authoring virtual experiments for delivery via the
world wide web and that methodologies for lowering the complexity
of doing this are required. In the paper, we put forth a concept
which is made feasible by recent technology but requires further
development and collaboration to be fully implemented.
The virtual apparatus model allows
teachers to take ownership of the virtual experiments they create
without requiring them to invest heavily in understanding a fast
changing technology. Similarly, the computer professionals can
take ownership of creation of the virtual apparatus. This aspect
of the model addresses the "not-invented-here" syndrome
by acknowledging the professional value and expertise of both
The success of such a model depends
on whether the model can give rise to practical solution that
is acceptable to the teaching professionals. It is our intention
to start building a repository of virtual apparatus and make them
available to anybody interested.
Bothun G (1996) Virtual Laboratory. [http://jersey.uoregon.edu/vlab/]
Eriksson H (1996) Control The Nuclear Power Plant (Demonstration). [http://www.ida.liu.se/~her/npp/demo.html]
Johnston W (1994) Virtual Frog Dissection Kit. [http://www-itg.lbl.gov/vfrog/]
Kinzie M (1994) The interactive frog dissection.
US National Library of Medicine (1995) The visible human project. [http://www.nlm.nih.gov/research/visible/visible_human.html]
Kaufman A (1995) 3D Virtual Colonoscopy. [http://www.cs.sunysb.edu/~vislab/start_colonoscopy.html]