Villa Julie College Online Application

Applying to college in the early 2000s was still mostly a paper affair. You would get the application from the school itself, or your high school had application forms for the local colleges, or you’d mail away for one, or (maybe) be able to download a PDF or Word Doc of the application. You’d gather all of your info – school history, standardized test scores, work history, parentes info, income information – and fill in one or more applications with all the same info. For the most part, college applications were unique, though the Common Application was starting to become much more widespread between participating colleges.

But you couldn’t easily apply for college online, and we wanted to do that at Villa Julie. The existing application process wasn’t just slow for students, it was slow for Admissions staff. It would take one person about 10 minutes to key in all of the hand-written (typewriter if you’re lucky) information into the Datatel student information system software, and it was an error-prone process. Shaving even a few minutes off of this, or reducing the likelihood of errors, would allow the Admissions office to process many more applications correctly.

At the time, you had basically two browsers in use: Internet Explorer and Netscape Navigator, the latter which was slowly turning into the open source Mozilla suite and Firefox browser. Additionally, you weren’t constantlys updating your browser like what happens nowadays – browser updates were costly, long downloads unless you had DSL or Cable. Finally, JavaScript support across browsers was iffy at best. While XMLHttpRequest existed, partial updates to webpages were still tricky at best, especially for a young programmer like myself.

So when the admissions department came to us with the idea of moving college application online, we would have a good number of challenges to deal with, and not just technical ones. We would also have to build something that could beat what other colleges were doing at the time – a single long HTML form. Here’s what we did

• We implemented a Perl application, attached to a MySQL database, that would deliver HTML and accept form input from potential students. The system had an authentication system for persisting user data between sessions (if needed).
• The application would be accepting personally identifying information, so we went through the (at the time) expensive and challenging process of getting an SSL certificate. We didn’t accept payment, as things like Stripe were many years away from existing.
• We would email potential students upon receiving their application for admission, and would allow them to log in and return to look at what they submitted.
• Nightly, a cron job would take the list of all students that applied the day before and dump them into a text file that the Datatel system would later batch import.

The Perl webapp and batch file output were my part of the work. The web department – me and my boss – wanted to make sure that the application was as user friendly as possible, especially to users of older computers or for those still on modems, still commin in the early 2000s. We also wanted to be mindful of students needing to gather info. Finally, we had to beat the “one long form” approach other colleges were doing.

We chose to break the application into multiple pages – personal information, standardized test results, references, and so on. Each page would have a status: incomplete, partially complete, and ready for submission. We didn’t prevent data from being stored if it failed validation – we persisted it and showed the necessary error message, so that even if the user left and logged back in, they would be able to correct their error. Without Shadow DOMs, XMLHTTPRequests, and a lot of the modern browser conveniences, submitting individual subsections of the application was the best compromise we had.

This was the early days of XML, and there was no way I wanted to code and recode all of the necessary HTML to build these complex, repetive forms. So I ended up writing a form definition language using XML, not unlike how Mozilla used XUL to define interfaces, or as a very early precursor to how frontend frameworks like Vue handle custom components. This allowed me to easily shuffle around form elements on the page, or to different pages, based on user feedback.

And we ended up getting a lot of user feedback before launch. The idea of 5-users-at-a-time usability testing was gaining popularity, and so we ran multiple usability sessions on the online application using Library computers, focusing our testing on freshman who had just applied using paper a few months ago. We ran multiple sessions, at least three or four, and used their feedback to continue to refine the application.

Hooking up the application to the Datatel student information system was starightforward, but required a lot of testing, both before and after launch. We constructed a text file, with (I think) fixed width fields, with one line for each incoming student. The Datatel admin would download this file from our webserver and upload the file manually every morning, and then the admissions department could review the uploaded applications, and contact prospects about payment.

The application was a runaway success. I forget the rough numbers of applications that the college received on average, but the online application allowed an order of magnitude more applications to come in (for good or for bad). Additionally, the time to process a single application dropped from 10 minutes to 45 seconds, with an even higher rate of accuracy.

The application continued on until my boss and I left, when the school replaced most of the web presence with a turnkey admissions/marketing system. It was the first large scale application I’d ever built, created at a time when those new ways of interacting with computers and the Internet were still being worked out.