The package is in no way perfect. Due to the vague specifications we had at the beginning we have many times found ourselves in situations were we  more or less had to improvised. Our limited knowledge of the technologies used, and maybe more important the technologies available, also put limits to what and how we did what we did. Below will follow a short discussion on the improvements that might be taken under consideration.

Data storage and communication

The current way the storage and communication in the system are performed in a somewhat cumbersome way. Even if the storage of QuestionPages and students answers are simple it is hard and time consuming to write and modify the cgi scripts that works with the data. A much better approach would probably be to use a real database program as the Java.sql package also provides classes that could connect to a sql database. The use of a database abstraction layer would make the package a lot more flexible and easier to overview. Unfortunately we have very little experience working with databases so it is hard for us to tell if it would be difficult to implement. On the other hand, as the applets are well designed and all server communication is performed in only one class, the class DataLoader, it should not be to hard.

Another interesting alternative would be to use RMI (Remote Method Invocation) for the communication. The applets can then work directly on objects residing on the server to create QuestionPages, edit students, etc. When a teacher performs a saving on the server, whole objects could be saved on disk utilizing Java serialization.

QuestionPages

• Implementation of auto correction for the written type of QuestionPages by using for example keywords.
• Adding of more QuestionPage types to the system

MakePageApplet

• Using the space now occupied by the student answer text area, to display more question text areas.
• Use of menus and/or image buttons with pop-up help text, instead of the simple text buttons currently in use. This will save valuable screen space and give the applet a more professional look.

ReadAnswerApplet

• Ability to save the grade given by the teacher.
• Adding of more statistics, for example average number of correct student answers for each QuestionPage. This would be easy to implement.
• Use of menus and/or image buttons with pop-up help text, instead of the simple text buttons currently in use. This will save valuable screen space and give the applet a more professional look.
• Ability to save the students answers on the clients hard disk, to do this one have to get an applet certification number form an authorized institution/company. Otherwise the browser will not allow the applet file access.
• Ability give the student personal response to his answers, for example by email.
• Automatic sending of e-mails to all students telling them how they did on their web exam, the student average, etc.

CreateCourseApplet
 
Suggestions for further possible implementations:

• The showing of a "number of students" value.
• The possibility for a teacher to view the students sorted by their cedula number, first name and last name.
• The possibility to change the name of a course after it has been created.

There are many improvements that can be made to the scripts. They are really not optimized, as we have had problems with finding useful information about the Perl language. Due to that, the implementations of the scripts are more or less written using a C syntax (which can be done in Perl, but then all the in Perl nice built-in functions are not utilized). Many quite bad solutions can therefore be found in the scripts.

There should be a very important improvement made to the rmCourse script. The script should check some kind of user name and password if a course is to be removed. If not (as it is today) it is possible for a person with bad intentions to remove whole courses,  if he/she only knows about the scripts and the invariables to be used. This can easily be done by taking a user name and password for arguments and perform a check on them similar to the check in the checkPassword script.

In the distans.perl script it could be implemented that if a student/person that is not registered to a course and still gives answers to a QuestionPage, then the e-mail address of the teacher(s) responsible for the course could be displayed. The student/person can then easily contact the teacher. This could be a nice feature for students that have not been registered correctly to a course or that have been deleted from a course by mistake by a teacher.