This entry pertains to work done in the context of my employment. Please remember, however, that any opinions expressed on this blog do not necessarily reflect those of my employer or co-workers.
Admissions needed help. They had been moved from their former product, Exeter, to Banner’s1 native admissions module. But Banner’s interface stinks, and there was no decent way for counselors to do, well, anything. They relied on daily reports run out of an Excel pivot table by the executive directory of admissions, and therefore they lived on paper. The counselors needed a better way to get their work done and stay on top (figuratively speaking) of their recruits.
Enter my department. It fell to us, after some discussion, to build a tool that would be initial for undergraduate counselors, to let them slice and dice their data as needed. After a pilot run, it will gradually be expanded to include graduate and transfer admissions, as well as reporting tools for directors and and other muckity-mucks.
The current iteration is 4808 lines of code, for both the views and the comment submissions servlet. Most of it was written by me, though some was reused code, and the initial servlet skeleton was written by my boss.
The first thing an admissions counselor sees is a parameter page. There are a number of options to choose from:
- Term (can be multiple)
- Population selection (e.g. active applicants, active but non-applied recruits, enrolled applicants, etc)
- Student level (can be multiple)
- Recruiter (signed-in counselors will be auto-selected (can be multiple)
- High School (can be multiple)
Selecting from term or student level repopulates the possible recruiter list with only applicable options. Selecting “Undergraduate” applicants will necessarily filter out (or should filter out) graduate admissions counselors so they’re no longer an option.
Perhaps the toughest engineering challenge here was high schools. We currently have ≈10’000 high schools in our database, and will likely have a lot more soon. Loading all those into a multiple select box would make the page huge, and likely overload some underpowered browsers. My solution? Autocomplete. Using a simple JSP fragment and the Autocomplete plugin for jQuery, I was able to make a simple autosearch/complete behavior; selecting an item drops it into a list below the input box.
The odd thing about the plugin was that it didn’t end up being very flexible about the format of returned data. I had figured it would ask you to specify a data type and do your own parsing. It seems, though, that it only wanted one format: pipe-delimited data, with newlines between records. After wrestling with it for a while, I finally got it to work, but I really would have rather just returned XML and done some simple parsing.
The Table View
Once the parameters are chosen, the user gets a very complex table (the specifications were given to us by the Admissions department).
- Term (if >1 chosen)
- High School (if >1 chosen or none specified)
- Intended major (code display; full description on hover)
- Application decision (e.g. accepted, denied, etc) (code display; full description on hover)
- Student type (e.g. new freshman, transfer, etc)
- Athlete indicator
- Registered indicator
- Application status
- Green: complete, no pending items
- Yellow: complete, but pending items which don’t affect admission
- Red: incomplete: pending items affect admission
- None (has no application; is only a recruit)
- Financial Aid
- Green: all items complete, and aid is packaged
- Yellow: all items complete, but aid is not yet packaged
- Red: outstanding items; aid cannot be packaged
- None (has no financial aid)
- Date of application
- Composite admissions score
- Date of last comment (usually a contact with applicant)
- Visited campus indicator (is not currently used)
The recruiter can export this table as an Excel document for easy printing and carrying; otherwise, clicking on a recruit/applicant’s name will bring up a detail screen, which is divided into several sections.
The Detail View
I call it basic, but this is really the most detailed tab of this entire view.
- Application-related Items
- Entry Term
- Admissions Counselor
- Application Status
- Biographical Items
- Banner ID
- PIN (for helping with portal access)
- Last Portal login
- Student Type
- Advisor (email link)
- Residence (dorm icon for on-campus, car icon for commuter)
- College (Education, Arts & Science, etc)
- Date of Birth
- Phone Number(s) (shows primary; expands to show others)
- Email Address(es) (shows primary; expands to show others)
- Holds (is only shown when there are holds on the student’s account)
- Hold Type
- List of items which this hold prevents
- High School (for undergrad and transfer)
- Name of high school
- Graduation Date
- Class rank
- ACT composite score
- College (for graduate and transfer)
- Name of college
- Dates of attendance
- GPA transferred
- High School (for undergrad and transfer)
- Athletics (list of sports/activities)
The checklist is a simple table displaying pending and completed items necessary for admission. The applicant sees the exact same table when they sign into the portal, so now the counselor can see what the applicant sees.
This is a tripartite screen. The first and most important section is “Comments,” which is a sort of chronicle of counselors contacts with the applicant or the applicant’s parents. This screen is especially nasty using the native Banner interface, and so the object was not only to make the viewing nice, but also allow for the deletion, editing, and creation of comments.
Contacts and mailings are merely for records of correspondence the applicant or recruit has received, aggregated from several places.
This screen gives detail of all awarded financial aid, as well as both completed and outstanding documents. This, too, is almost exactly what the applicant will see when signed into his or her portal.
This screen, which details charges and payments for the student, is once again a replica of screens available to the applicant when logged in. These screens are mostly to provide parity for support with applicants who have questions about financial aid, bills, or schedules.
Once an applicant is accepted, and registers for class, this schedule tab will be filled out. It is a slight modification of the student’s schedule, which is displayed to them upon portal sign-in. Advisor see a similar view, since this is a module we reuse in several different portions of the web app.
The Big Finish
There are always bugs. I realize, just before going live, that the abbr tag that I used so heavily in the tabular view isn’t natively supported by Internet Explorer 62.
Luckily, good old Dean Edwards notes that for some reason, prefixing the namespace to the
<abbr> tag makes the damn thing suddenly work, and it’s still valid XHTML! Crisis averted.
As with most of our web application, we make heavy use of jQuery. Specifically for this application, we make use of the UI Tabs plugin, the UI Autocomplete plugin, and jQuery’s native AJAX functionality. We also use the Unobtrusive Tablesort Script from Frequency Decoder, which has much better performance than jQuery equivalents.
As I said, this is only a first try at a first stage, but we’re pretty happy with the progress, and the admissions folks seem to be as well, so we’re doing something right.