Figure 1 - Interface of WebSteer's Core Controller
Jorge H. C. Fernandes* (jhcf@di.ufpe.br)
Departmento de Informática, Universidade Federal de Pernambuco
Av. Prof. Luiz Freire, s/n, C.P. 7851, Cidade Universitária
50.732-970 Recife - PE, Brazil, Fax:+55-81-271-8438
* on leave from DIMAp/UFRN - Brazil
Silvio Lemos Meira(srlm@di.ufpe.br)
Departmento de Informática, Universidade Federal de Pernambuco
This paper presents WebSteer: a framework for construction and delivery of interactive documentation, training and education material over the Web. WebSteer extends the current technology of Java Applets and HTML browsing by creating a highly interactive instructional setting. WebSteer is based upon the laboratory metaphor, where learners follow instructional modules (courseware) by interacting with informative texts and reactive instruments in a scripted environment. WebSteer allows the user to select and follow any courseware made available by providers. Each courseware is composed by a (possibly open) set of HTML pages, a set of scripts, and a set of applets (instruments). The HTML pages are rendered by a special purpose HTML browser: the Slide Projector. The instruments (applets) are laid over the Workbench and cater for the multimedia user interface. They generally simulate the workings of laboratory instruments that are manipulated by the user. The scripts are hosted in the HTML pages and written in a purpose-designed language called JetScript. These scripts describe how to map events that are raised by the instruments and by the Slide Projector into messages that are sent to the other instruments and to the Slide Projector.The main differences between the WebSteer model and the Java Applet model created by Sun Microsystems and supported by popular HTML browsers like Netscape Navigator and Microsoft Internet Explorer are: the promotion of applets to the status of first class Web components, and the provision of a simple, detached and high-level event handling mechanism between applets and HTML pages
1 - Introduction
2 - The WebSteer Approach
3 - Architectural Elements of WebSteer
4 - Creating Courseware For WebSteer
5 - Conclusions and Future Work
Acknowledgements
References
While the conventional teacher-directed instruction mode relies basically on this figure as the didactic knowledge dispenser, the use of networking technologies for long distance instruction cannot rely on the teacher as sole controller of the subject matter ministering. Long distance instruction needs to use independent and highly interactive construction blocks that are directly manipulated by the learner while maintaining some level of control by teachers and course facilitators.
The recent introduction of the Java[4] programming language and of HTML browsers that support the execution of Java Applets, like Netscape Navigator, provided an innovative way to deliver dynamic information over the Web. Applets are programs written in Java, that can be downloaded automatically from Web servers and executed inside browsers, at the user's side. The applet code is highly portable among different computational platforms and present multimedia capability, being able to manipulate images, sound and text. An applet in execution is hosted inside a specific HTML page, and its graphical interface is presented in a predefined area within this HTML page's display space. The ubiquitous Applet technology has already produced a strong ground for the construction of interactive content, that is being used for education and training purposes. See for instance, the Gamelan directory of educational applets [5] that presented approximately five hundred entries in January, 1997.
Unfortunately, the standard applet technology does not provide a satisfactory level of integration with HTML, due to several limitations:
WebSteer solves these three problems by detaching the applet from HTML pages, and by allowing the interoperation between an arbitrary assembly of applets and HTML.
The WebSteer approach is based on the following points:
Although there are some successful examples of its use in educational contexts[6], sophisticated component software models like OpenDoc and CORBA[7] are not well suited for the construction of education and training software by teachers and learners. They are aimed at the construction of high-performance packed software, but lack simplicity and lightness. The most successful approach to the delivery of software over the Web is the applet technology, the ubiquitous mobile code approach developed by Sun Microsystems (JavaSoft[8]).
We must make extensive reuse of preexisting resources in the construction of courseware, mainly HTML and applets. When reusing or adapting these resources we should keep them compatible with the original model.
Navigation with conventional HTML browsers is ever more "flexible", and thus is not suited to controlled educational contexts. Furthermore it is not easy to guide the interaction of learners with conventional applets. WebSteer creates a loosely controlled environment for HTML browsing and applet execution that watches the interaction of the user with these elements. By using a detached script (see JetScript below) , it produces a guided control over the browser and the applets.
As pointed out in[3], the next generation of educational tools should ease the monitoring and reconfiguring of the learner's activity environment. We believe that the collection of usage profiles generated by WebSteer at run-time can be a valuable source for monitoring learners activity. Reconfiguration of the courseware may be easily made by altering the script (see JetScript below).
Powerful scripting languages like JavaScript and VBScript pose one more threat to the builder of educational software, provided that they are overly complex and aimed at a more sophisticated software developer population. Minimalist, but not simplist, scripting languages like JetScript, which we developed especifically for use in WebSteer, provide enough power to be used as a glue in the construction of courseware.
<jetscript> ::= <jetscript <preamble><mappings> jetscript> <preamble> ::= name= <script-name>; instruments= <instrument-list>; <mappings> ::= <mapping>;<mappings> <mapping> ::= <event> =) <message> <event> ::= onSlideEvent(<event-name>) | onInstrumentEvent(<instrument-name>#<event-name>) <message> ::= <slide-message> | <instrument-message> <slide-message> ::= <url> <instrument-message> ::= <instrument-name>#<message-name>(<args>))The syntax above is meant only to give a general idea of JetScript. For the sake of clarity we allow a more relaxed syntax for scripts, as the example below:
<JETSCRIPT
name = WebSteerInWebSteer;
instruments = WebSteerInWebSteer, SlideSelector;
onSlideEvent(#showWorkbench) =)
WebSteerInWebSteer#showWorkbench();
onInstrumentEvent(WebSteerInWebSteer#Back) =)
scripts/webSteerInWebSteer/BackButton.html;
Forward =)
scripts/webSteerInWebSteer/ForwardButton.html;
#showComponents =)
showSlideProj(), showWorkbench(), showCoreControl();
JETSCRIPT>
When the script above is inside an HTML page loaded by the
Slide Projector, the instruments WebSteerInWebSteer and SlideSelector are
loaded and laid out on the Workbench. The Controller them watches
the occurrence of
any of the four events defined in the script and sents to the instruments
the message corresponding. The first two mappings
use an explicit and longer format, while the last two are
abbreviations meant to simplify the writting of scripts. The semantic of each
definition is as follows:
onSlideEvent(#showWorkbench) =)
WebSteerInWebSteer#showWorkbench();
When the internal HTML reference #showWorkbench is raised by the slide projector, the message showWorkbench() is sent to the instrument WebSteerInWebSteer
onInstrumentEvent(WebSteerInWebSteer#Back) =)
scripts/webSteerInWebSteer/BackButton.html;
When the event Back is raised by the instrument WebSteerInWebSteer, the HTML page whose (relative) URL is scripts/webSteerInWebSteer/BackButton.html should be rendered by the Slide Projector;
Forward =)
scripts/webSteerInWebSteer/ForwardButton.html;
When an event Forward is raised by any instrument or by the Slide Projector, the page whose URL is scripts/webSteerInWebSteer/ForwardButton.html should be rendered by the Slide Projector;
#showComponents =)
showSlideProj(), showWorkbench(), showCoreControl();
When any event whose name is #showComponents is raised by any instrument or by the Slide Projector the messages showSlideProj(), showWorkbench() and showCoreControl() should be sent to all the instruments loaded on the Workbench: WebSteerInWebSteer and SlideSelector.
public class ClockInstrument
extends Clock2
implements websteer.InstrumentInterface {
public void raise(String s) {
java.awt.Container parent = getParent();
if (parent instanceof websteer.Workbench) {
((websteer.Workbench)parent)
.raise((this.getClass()).getName(), s);
}
}
public boolean action(java.awt.Event awtEvent, Object arg) {
raise(arg.toString());
return super.action(awtEvent, arg);
}
public boolean handleMessage(websteer.Message message) {
if (message.kind().equals("show")) {
show();
return true;
} else if (message.kind().equals("hide")) {
hide();
return true;
} else if (message.kind().equals("stop")) {
stop();
return true;
} else if (message.kind().equals("start")) {
start();
return true;
}
return false;
}
public java.awt.Dimension preferredSize() {
return new java.awt.Dimension(200, 150);
}
}
The adaptation of any preexisting applet of any size consists basically in the
creation of a Java class that inherits
from the original applet,
implements the InstrumentInterface from WebSteer, and declares
at least these four methods: raise(), action(),
handleMessage() and preferredSize().
raise() and action() are standard and should not be
modified.
raise() allows
events to be signaled by the instrument.
action() relies on
raise() to signal that some user interface action was done
by the user.
The name of the target in the GUI action
(arg.toString()) is sent as an event.
handleMessage()
defines how the instrument
copes with the messages it receives.
In this case, any ClockInstrument
handles only the
messages start(), stop(), hide() and show(). The method preferredSize() just returns
the expected size that the instrument's GUI occupies over the workbench.
To allow more interactivity to the courseware, we will insert extra
code that allows the instrument raise an event named "newMinute",
each time the minute of the clock changes.
This method relies on the updating of the GUI
of Java, that automatically calls the method paint(Graphics).
The code as below
should be inserted in the ClockInstrument definition above in order to raise
this event.
int oldMinute = new java.util.Date().getMinutes();
public void paint(java.awt.Graphics g) {
int newMinute = new java.util.Date().getMinutes();
if (newMinute != oldMinute) {
raise("newMinute");
oldMinute = newMinute;
}
super.paint(g);
}
<HTML>
<HEAD>
<TITLE>Controlling a Clock Using WebSteer>
</HEAD>
<BODY>
If you <A HREF="#stop">click here<A> the Clock stops.
To get it going again, you <A HREF="#start">click here<A>.
If you don't want to see it anymore,
just <A HREF="#hide">hide it<A>.
To see it again, all you gotta do is to
<A HREF="#show">click here<A>.
</BODY>
<JETSCRIPT
name = ClockLecture;
instruments = ClockInstrument;
#stop =) stop();
#start =) start();
#hide =) hide();
#show =) show();
newMinute =) scripts/ClockLecture/NewMinute.html;
JETSCRIPT>
</HTML>
Although the example provided may seem too complex to produce a small
result, we have learnt that the consistent application of these simple
techniques produces useful effects. For instance,
after the possible incremental definition of instruments' events
and messages, it becomes very easy to alter the general
behavior of the courseware.
Using WebSteer and applets we have developed courseware, interesting
experiments, and useful instruments that show strong possibilities for its
use in education and training settings.
As of February, 3, 1997, the current version of WebSteer is itself an
applet (and a WebSteer's Instrument!), and presents the following
courseware:
We are actively working in the enhancement of WebSteer, and are facing several issues to be tackled in the near future. They are:
Our findings about the WebSteer project are that: