Waiting for WebRegistration:
One Small College's Solution
Scott Dittman, University RegistrarWashington and Lee University
Jeff Knudson and John Hellmuth,University Computing at Washington and Lee
MOSIS 2000 Springdale, Arkansas
Session T.3.2, Tuesday, July 18, 2000
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Washington and Lee University
Founded in 1749• saved by a financial gift from George Washington
• Robert E. Lee's only job after the "unpleasantness"
Lexington VA (pop. 7,000 including students) 1,740 undergraduates, 360 law students 4-4-2 (12-12-6) calendar initiated in 1969 190 undergraduate faculty, 3-3-1 normal teaching load University Registrar's staff:
• 2 exempt, 2 support, 2 PT students
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
W&LUniversity Computing today
Hardware
• 1,300 university owned PCs; 90% of students own
• personal Ethernet connections for campus residents, Novell NetWare
• free dial-up PPP access for non-residents, faculty, staff
• T3 Internet access, T1 for Lexis/Nexis, backup T1
Staffing
• 25, several of whom are permanently assigned to support specific schools or departments - only 1 administrative programmer/analyst
Budget
• $500,000 non-salary annual operating
• $1.5-2.0 million annual capital including replacement
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The problem
Manual system: paper forms, headcounts,wait lists
Long lines outside of department offices and the registrar's office - students cutting class, esp. early
Outdated information, poor communication
Poor enforcement of registration priorities
W&L idiosyncrasies (calendar, balance, no section registration, 75% of all courses required a signature)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The charge
In 1995, as part of developing a University-wide, 5-year strategic plan, the president charged a group of faculty, staff, and students to
"determine the means and timetable for a flexible and widely accessible on-line registration process, estimating the feasibility and benefits, as well as the costs and liabilities. Consider compatibility with the degree audit program and other student records, and also the relation of registration to matriculation."
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The first committee
Comprised of the following:• 6 faculty, two of whom are alumni:
* disciplines: mathematics, journalism, French, religion, physical education, management
• 2 students, a sophomore and a senior• 4 administrators:
* university registrar, associate academic dean, controller, director of administrative computing
Met for 5 months: Oct.1995 through Feb.1996
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The priorities
NOT paper-based
Faculty control of enrollments and advising
Minimize signatures; let the system count noses
Easily updated with added or deleted courses
Interactive so students know what's open (course availability)
End with balanced enrollments within a course
Cost-effective
Secure, confidential, and fair
Appropriate staffing support
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The options
Online with hard wiring directly to mainframe• problems: security and user training, no interface, firewall, cost
of dedicated terminals/PCs • had been tried in 1987 with only mixed success & acceptance• looked at Oberlin's system which allowed for off-campus access
Telephone registration (voice response)• problems: perceptions of less personal contact, "high" initial
financial and labor cost ($35,000-80,000), high continuing
maintenance costs (primarily labor)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The options (cont.)
Customize existing software• Datatel customer since 1982, live since 1983• Software at that time did not have an "easy" interface• Costs for out-sourced programmer estimated at
$150(!) an hour (now much higher) with no internal commitment to staffing for long-term maintenance
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The options (cont.)
Delivery via intranet/Internet as web page• problems:
* still relatively new (remember, this is 1995-96)
* costs unknown
* access by faculty and students not ubiquitous
• advantages: * "it's coming fast,” promise of long-term stability & ease of maintenance
- commitment for the University in place, including campus-wide network and widespread e-mail use (97% of students, 98% of faculty)
* had staff expertise on both sides of the data manipulation stream (Datatel data exporting, web/Perl programming)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
The initial recommendations(March 1996)
-move advising to the week before the registration process rather than during registration week
-develop a one-year calendar for planning, programming and testing, and involve all segments of the university (offices, department heads and faculty, students) in the development
-install secure web software on the campus network -arrange for custom programming -confirm the technical requirements for hardware
availability and capacity -develop faculty and staff training information and
student documentation and instructions
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
In the meantime …
All computing issues were removed from the Five-Year Plan recommendations
Met individually with department heads to find one system to which all departments would subscribe
Continued with manual registration (paper forms, lines, signatures)
Recommendations were implemented piecemeal
Fall of 1997, two events moved us forward ...
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Kick start
University Computing offered to help me develop a web interface for registration (October)
Upperclass students panicked the freshmen with rumors of getting no courses if they didn't spend the night waiting for registration signatures. Approximately 80% camped out (November)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Committee #2 is formed
In January 1998, the urgent charge was to develop a WebRegistration system which would
• approximate the priorities of the redesigned manual registration process
• eliminate lines• operate interactively• enforce the system fairly regardless of department
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Committee #2
Comprised of the following:• 4 faculty:
* disciplines: chemistry, journalism, physical education, politics
• 2 students, the freshman class president and a sophomore
• 6 administrators:* university registrar and assistant registrar, associate academic dean,
controller, director of administrative computing, systems analyst, webmaster/systems specialist
Met for 4 months: January through April 1998
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Priorities
Eliminate paper Increase quality advising time Changes in offering and availability immediately
accessible Transfer mechanics to students Allow for “standing” in multiple lines Don’t cut class to do registration Improve communications between faculty, students, and
University Registrar
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Process
Consensus, rather than majority votes
Individual and group creativity
Formatting proposal from University Computing
Reactions to formatting proposals
Constant “tweaking” of appearance and mechanics
Introduce one piece at a time
Frequent public comment, including web forum
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Schedule
-PreRegistration (added late from student suggestions and faculty interest) - May 1998 for Fall 1998 - followed with final paper registration
-Freshman PreRegistration - Summer 1998 - results given to advisers as conversation starter
(overhead) -Late summer classes for advisers - mechanics and strategy -Upperclass students change paper results - September 1998 (total
of 200 made changes on the web without instruction but with nearly 100% positive feedback
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
… continued ...
Fall 1998 freshmen registration completely web-based, without training (“how self-evident” test).
Hotline/HelpDesk staffed by University Registrar and volunteer deans and faculty for those students whose advisers had problems or preferred not to do computer work
System ground to a halt because, unbeknownst to the planners or computing staff, a parameter limiting the number of simultaneous web transactions was in place. As soon as the parameter was increased, the process resumed without incident.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
… continued ...
Manual drop/add process has continued (one week, simple form, avoids need for additional advising password)
October 1998 - first all-campus PreRegistration (98%)• extensive documentation on the web, getting hundreds of hits
• numerous offerings of training/feedback classes, few attendees
November 1998 - first all-campus WebRegistration• late registrants dropped from 65 to 4
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
W&L WebReg system: Hardware
Today•T3 to internet with T1 backup through
alternate provider•1 Gb campus backbone•"Liberty" web server: HP 9000 D250, running
dual 100 MHz processors, 10 Mbs connection to backbone
•"Augusta" database: HP 9000 K200, running quad 100 MHz processors, 10 Mbs connection to backbone
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Software
Administrative database software is Datatel’s Colleague, release 13.13 on Augusta
Composed of five sets of software on Liberty:•Central Systems Interface•Student Access•Faculty Access•Administrative Control•Archiving and Health Checks
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Central Systems Interface
The Central Systems Interface is composed of a Perl client program on Augusta, which passes commands to a Perl server process on Liberty, which in turn executes the appropriate WebReg database functions. These commands include the creation/modification/deletion of courses, the creation/modification/deletion of student accounts and updates to the Hold table.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Student Access
The Student Access software provides an interface between the web server on Liberty and the student WebReg databases. Through these Perl scripts, students may view, add and drop courses from their registration schedule. They may also view listings of available courses and view the current enrollment numbers and limits for each course.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Student Access
Two passwords (random 4-digit)•PreRegistration: course interest, provided by e-mail•Web Registration: sent to advisers for release after
advising Assigned access window (36-60 hours) - starts every 30
minutes from 10 am to 3 pm•Class•PreRegistration participation required•History of start times - average at 12:30 pm over 4
terms•Current class schedule•Random within class (overhead)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Student Access The chart below shows freshman WebReg traffic; red = the number of simultaneous Web
connections, blue = the total load on Liberty
(overheads)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Student Access
http://www.wlu.edu/registrar/newreg.htm
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Faculty Access
The Faculty Access software provides an interface between the web server on Liberty and the course functions of the WebReg databases. Through this Perl script, faculty may accept students into a course from a wait or permission list and send group emails to registered or wait‑listed students. Department heads may set course enrollment limits, modify the class distribution of the limits and set a message to be displayed to registering students.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Faculty Access
Two levels of passwords sent to department head only
•Department head: allows determination of course limit mode and numbers, special message, and faculty privileges
•Faculty member: allows manipulation of wait lists and use of e-mail features
Limit modes•Single limit - first come, first served•Class limits•Major/non-major limits•Permission required - also single limit plus faculty action
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Faculty Access
http://olr.wlu.edu/cgi-bin/apps/registrar/reg/list.pl
http://olr.wlu.edu/cgi-bin/apps/registrar/reg/fac.pl
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Administrative Control
The Administrative Control software provides an interface between the web server on Liberty and the administrative functions of the WebReg databases. Through this Perl script, the University Registrar may control access to the WebReg screens and toggle the ability of faculty and students to modify the WebReg data. Event logs are available by day or by student.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Administrative Control
Super user Maintenance and override access for all functions, including passwords, holds, and times
Access to logs (current term) and archives (previous terms)
Access to history of communications: conflict messages, prerequisite checking, wait list permission, course cancellation e-mails
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Administrative Control
http://olr.wlu.edu/cgi-bin/apps/registrar/reg/admin/index.pl
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Archives
Every half hour, during registration, checkpoint files are created (cron processes) which archive the state of the course and student databases and updates the Datatel database.
The entire WebReg database structure may be recreated from any set of these archive files. An audit program compares versions, verifies the integrity of the WebReg databases, and debugs any discrepancies.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Archives
Archive Files: a plain text snapshot of the WebReg databases. They are composed of three files, Courses, Enrollment, and Student.
• Courses: department, course, title, credit(s), general education flag, limit mode, limits, equivalent (cross-listed) course, permission required flag, associated majors, faculty password, department head password, associated message
• Enrollment: student user name, selected courses, first choice wait-listed courses, second choice wait-listed courses, PE courses
• Students: user name, password, full name, year, major, maximum allowed credits, holds, start time, end time, adviser
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Data
Composed of the following data stores:•Course Databases•Enrollment Databases•Student Databases•Hold Table•Event Logs•Archive Files
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Course Data
Course Databases: Perl DBM containing the descriptive elements for each course.
• department, course, title, credit(s), corequisite(s), prerequisite(s)• general education area notation• limit mode and limits and permission required flag• equivalent (cross-listed) course• associated majors• faculty username and password, department head user name and
password• associated message
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Enrollment Data
Enrollment Databases: Perl DBM containing the students registered for or waiting for admission into a course.
•counter•data for each student - student user name and ID, class year, major(s), credits accumulated
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Students Data
Student Databases: Perl DBM containing the descriptive elements for each student as well as the list of courses that the student has selected.
•user name, password• full name, class year, major(s)•hold flags, start time, end time, adviser, •maximum allowed credits (14 in long terms), current
credits accumulated, number of wait lists, number of permission lists, pending notice to student, courses selected, courses waiting, PE courses selected
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Holds
Hold Table: a text file containing the hold flags codes, descriptions, and associated phone numbers, for example,
•RG*REGISTRAR’S OFFICE*463‑8451•BO*BUSINESS OFFICE*463-8730•LR*LIBRARY-REG ALLOWED*463-8643•IR*HEALTH CTR-REG ALLOWED*463-8401
Hold flags update cron is run every 5 minutes
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Logs
Event Logs: text files containing detailed logs of each event that occurs in any of the WebReg subsystems.
•time stamp•user name•event and description (drop from schedule, drop from roster, admit to course, warnings, etc.)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Results
WebReg results are run through batch process to assign times and balance schedules
Schedule available via the web to students
Advisers receive an e-mail schedule for each advisee before and after drop/add
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Bug List
Under very heavy load, a race condition may occur if a student adds a course then immediately resubmits the same request. No data corruption occurs, but the second process hangs and must be terminated by a watchdog program (also a Perl script). This will be resolved when the SQL database is implemented.
If a user uses the Back button to overwrite PE courses, he may cause an entry to be dropped from the course database that still exists in the student database. This will be resolved when the SQL database is implemented.
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
WebReg: Enhancements
•Replace the many Perl DBM databases with a SQL database.
•Rewrite the databases access modules to take advantage of Apache Fast‑CGI, which will greatly improve performance by eliminating the need to spawn a new process whenever a database event occurs.
•Rewrite the authentication code to integrate the Novell NetWare user accounts for students and faculty.
•Migrate the entire package to a compiled language such as C++ to increase performance.
•Develop faculty post-WebReg advising & course management
•Others??? (e.g. move to secure server)
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
Information Links
Technical assistance and contacts:• John Hellmuth, [email protected], Systems Analyst: Datatel database, Unix, cron,
Uniquery reports
• Jeff Knudson, [email protected], Network & Systems Specialist: webmaster, Perl, Unix
University Registrar's page:• www.wlu.edu/registrar
WebRegistration instructions and strategies page:• www.wlu.edu/registrar/newreg.htm
WebRegistration starting page (no password required ‑ feel free to play):• olr.wlu.edu/cgi-bin/apps/registrar/dev/admin/index.pl
MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution
… links continued ...
Planning group:• www.wlu.edu/registrar/webreggrp.htm
WebRegistration development feedback forum:• www.wlu.edu/cgi-bin/apps/forum/aforum.pl?forum=online_reg
WebRegistration process articles:• advice to students (April 1998):
www.wlu.edu/computing/news/access/97-98/march/webreg.html
• first feedback report (June 1998): www.wlu.edu/computing/news/access/97-98/June/webreg.html
• follow-up report (January 1999): www.wlu.edu/computing/news/access/98-99/jan/05register.html