Tag Education

The case of the not-so-electronic application

There was an article in the New York Times today about the vexation students experience in using the online version of the Common Application:

So it was frustrating for Max Ladow, 17, a senior at the Riverdale Country School in the Bronx, to discover this fall that he could not get his short essay answers to fit in the allotted 150 words on the electronic version of the application, even when he was certain he was under the limit.

When he would follow the program’s instructions to execute a “print preview” of his answers — which would show him the actual version that an admissions officer would see, as opposed to the raw work-in-progress on his screen — his responses were invariably cut off at the margin, in midsentence or even midword.

I remember encountering this problem when applying to undergraduate programs a number of years ago, and even then I recall being astounded by the approach taken by the Common Application—the online application is actually only a web front-end which takes the applicant’s data and stuffs it into a tagged PDF version of the paper application. It’s like using TurboTax or similar software to prepare your tax return, then printing the forms out and mailing them in; there’s nothing inherently electronic about the process. You could have filled the forms out by hand, or with a typewriter, and gotten nearly the same result. Because the web front-end knows nothing about the PDF-generation process, it only enforces the word-count limits which apply to the paper version of the application. But there’s another, more insidious limit—that of space on the page. As the article explains, it’s easy to be well within the word-count limit, yet have run out of space on the printed page. In a real word processor, you might play with the font, or the font size, or the margins. But the Common Application provides no such features.

What is both stunning and alarming, though, is the response that the New York Times received when they asked the Common Application about the problem:

Asked why the problem had not been fixed, Mr. Killion said, “Believe me, if there’s a way to do it, we’d do it. Maybe there’s a way out there we don’t know about.”

It is really inconceivable to think that that is considered an acceptable response to the problem in 2010. The most appropriate response, of course, is to liberate the electronic version of the application from the constraints of the paper form. There is no reason that an applicant’s information cannot be sent to schools in a purely electronic format. There is already an EDI transaction set, defined by ASC X12, for admissions applications—number 189, “Application for Admission to Educational Institutions”. Considering that the 130 and 131 transaction sets are already routinely used by many schools to exchange transcripts electronically, this does not seem so unreasonable.

Given that I do not have a copy of the ASC X12 EDI transaction sets, I can’t say how well the 189 transaction set would do for the data the Common Application collects. Of course, there is also a general movement away from EDI, in favor of XML-based formats, so I suspect that the new XML Admission Application developed by PESC might be a better choice.

In short, there are a multitude of solutions available to the Common Application—from improving the process which generates PDFs so that text is scaled to fit the available space, to moving to a purely electronic, XML-based process which casts off the vestiges of the paper form. Claiming that the problem cannot be solved, while it continues to unfairly penalize students who seek only to have their application information conveyed with fidelity, is not an acceptable solution.

Help me out by taking a brief survey!

This semester, I’m taking a course in user research and usability testing at the University of Maryland. One of the requirements for the course is to complete a group project involving a usability study of an existing product. My group is studying Google Docs, and I am conducting a survey on Google Docs and issues surrounding web-based word processing and spreadsheet software. I’d appreciate it if you would take the survey; participation is entirely voluntary, and you will not be identified by your responses. The survey is brief, and shouldn’t take more than a few minutes of your time. You can help even if you don’t use Google Docs.

Update: The survey is now closed; thanks to everyone who participated! Your responses were very helpful.

A tool for evaluating academic programs

While I was studying at McGill, I wrote a small Python script which read in an XML file which contained a description of university courses and programs; the script verified that each course’s prerequisites and corequisites were satisfied, and that the requirements of the program were satisfied. The script would then produce an HTML file listing the courses taken each semester (highlighting those with unmet prerequisites or corequisites), as well as the met and unmet program requirements. The script also used dot (part of the GraphViz package) to produce a diagram showing the interactions between course prerequisites. It is my understanding that software of this type is actually of commercial value, as evidenced by such things as the CAPP module in SunGard (formerly SCT) Banner, and its Degree Audit feature, which is similar to what has been described here. Other student information systems have similar features, but I have found that they all have certain shortcomings—one of the more common shortcomings is an inability to input course selections for future terms and perform a “what-if” analysis, making it possible to formulate a multi-semester plan, rather than simply evaluating the courses taken thus far against degree requirements.

I have recently dusted the code off and posted it to GitHub, in the hope that someone may find it useful. I’ve also made some improvements; most notably, dot is now used to generate SVG output which is directly included in the XHTML generated by the script. Previously, dot produced a PNG file and imagemap which were used together. The new solution is cleaner, as it allows the output to be contained in a single file. An example of the output produced can be found here. While I cannot say this with any certainty, I believe this type of graphical output is unique among degree audit tools.

A word of explanation concerning the name is probably in order as well; it refers to a document issued to incoming Engineering students at McGill which laid out, in great detail, and with little room for variation, the courses one would take over the coming eight semesters. This document was thus referred to as one’s ‘life’. Were you to deviate from it, you would find yourself in uncharted, shark-infested waters, and this software was designed to alleviate some of that.

I do not know if I will continue working on the software beyond what I have already done; if I do, then my priorities will likely be to make the necessary changes so that the degree evaluation information which is currently printed to stdout is also included in the HTML report, as well as improving the experimental Tkinter interface (which is also included in the Git repository).

Notes on the design of student information systems

Student information systems are frustratingly large, inflexible, and most often proprietary. Would an open format for data interchange spur innovation and modularity? And what new features could be developed in an XML-based environment?