UC Berkeley Department of Political Science

Online PhD Application Management and Review System

Prepared and submitted by Janet E. Newhall

Project Leader: Janet E. Newhall, Graduate Advisor for Admissions and
Job Placement
Team Members:
Tim Fisken, programmer)
Gilbert Hernandez, department IT professional
Andrea Rex, Graduate Advisor for Current Students
Vicki Lucas, Department Manager

Project Summary
The Department of Political Science, UC Berkeley internally designed PHPbased online application management and review system was designed
based on successful systems at other UC campuses and at Berkeley, along
with the expressed needs of department faculty and staff, as well as
prospective students. The result is a comprehensive application data,
document, and review system that has dramatically simplified the
application management process. This has allowed us to dramatically cut the
number of staff hours required during the admissions process, improve
student service to our applicants, and create a high quality and efficient
review process for our faculty admissions committee.
Project Description
About five years ago, the staff and faculty in the department decided that it
was time to move to an online PhD application review process rather than
the traditional paper review process still used by many departments today.
The campus was fully engaged in accepting applications online, and we felt
we should take advantage of the process. For two years, we used a primitive
but fairly effective internally-designed system to which we could upload data
collected by the Graduate Division application and allow faculty on the
admissions committee to review this data online. While faculty fully
embraced and appreciated the online review process, several limitations of
the system prevented a smooth review process and proved to be very labor
intensive for staff members who would scan and upload each document
submitted by applicants through the mail, which totaled in the thousands.
Encouraged by campus enthusiasm for a new system being designed in
another department called Our Unit, the department decided to retire the
internally designed system and subscribe to this new system. Within a short
time at the beginning of the following admissions cycle, we realized that in
addition to a few serious security concerns, Our Unit failed to meet many of
the needs of our admissions committee including searching, sorting, and
reporting, all of which are essential aspects of our review process.
We then decided to build a new system with the goal of creating a system
that would not only meet our current needs, but would also be dynamic and
flexible enough to meet our changing needs in the future, and hopefully the
needs of other departments on campus. We began by researching the
systems used at other UC campuses followed by visits to the admissions staff
at departments on UC Berkeley campus with exemplary systems of their
own. We then created a flow chart of the needs of our three primary users,
which are applicants, staff, and faculty. The following three sections outline
the functionality of the system for each of these groups.
Applicants

 One of the primary needs of an applicant during the application process

is regular updates on the status of the application. Whether weve
received their official transcripts, recommendation letters, official GRE
scores, etc. The standard method for handling this need is for
applicants to email staff, and for staff to go through physical or
computer-based files to find whether these documents have been
received. We therefore developed a simple, short, online summary page
where applicants can see a list of the materials we are expecting and
which of those we have received. This information is entered by staff.
Two specific documents that our department requires for the application
that are not required by the Graduate Division are a writing sample and
CV. Previously, these documents were sent by mail, which resulted in
enormous stacks of paper mailed at great expense by applicants, and
managed over many staff hours for faculty review. The applicant
summary page also includes an Upload Document function for these
two documents, saving both staff and applicant a great amount of time
and resources.
Occasionally, admissions staff may wish to convey a message to the
entire applicant pool or to individual applicants about the admissions
process or individual files. The normal procedure has been to send a
mass email. Staff can now leave personal or all-applicant messages for
applicants that appear at the very top of the applicants summary page.
These messages also include the email address of our admissions office
in case the applicant has further questions.
Staf
As mentioned in the student section, staff can now enter when they
have received an applicants document with great ease, which is then
conveyed in real time on the applicants summary page. This not only
saves an enormous amount of time in individual correspondence with
applicants, it simultaneously greatly improves student service by
providing immediate feedback. This also provides faculty and staff with
an accurate record of which materials are accounted for in the
application. Staff are also able to update the decision status of each
application (not viewable by applicants) as the committee progresses
through its decision making process.
Since our system is able to automatically pull updated data and online
recommendation letters from the Graduate Division admissions
database, we are able to regularly glance through applicant files to
update the status with the click of a button to indicate to all users
whether a file is complete. Because we mark both individual sections
(i.e., whether weve received all expected transcripts), as well as the
application as a whole, faculty can decide whether to review an
incomplete application based on the materials present.

 Because many campus people are using the system, it is essential to

limit the functionality and privileges of each of these people. People
identified by campus as members of this department are automatically
listed on our privileges page, and staff can choose to designate them as
one of a number of assigned roles such as staff administrator,
admissions committee chair, committee member, or non-committee
member faculty.
Staff are able to leave messages within the system for both applicants
(which appears on the applicant summary page) and for faculty, which
they see when reviewing each file.
Sorting and reporting functions allow staff to keep track of a variety of
groups of applicants such as complete applications, or which applicants
are applying to a particular specialization within the department.
The person(s) assigned as staff administrator are able to change a
number of system settings, which creates some flexibility in how the
admissions process takes place. Settings which may be changed
include designating a new admissions cycle (therefore archiving
previous cycles, which can then be easily accessed later), which
materials are required by applicants, and the status options for
applications.
Faculty
The committee chair has the authority to assign faculty committee
members to review specific applications. The chair can assign one or
multiple faculty at once, and as many or few as he sees fit and within
the current parameters of department admissions policy. These
committee members can then enter their own names into a search box
to find the list of applicants to which they were assigned.
After committee members find their list, they can search and sort the
list by one or more of a number of application elements including
undergraduate institution and/or GPA, preferred subfield of study, and
current committee evaluation average score. They can then click on an
applicant name to view that file, and scroll through all applications
within those search parameters without having to return to the list,
which saves the reviewer a great deal of time and frustration when
combing through over 100 applications.
While reviewing an applicant file, the reviewer may expand or shrink
each section of the application for easier viewing of specific sections of
the application. For example, if a reviewer wishes to glance at the GPA
and GRE score breakdowns of each of their assigned applicants within a
certain subfield, they can create a viewing environment which allows
them to do this with ease.
In order to review application documents such as transcripts,
recommendation letters, and writing samples, a reviewer clicks on the
name of the document, and is brought to a page within the system with

an embedded PDF viewer. Unlike most other application review

systems, this prevents the need for a new PDF window to open, and
allows to reviewer continued access to a few main menu items such as
return to applicant without having to use browser functions. This has
also allowed us to include buttons allowing the reviewer to scroll
through all of the documents in an applicants file without having to
return to the main applicant page. This functionality brings to online
review one of the preferred advantages of reviewing applications by
paper, which is the ability to flip through the pages of the application.
As the committee member reviews files, he or she can immediately
leave and save comments and scores for the applicant within the
system. Committee members are able to edit their scores and
comments during the review process as they become more familiar
with the applicant pool or learn additional information about an
applicant. These comments and scores are currently viewable by other
committee membersas dictated by current department admissions
policybut this can easily be changed to make this information
confidential from other committee members.
Once the reviewer has finished with all applications, he or she may
choose to manipulate data in far more complicated ways than is within
the scope of this system. Therefore, we added the function to export
data to a csv file, which includes the reviewers individual scores for
each applicant. This exported data file is also used during the
admissions review meetings, when each committee member brings his
or her own laptop with which to review individual files during the
meeting, and the admissions staff person at the meeting manages the
decisions being made during the meeting using the exported
spreadsheet.
Summary
Most campus departments have developed their own procedures for dealing
with the massive undertaking that is admissions. Some have created
FileMaker Pro databases to manage data. Many have some combination of
paper and online application management and review, while some still
conduct the entire process by paper. As the UC Berkeley campus works
toward developing a new campus-wide application system, they are
exploring the possibilities for including a comprehensive online review
system for all departments to use, as well. Our department has been closely
involved with the development of this system, and we are confident that our
online review system will be an important model for the based on feedback
from other admissions staff around campus as well as central campus
admissions managers. Because our system has been largely inspired by
some of the best in the UC system, we believe it to be one of the best
department-developed admissions review systems and hope to be able to

share our greatly improved admissions process with many others around
campus and throughout the system.

Technology Used in the Project

Scanning
Software and hardware from Canon are heavily utilized in the scanning segment of
the workflow. Hundreds of application documents go from a physical medium to an
online form in mere minutes instead of several hours and days.
Software/Hardware
Usage
Canon imageRunner 7095 Digital
Scans a batch of documents (Letters
Copier
of Recommendation and Transcripts)
received from applicants and stores
them on an on-campus file server as
a single file
Canon imageWare ScanManager
Indentifies, indexes, separates,
renames, and stores each document
from the batch file scanned by the
copier as individual PDF files on the
file server.
Web Application
The web application follows common practices and utilizes standard web
development technologies such as PHP, MySQL, HTML, JavaScript, and XML. Below is
a table of specific tools found in the project that use these technologies:
Technology
Usage
Zend Framework
Zend is an MVC (Model-Viewhttp://framework.zend.com
Controller) PHP framework used as a
building block to create web
applications. We elected to use a php
framework, like Zend, to eliminate
the need to reinvent the wheel
when writing code needed to connect
to databases, authenticate users, etc.
phpCAS
CAS is a secure authentication
http://www.jasystem used to securely log users in
sig.org/wiki/display/CASC/phpCAS
and out of the system. Each user,
when authenticated and recognized,
is assigned a specific role in the
system thus increasing application
security by limiting user rights and
permissions to certain functions
related to that role. phpCAS is a
module written in PHP to help
integrate and facilitate the
authentication within the system.
jQuery
jQuery is a JavaScript library used to
http://jQuery.com
help ease coding by providing many
useful functions for document
traversing, animation, event
handling, etc. jQuery is used in the
system to animate certain sections of
the user interface (UI) for better

usability. (e.g. Clicking section

headings can toggle sections of the
applicant view thereby eliminating
clutter on the page)

Other Campus Systems Utilized

The system utilizes preexisting campus resources to
These campus groups and tasks are detailed below:
Group
System
UC Berkeley Graduate
Graduate Admissions
Division
Oracle Database (ODBC)

UC Berkeley College of
Letters and Science
Computer Resources
Unit (LSCR)
http://ls.berkeley.edu/lsc
r
LSCR

Web Server

File Server

accomplish several tasks.

Usage
Our system uses several
views of the Graduate
Divisions admissions
database to retrieve
applicant information
such as Letters of
Recommendation,
Statement of Purpose,
Field of Study, etc.
Web and MySQL
Database hosting

Temporary storage of
scanned PDF documents
from copier

Timeframe of Implementation
The entire project took approximately 5 months to complete (May to November).
Stage
Timeframe
Scanning and File Storage
3 weeks
Needs Assessment
1 week
Application Design
2 weeks
Application Coding / Implementation
10 weeks
Testing / Debugging

4 weeks

User Comments:
The admissions database system was designed for use primarily by the faculty
admissions committee. Committee members responded extremely favorably to the
electronic system on multiple grounds: ease of use; efficiency; transparency;
ability to revise and compare rankings from different committee members; and
overall reliability/security.
One member of the admissions committee, serving for the first time this year, said:
The system was incredibly helpful. By having direct access to a
database of documents, I was able to review files at any time or place I
found convenient, without having to worry that while I had the file
checked out someone else was unable to use it. The system is also very
well-organized, making it easy to compare applicants in any major
dimension.
Another faculty member who had served on the admission committee several times
in previous years, commented by saying,
The graduate admissions system has been dramatically improved by
going
paperless. The current system is easy to navigate from one
application to another or from one piece of a candidate's file to others.
The ability to enter comments, see the comments of others, and edit
one's own scores provide additional pluses. This has worked
exceptionally well and clearly facilitated my own review of files.
The continual improvement of the database was highlighted by a committee
member, who said this years system made reviewing files easier and more
systematic and said it was great not to have to haul a big stack of applications
back and forth between home and office. Even more than convenience and
efficiency, however, this committee member emphasized how the database
improved the quality of the selection process itself:
Each year, admission committee members write more comprehensive
qualitative evaluations in the remarks section, allowing us to make more
accurate assessments in later rounds. Instead of just looking at a
quantitative score, we can also refer to these qualitative assessments.
The qualitative improvements in the process figured in the comments of another
committee member, who compared the admissions process in Political Science to
that in other departments:
I think the admissions database is fantastic. I do admissions in another
department, too, and the database is the single most important factor in
making the process in Political Science more efficient, more humane,
more transparent, and more equitable. [T]he way my other
department does this (not allowing any files to leave the building, which
is locked in the evenings) is really tough, and I suspect it leads to all

sorts of corner-cutting. Facing well over four hundred applications, I'm

at a loss to explain how we could do without the electronic database. I
found it intuitive and easy to use, and was delighted to find that the
information I wanted was always available for each file and
comparatively.
The committee chair for 2009-2010 also noted that the electronic database
permitted secure access to particular applications by a range of faculty colleagues
in the department, with important consequences for making good admissions
decisions and for using departmental resources efficiently.
By allowing non-committee colleagues to read particular applications
without transferring paper files, the new system greatly improved the
committees ability to get specialized readings of individual applicants
to the graduate program. This led to better decisions and more reliable
matching of applicants to departmental faculty. In several cases, it also
led to important cost savings for the department when non-committee
colleagues suggested funding sources for particular applicants that the
committee would otherwise not have not been able to identify or secure.
According to the committee chair, all committee members commented informally
on how much more difficult the process would have been without the electronic
database to facilitate and guide their readings.