This section describes the development including the approaches and the methods we used and the thoughts we had during our work with the "Distance Education over Internet" project.
It is divided into these parts:
With the somewhat vague descriptions we had to follow for the line up of the project we had to find a way to find answers to the questions we had for the moment. The primary questions were:
To get to the answer of the questions addressed above, we had to learn JavaScript ourselves (as we did not have any former knowledge of JavaScript programming), to get an idea of the programming skill that was required to make HTML/JavaScript pages with questions. [JavaScript Essentials, Jason J. Manger, 1996 and JavaScript for the World Wide Web, Ted Gesing and Jeremy Schneider, 1997].
We started off with implementing a page with questions that gave the result of the answers of the questions directly to the user. We soon came to the conclusion that it would not be a good solution to let the teachers write their own question pages. The reason for that was that even if we developed question page prototypes, that the teachers afterwards could use to understand how to implement their own questions it seemed to be very difficult for a teacher without any programing background to get it correct. To implement it correct it would demand a knowledge of JavaScript at a level similar to that of writing the whole question pages their self.
Having this in mind we decided to go on with learning Perl, as it would be needed some kind of scripts residing at the server as an interface between the question pages and the savings on the server. The choice of Perl was taken due to that we didn't have any idea of how to implement the interface between a question page and a server, except for that we had heard that things like this could be done using Perl and that a book about Perl was available for our use at the university. [Programming Perl, Larry Wall and Randall Schwartz, 1991].
We read parts of the book, but as the purpose of the book was to serve more as a reference for Perl programmers then a novice "learn Perl from scratch"-book we surfed the Internet to find more information about the Perl language. [http://www.nsca.edu].
An cgi directory was created for us by the system administrator at the university and we learned Perl and implemented some test programs consisting of HTML/JavaScript pages calling PerlScripts. The next step was to implement a way for the question page to call a PerlScript which should take care of the saving of a students answers. At the same time as we were developing the PerlScript that was to handle the saving of answers we decided to use the social security numbers of students to identify them. This led us to begin thinking about how to make sure that a student only answered a certain question page once. (There would surely not be appreciated by the teachers if the students could answer a question page more than once and it would be more complicated to implement multiple answering possibility without inconsistency of the student answers too). We came to the conclusion that each course to be given should have a list of the students attending the course. We had had thoughts about how the file structure on the server should look before too, but this made it certain that we would use a structure using (at least) one directory for each course, with the information regarding the course in that directory.
The general file structure at the server was now developed. The question pages had to be placed under a directory with public permissions for the possibility for students to take part of them. On the other hand the information of the course, such as: students registered and the answers of the students should not be available for public access. So we had to divide a course into two directories, one containing the question pages for public access and one containing the secured information that only teachers would have the possibility to access. (Most preferable would be to have access restrictions for the secured information so that only the specific teacher(s) "having" a course could access this information, but this was taken under question later).
After having implemented the question page and the PerlScript for the saving of student answers, it got even more certain that it would not be a good idea to let the teachers implement their question pages themselves. The extra difficulty that the server saving question page brought with itself was, as we believed, that the teacher would have to understand even more of JavaScript programming than what was necessary for a question page without the server saving method.
4. The idea of making a Distance Education over Internet package
At this stage we decided to try to make some kind of application package that the teachers could use to create their whole question pages. This introduced some limits to a question pages layout/design, but we considered it more valuable to have the question pages correctly written than to have the possibility for a teacher to design its own question page. Certainly, the most important thing with an exam given through the Internet is not the layout of the questions, but that the questions are correctly written and that the answers are correctly handled for each student.
Now we had a new question:
Design and development of the packet
We decided to make applications that the teachers would use to:
We had two different approaches in mind, to program everything in HTML/JavaScript or to do it in Java (as Java applets). If it would be possible to write everything in HTML/JavaScript it would probably be the best solution, because:
Thus we started off with trying to write the package HTML/JavaScript code at the same time as we began developing a new kind of question page, which was to take a written answer and send it to the corresponding teacher through e-mail.
The first two things that had to be done, were to create a PerlScript that could generate question pages taking questions and answers to the questions as in arguments from a HTML/JavaScript page and a PerlScript that would generate a temporary HTML page with the results of the students displayed in different formats. The format etc. etc. should be user interactive
After completing the PerlScripts and their corresponding HTML/JavaScript
pages we examined the result. We found the HTML/JavaScript page for creating
question pages very inflexible, mainly for the reason that the number of
questions (Cross and Alternative) and the number of possible answers (Alternative)
could not be dynamically changed on interaction with the page. It could
have been done using a first page were a teacher wrote the number of questions
and answers in a form that would then be used to create the page were the
teacher wrote down the questions and answers. But on the other hand, if
more interaction possibilities were desired (which we supposed) then it
would not be flexible enough and very cumbersome to implement only using
HTML/JavaScript pages. Besides this, the programs to generate results of
students was inflexible too.
The main reason for this is that JavaScript really is not designed
to dynamically change the content of a page e.g. add and remove text fields,
instead it is better used to manipulate the contents e.g. changing the
text of a texfield. The loose typing also makes it very hard to program
and debug bigger applications
6. The second approach to the "package" - the Java approach
Facing the problems with implementing everything in HTML/JavaScript we decided to use Java applets for the teacher interaction instead. As Java applets can use PerlScripts in a similar way as does programs written in HTML/JavaScript there would not be a need for any big changes in the PerlScripts already in use. Besides we had previously programed in Java, and we therefore knew that we now could implement a lot more methods/functions than we could have done only using HTML/JavaScript.
At this stage John went on vacations and David began writing the two different applets used to create question pages and provide results of students. These two applets were called MakePage and ReadAnswer. The development of them and the PerlScripts that they work with continued the rest of the development of the project.
David then went on vacations he too. When we came back from the vacations David continued writing on his two applets and John began implementing a Java applet to administrate courses, which was called CreateCourse, that work continued for the rest of the project too.
The development of the applets were done concurrently with the implementation of the Perl scripts that were to be used for the applets..The old scripts were updated and then there were a whole lot of new scripts that had to written from scratch. The CreateCourse applet was something totally new, so all the PerlScripts to be used for it had to be written from scratch.
Even if we knew programming in Java, we (David) had only written a few simple applets, so there was something new to learn here too. The graphical components and the methods for user interaction was new, but the "normal" methods implementation is the same as for a normal Java program.
We had some problems finding ways to contact the server in a similar way as do programs written in HTML/JavaScript (which contact a server with either the GET or POST method). There are no easy functions built into Java to handle these kind of contacts, but with the WWW as a big help we found our way out of it. It was also at this stage of the development that we found out that Netscape Navigator/Communicator, in it's original version, did not fully support the latest version of Java (jdk1.1).
It had been made quite clear that Netscape Communicator was the browser that most of the teachers would use (the reasons for that are discussed in the Problems document), so we had to find a solution for this problem; we also wanted the package we were developing to work with both Microsoft Internet Explorer and Netscape Navigator/Communicator.
On Netscape's home site [http://home.netscape.com], we found a batch file that could be put into Navigator/Communicator that would eliminate the problem of jdk1.1.. We downloaded it and started testing it, and found that it worked satisfactory with the applets. A problem though was that the batch file was big, about 6 MB, and the data connections between Uruguay and the U.S.A. (the main resource for this files) were really bad during day-time, so in most cases it was not even possible to download it during the normal office hours. As we were mainly working at our apartment and during night-time, we could download the file without any greater problem, but we left the problem that would arise for teachers wanting to get hold of the batch file for this moment.
7. An account dedicated on the server ceibo.fing.edu.uy, with the purpose to be used for the project
At this time we got an account at a server and a domain to use for the "Distance Education over Internet" package. We named the domain distancia, so the URL for the domain look like this: http://www.distancia.edu.uy. Now we had a way to get around the problem with downloading the batch file. We could just put it on the new server and let the teachers download it from there. The connection line from the server dedicated to us was not very fast as it during day time is used by a lot of people, the connection to the server is only 56 Kbps. But anyway, it was faster than downloading it from the U.S.A. (which hardly was possible).
The server we now had offered a new feature. The directories and files created using the applets/PerlScripts got the user set to "web" on the server. That meant that the files/directories we create through the interface of PerlScripts belongs to the user "web" and not to the user of the account (us) so we could no longer remove files or directories without going through PerlScripts that calling them from a browser. So, we then designed some PerlScripts to use for this purpose. The idea we had had about letting teachers use ftp to download results of the students was now not possible anymore, as those files were not accessible.
8. Facing problems with a connection from a LAN
Now some of the applets were working sufficiently well during the tests
from our apartment. To demonstrate what we had done for our project manager,
we accessed the applets from a computer at the university and tested them.
We found that we had a quite big problem, the POST method from the applets
did not work from inside the LAN at the university. We spent an incredible
amount of hours trying to solve this problem, but all we found were other
persons having experienced the same. (For a more technical description
of the problem, see the document Problems).
We found a plug-in for Netscape Navigator/Communicator that could be used instead of the batch file. As this plug-in was big too, about 8 MB, we had the same problem with it as we had with the batch file, but the plug-in was better in that it was more stable than the Netscape Navigator/Communicator with the batch file installed. It was also better in the way that if the person accessing a Java applet did not have it installed then the applet automatically demonstrates a link from where the plug-in can be downloaded. As Netscape in the future probably only will use Plug ins for Java applets, we found the solution to use the Plug-in instead of the batch file more appropriate and therefore decided to go on with the Plug-in. We put the Plug-in on the server too, available for the teachers to make it possible to download it faster.
We continued working on our applications package correcting bugs and finally came to a satisfactory result. The end result is a package that can be used by teachers to generate pages with questions that the students of the teachers are to respond. The answers the students give to the questions can either be evaluated by the QuestionPage or sent to the server for storing. In the first case the answers to the questions are given to the students directly. In the latter case the answers are evaluated and shown to the teacher through an applet which connects to the server to retrieve the results.
The teachers uses applets to administrate their courses that are given over the Internet. The students uses the QuestionPages created by the teachers to give answers to questions. In the teacher's and student's point of view, everything that has to do with QuestionPages and students answers to them is performed over Internet using common browsers as Netscape Communicator and Microsoft Internet Explorer.
There are three applets developed to be used by teachers:
The final file structure on the server looks like this
Regarding the directions for the project that we were given at the start,
we are quite satisfied with what we came up with and the result. We are
aware of that the package can, and should be further developed for future
success. We describe our thoughts about the future in the Improvements
chapter.