One of these programs is used by applicants to apply for our degrees. A second program is a password-protected administrative system, used by secretaries and course coordinators, to evaluate applications and generate reminder letters. A third program is used by visitors to our web site who have specific questions and or who wish to request us to send them materials such as a prospectus; these requests are logged in our database and are then processed by administators using the administative program. We first describe how the system works from the viewpoint of the applicant and the admissions administrator and then describe how it was programmed.
The end user connecting to our admissions web site http://www.econ.bbk.ac.uk/admissions [This page has since been removed- Web Editor] will see a display as in the browser in Fig. (1) below. This is just a standard web page. New users will click on the ``Register'' button and will receive a userid and password. The new users are then prompted for address and contact information. Applicants can then proceed to fill out applications. Applicants are able to edit incomplete or unfiled applications, check the status of their filed application or update their information (e.g. phone numbers, etc.) by returning on subsequent visits and entering via the ``Login'' button.
Figure 1 The login screen for applicants on Admissions On Line
For instance, when the applicant selects the degree programmes to apply for, a full-time applicant for our postgraduate certificate in economics (PCE) is warned that most classes are in the evenings and a part-time student for the MSc. in Economics from o utside EU countries is warned about work permit requirements before the application process even begins. Forms are validated as they are processed to make sure answers are correct and the applications are complete before submission. This is particularly i mportant in the case of Birkbeck where we have a complex mix of students and degrees. Online admissions enables us to ask degree-specific questions of applicants.
Figure 2 Some specialized questions for Ph.D. students
Click to see the full size graphic
One set of questions applicants must answer is a set of confidential statistical questions mandated by the Higher Education Statistical Agency (HESA). This information is stored in our database but is only accessible to the College Registry and not to tho se evaluating the applications.
Typically, applicants do not finish the application procedure on their first visit and must return to edit their application. Since all information entered is immediately stored in the admissions database, interrupted sessions are not a problem. When the applicant is pleased with the application, s/he submits it electronically and, after this point, cannot edit the application any more. However, the applicant can return to the admissions web site to check on application status and to update contact information and provide new information through admissions queries.
When an application is filed, two things happen. First, a copy with confidential statistical information is sent to the Registry; eventually, the Birkbeck Registry will also evaluate applications online but at present they prefer to receive hard copies. This copy is sent with a cover sheet which is then returned with the Registry evaluation; the Registry evaluation is entered into the database by an admissions secretary. Second, the application is reviewed by a faculty member and references, transcripts, additional questions are requested as necessary; an automatic electronic mail message is generated with instructions on how to address (with the application ID number) and send the material to us. When the mate rial arrives, an admissions secretary clicks on the appropriate button and the online database is updated. If the material does not arrive, automatic reminders can be sent to applicants and referees. When the file is complete, a judgment is made. Formal a cceptance letters are sent by post while rejections are handled electronically.
Figure 3. An admissions query (this is fictitious but representative).
Click to see the full size graphic
Users of the administrative program also process input from a third program, an admissions request system: http://www.econ.bbk.ac.uk/aolrequest. This program puts user requests for prospectuses and application forms directly into a database. Before we implemented this system in November, 1996, these requests were a major problem because there were so many of them; in fact, we had more than one hundred unanswered requests at the time of setting the new system up. We provide a list of frequently asked questions, downloadable application forms and remind people that everything in our prospectuses is available online. This helps reduce traffic to those only with very specific questions or with very slow network connections.
The admissions program was written in server-side JavaScript in the Netscape LiveWire environment (both Java, an object oriented language which is compiled into byte code, and JavaScript, an interpreted language, are normally used as client side programs; the Netscape second generation server technology which includes LiveWire allows for server side Java and JavaScript). Although the system we have implemented was designed with the needs of economics in mind, it should be more generally applicable.
The Netscape LiveWire environment in which it is developed is available on a wide variety of hardware platforms, including Windows NT on Intel and Digital Alpha machines, SGI Irix, HP-UX, IBM AIX and Sun Solaris. The Netscape server and LiveWire software is available at low cost for academic use; depending on the platform, LiveWire will work with ODBC, Informix, Sybase and Oracle database servers. Netscape markets a product, LiveWirePro, which bundles an Informix On-Line server. While client-side JavaScri pt requires Netscape 2.x and above, the admissions system we developed works with as little as Netscape 1.x and even the text browser Lynx.
For an example of how this works, this is a snippet of code to make sure that part-time applicants specify their employer and occupation:
if (client.coursetime != ''ft'') if (request.occupation.length < 2) str = str + "<BR><BR> You have indicated a potential preference for part-time study but have not indicated your <I>occupation</I>. Your application will not be accepted without this information."; if (request.employer.length <2) str = str + "<BR><BR> You have indicated a potential preference for part-time study but have not indicated your <I>employer</I>. Your application will not be accepted without this information."; ...The str string above is being used as a temporary variable to accumulate error messages; if no error messages are reported, the data is entered into the database. The client object (client.coursetime) in the above code snippet can be configured a s a client-side cookie item or stored directly on the server by IP address; the request object comes from the previous form.
Server-side Javascript is particularly useful for database access. For example, this is part of the code which stores information on one of the universities attended by the applicant:
database.beginTransaction(); cursor = database.cursor(''select * from universityatt'', update); cursor.univattID = univattID; cursor.univuserID = client.ID; cursor.univname = request.u1name; cursor.studystarted = parseInt(request.u1s1year,10); ..... Returnerror = cursor.insertRow(''universityatt''); if (Returnerror) database.rollbackTransaction(); cursor.close(); redirect(''dataerror.html''); else database.commitTransaction(); cursor.close();The above code snippet uses On Line Transaction Processing so that if an error occurs, the transaction is rolled back and an error message is printed. In additition to commands which manipulate database cursors, there are also commands in the the LiveWire environment to execute specific SQL statements. None of the code is visible to the end-user because the sources are compiled by the LiveWire compiler; only the actual dynamic HTML output of the program is visible to the user. The same is not the case fo r client-side Javascript which may be used for preprocessing of forms. Our system differs from the standard Perl-based CGI scripts (CGI stands for a Common Gateway Interface and involves a program executing in C or Perl on a web server) which are used in most Internet programming applications; in fact, we have replaced most of our current Perl CGI scripts on our website with server-side JavaScript.
We were not quite able to implement the whole admissions system in server-side JavaScript. Some functionality was simply not possible in JavaScript; this included sending automatic email messages to applicants and retrieving the user names of those who ha d logged into the administrative system using Netscape's user authentication. We wrote specialized C code in the Netscape Application Programming Interface (NSAPI) as server plug-ins for these tasks.
The discussion above ignores many of the issues which had to be resolved with the College in setting up the admissions system. For instance, a major issue was signatures. The idea we have worked with is to include the standard warnings and inform applican ts they will have to sign a printed undertaking and provide formal documentation at the time of registration. There are various security measures built into the program and we are recording client IP addresses when users register and when they formally file applications. However, we have not used tools such as digital signatures for authentication because they are not widely enough used yet.
However, we intend to expand the scope of the online admissions system to include students who want to take individual or short courses and we hope to begin accepting credit card payments for some of these courses. In addition, in the future, we will probably allow students to upload BLOB items such as word-processed documents (up to a size constraint) to the database such as sample essays, Ph.D. proposals and pictures in image format. We also are likely to expand the system to include more contact with students once they are admitted and to provide tools/facilities for mathematics and statistics preparation before courses begin.
The author may be contacted at :
E-mail: jmo@ricardo.econ.bbk.ac.uk