Abstract: The world-wide-web should be viewed as just another interface technology that inherently supports distance learning, cross-platform delivery and centralized maintenance. Unfortunately, it is easy to view the web as a hypertext technology which leads developers to implement flashy but static systems that are poorly suited for supporting high quality learning which requires systems with interactivity and opportunities for creativity. We argue that the traditional metaphor of a program with an interface is superior, from an educational standpoint, to the hypertext metaphor and we describe technical options for implementing systems based upon the metaphor of a program with a web-based interface.As with any new technology, a different mixture of problems face developers. In particular developers require appropriate ways to modularize software, support multiple students, face problems with concurrency and build highly reliable servers. Our solutions to all of these problems are described.
keywords: user-adaptivity, dynamic content presentation, intelligent tutoring.
We argue that the traditional metaphor of a program with a graphic interface is superior, from an educational standpoint, to the hypertext metaphor and we describe technical options for implementing systems based upon the metaphor of a program with a web-based interface. As with any new technology, a different mixture of problems face developers. In particular developers require appropriate ways to modularize software, support multiple students, face problems with concurrency and build highly reliable servers. Solutions to all of these problems are described. These suggestions are based upon our experience building a web-based Medical Technician tutor intended for training U.S. Air Force Reservists [Eliot et al., 1997]
Each stage of development has moved computer interface design further from arcane mathematical formalism into widely accessible interactive graphic metaphors. However, while the web represents a significant step forward in terms of giving computers simple visually based interfaces, it is a giant step backward in terms of interactivity between the user and the computer. The world-wide-web supports a hypertext metaphor that more closely resembles television, with all of its mind-numbing qualities, rather than easily supporting exciting metaphors that promote student's thinking, creating and exploring. Admittedly, the web does support a form of exploration, but a mindless wandering form of exploration is reinforced rather than the kind of creative discovery that will reinforce thoughtful, reflective thinking.
We believe that the world-wide-web could support one of the greatest advances in education if we can build sites that encourage students to delve deeply into a subject rather than glancing over a vast range of topics. We experimented with the technologies required to support this concept while implementing a web-based anatomy tutor.
Once we selected CL-HTTP as our basic implementation technology, two substantial problems remained: handling multiple students simultaneously and implementing highly interactive software.
In concrete terms, there are two problems that must be solved to support multiple students within a single address space: how to associate a client request with a particular student and how to store student specific data apart from data pertaining to other students. More abstractly, the fact that a single server supports multiple students simultaneously increases the importance of building reliable software because a serious program error that halts the server will affect many people.
Keeping individual student records requires indexing every data structure based upon the student. Many traditional programming techniques can be used to accomplish this, including hash-tables, association lists or databases. This is not particularly difficult, but adds some level of complexity to every representational problem faced by developers. The problem is pervasive, making almost every representational problem slightly more complex. Developers are advised to consider this early in the design of a web-based tutoring system and to create uniform procedures for identifying students and associating records correctly with individual students.
Regardless of the data structure techniques used to keep individual student records separate, there must be a basic mechanism capable of identifying which student corresponds to each client request. There are actually two aspects of this, identifying when students first access the system and continuing to associate requests with the same student.
We implemented a login screen to enable the system to identify when a student first enters the system. A password mechanism can be built into the login screen and individual student records loaded from long term storage only when a student becomes active, as indicated by logging on. Students who remain inactive for long periods can be automatically logged off and their records moved back out to long term storage. Most tutoring systems require some similar mechanism.
A student who has logged into the tutor will begin to access various pages within the system. Two mechanisms enable the system to automatically determine which logged-in student those requests belong to. One mechanism is to issue a "cookie" to the student as part of the login procedure. Some web browsers include a mechanism to store such cookies and will return the identification data within the cookie with each request to the same server. The cookie sent by the server effectively encodes an ID number for the each student which can be used as a key to retrieve his particular student records. This mechanism is sufficient, provided that the web-browsers used by the targeted student population supports the cookie mechanism. However, at the time we began implementing web-based tutors this mechanism was vender-specific and some users disable cookies on the grounds that individual privacy can be compromised. Consequently we did not use cookies.
Instead, we retrieved the IP address of the machine from which a request originated, and used that as a key to identify the student. This avoids the objection that our system is storing something on the students machine and works well as long as students gain access to our tutor from a personal computer or workstation. For research purposes this mechanism is adequate but students who use a client on a shared mainframe also share a single IP address.
Our tutoring system does not presenting include collaborative features, but the technological foundation could easily support collaboration. Global objects, not attached to any particular student, can be manipulated by any student. For example, these global objects could represent a shared simulated world. The server can export a dynamic web object which generates a current view of this world. A straightforward implementation requires nothing more than generating HTML representing the current state of the world. However, the resulting web page will not be updated if the simulate world changes while being viewed. A more satisfying result could be obtained by implementing a JAVA applet which is capable of receiving messages and updating the display whenever the simulated world state changes. We are currently implementing a simulation based upon this concept.
The basic pattern of web-accesses provides some coarse-grained information about the student's behavior. Links among pages can be given semantically significant labels so that the student's choices while browsing can be interpreted usefully.
"Forms" provide another simple mechanism for obtaining information about a student's knowledge level. Multiple-choice or short-answer questions can be easily implemented using forms. Because many questions can be encoded in a single form it is possible to obtain fine-grained information about a student's knowledge more efficiently than is possible using link information alone.
Macromedia implemented a version of Director(tm) called Shockwave(tm) to support interactive web page development. One advantage of this technology is that graphic artists can create interactive screens without programming support. However, the use of plug-ins makes Shockwave very slow and we were unable to dynamically exchange information between the client and the server using this technology.
The Java programming language for creating applets has proven to be our solution of choice. While Java applets must be created by programmers with more sophistication than most graphic artists, it does provide higher quality results and is the only technology enabling us to combine student modeling with dynamic graphic displays.
Constructing Java applets will not be discussed at length here. Student modeling requires dynamic interaction between the server and the client. We considered three mechanism for implementing this within our system. Java security features impose some limitations on what can be done. A Java applet is capable of manipulating files located on the server machine from which the applet originates. We could have designed our applet to read and write message files for exchanging information. However, we found that direct program-to-program communication could be implemented by opening a TCP connection directly from the applet to the Lisp-based server was also possible. We decided this was the optimal mechanism for our system. However, there are remaining problems because some client implementations handle TCP poorly. For reasons that we do not understand, messages from the server to the client may be delayed up to several minutes. These delays are unacceptable and appear to be caused by the client machines operating system implementation of TCP, which is beyond our control. We have found, empirically, that client machines of one type receive messages within a small number of seconds, while different machines connected to the same network in the same place experience delays up to several minutes.
Another technique for exchanging information that we have not explored is based upon the URL mechanism itself. A Java applet can (check this?) open a computed URL and read (or write?) data.
Regardless of the low level mechanism used to exchange information between the client and the server, we have found that a semantics of explicit message passing provides a comprehensible and implementable structure. Because of the potential for transmission delays we carefully designed our message semantics so that neither the client nor the server was required to wait for a response to any message. Instead, all messages were designed so that the sender could continue processing without a response. Any response that the receiver does make was required to contain sufficient information so that it could be converted into an independent message.