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 PHP-based 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 we’ve 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 applicant’s summary page.
These messages also include the email address of our admissions office in case the
applicant has further questions.
Staff
 As mentioned in the student section, staff can now enter when they have received an
applicant’s document with great ease, which is then conveyed in real time on the
applicant’s 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
we’ve 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 applicant’s 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 members—as dictated
by current department admissions policy—but 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 reviewer’s 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 Copier
Scans a batch of documents (Letters of
Recommendation and Transcripts) received
from applicants and stores them on an oncampus 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-View-Controller) PHP
http://framework.zend.com
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 system used to
http://www.jasecurely log users in and out of the system.
sig.org/wiki/display/CASC/phpCAS
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 help ease
http://jQuery.com
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 accomplish several tasks. These campus groups and
tasks are detailed below:
Group
System
Usage
UC Berkeley Graduate Division Graduate Admissions Oracle
Our system uses several views
Database (ODBC)
of the Graduate Division’s
admissions database to
retrieve applicant information
such as Letters of
Recommendation, Statement
of Purpose, Field of Study, etc.
UC Berkeley College of Letters Web Server
Web and MySQL Database
and Science Computer
hosting
Resources Unit (LSCR)
http://ls.berkeley.edu/lscr
LSCR
File Server
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
year’s 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 cornercutting…. 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 committee’s 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.