Technical Overview

ClassWeb was designed to let instructors easily create and control a class website without learning HTML, FTP  or needing to be assigned a UNIX account on our web server. Instructors just need a web browser and a ClassWeb username and password to administer their site.   ClassWeb was designed to make my job in web support at Social Sciences Computing, UCLA easier.  It ended up making it a lot more fun.

In 1995 and 1996, a growing number of Social Sciences faculty at UCLA were coming to us for webspace on our web server. We would give them accounts on our Unix web server (then running NCSA, later upgraded to Apache). While this was sufficient for some technically-savvy faculty, most were not interested in learning the technical details of running a website. We did not feel they should have to, nor did we want to create every site by hand.

In 1996, after hearing about the Virtual Office Hours Project developed by Prof. Craig Merlic and Matthew Walker in UCLA's Department of Biochemistry, we reviewed it with some of our Social Science Faculty and decided to try writing our own version. The deciding factor was finding Jeff Carnahan's Upload.pl Perl CGI Script (available at Misc CGI Scripts - click on FileUploader 6.0 for free, but registration required) that did File Uploads via a web browser.  With that, Matt Wright's WWWBoard, a Calendar script that we later discarded, and a script we wrote to edit files on the fly, we figured we had enough to make something useful.

Originally the plan was to have instructors fill out a web form to request a site. But I was having problems getting the email to work so I asked my boss if he minded if the sites were created instantly instead. That turned out to be easier. We added a password and emailed it to all the Social Sciences faculty and waited to see what would happen. We figured we weren't in too much danger since our logs would record all the sites created and anything bogus could be quickly removed.

We first offered ClassWeb to UCLA Social Sciences Faculty in the Spring Quarter of 1997. Eight instructors set up ClassWeb sites (see Spring 1997 sites). We considered it a success when one instructor used the class discussion board for student assignments and never once came to talk to us.

Original Features - Spring 1997

Current Features - Spring 2000

upload files (and add them to the class menu automatically) add or edit announcements add or edit links (URLs) add or remove discussion board postings edit basic course info edit instructor info create a private, password-protected directory

Discussion Board posting limited to students on roster (optionally board can be open/anonymous) "roster-authenticated" private directory (see glossary) email to students on roster, optionally saves to Announcements Page List of Links Page Editor can now be organized hierarchically additional Discussion Boards can be created instantly by the Instructor Popup Links Flashcards Annotation Board (comments can be placed in middle of text - see glossary) Teaching Assistants can have their own websites Grades can be posted and viewed securely

Scaling Up

That summer, in July of 1997,  the College of Letters and Sciences at UCLA initiated an Instructional Enhancement Initiative fee for all undergraduate classes. Though much of that was to go to new computer labs, all undergraduate classes were now required to have a class website with an interactive component. Our big decision was whether to scale up our homegrown ClassWeb, or buy a commercial package like WebCT (UCLA Humanities went with WebCT). WebCT, while very impressive, seemed to be overkill for our faculty. (Too much to learn for the uninterested and the others were either happy with ClassWeb or were running their own websites already.)  Also, WebCT was just finishing their beta-testing three weeks before the start of our Fall Quarter.

Worse, from my point of view, WebCT required a login ID and password for each student in each class - something none of our faculty had asked for so far (and still haven't two years later). Basically it was a closed system, while we wanted ours to be open by default. All ClassWeb sites are open to the world except for material instructors upload to password-protected directories.  For the first few years, those were protected by generic username/passwords which the instructor would select and announce in class. With the incorporation of the UCLA Administrative Systems Authentication Server, and daily Registrar roster downloads to our MySQL database, we have roster-only private directories for each class where students have to authenticate themselves with their UCLA ID# and the same pin code they use for telephone course registration. 

There were 312 Fall 1997 ClassWeb sites. 211 of them done with ClassWeb, 90 more were run separately on our server. The History Department decided to go their own way, and 11 classes had external sites. We centralized our Perl scripts into a set of central subroutines with only a small "stub" in each directory. The one thing I knew was that we'd be making modification and improvements all the way along the line, so centralized subroutines let us change features whenever we wanted. Unfortunately, they also let us break everything in ClassWeb all at once too!

That Fall Quarter 1997, we set up the sites by having our Help Desk student staff fill in the web page forms by cutting and pasting information from UCLA directories, class schedules and course catalogs. Everything was static HTML pages. But it worked. Then we started "scraping" the Registrar's web pages for data and storing it in "flat files" (see glossary).

In Summer 1998 we started getting downloads directly from the Registrar's Office. At this point we started switching over from all Perl and HTML to PHP "templates" (see glossary) linked to a MySQL database.  Many Perl scripts remain (we didn't have time to rewrite scripts that were working), but for speed and ease of database access, most of our new features are done in PHP and MySQL.

What We've Learned

From this vantage point, three years later and over 3,000 ClassWeb sites later (complete list of classes here), our gamble has paid off and there have been some unexpected fringe benefits.

• Because we wrote the software, we could change it. Most of the changes came from faculty suggestions. When one faculty member asked us to add the ability to email to the class roster, it took us three weeks. (Most of that time was spent in handling the complication of cross-listed classes.)  That one feature has been the most appreciated by our faculty and Teaching Assistants.   See List of Features for all the other improvements.
• A tight feedback loop where faculty talk directly to programmers has made all the difference.
• Open class sites that stay up permanently (so far we have managed to keep all our old classes online unless removed at the instructor's request) allows us to use them as examples. See ClassWeb in Action. 
• We did find it necessary to discourage search engines from our class sites by using the robots.txt protocol.
• Simple, easily grasped tools are essential for faculty who are extremely busy with their teaching and research.
• One-on-one one hour meetings, when the faculty member is ready and interested, are enough to show off the basics of ClassWeb and start talking about their specific class needs.  
• Everything we showed them, we would of course do for them. It's not their job to learn the technology. That's our job.
• I strongly supported anonymous discussion boards. I was wrong. My argument was that students would be more likely to post messages if they didn't have to give their name. The more important argument is that faculty will be more willing to make use of class discussion boards if they are not anonymous. And bogus postings disappear if they are restricted to the class roster and the name of the poster automatically appears.
• Of course we left the option to have anonymous boards and some instructors take advantage of that.
• One of our departmental "webtechs" (see glossary) noted that classes where the TAs had admin privileges usually had more material posted. So we made it much easier to add TAs as administrators. When the History Department came into the fold (with their own templates and complete control of their sites) they pushed us to add and option for TA websites.
• In Winter 2000, we gave TAs their own portal where, by logging in with their UCLA ID, they can change their office hours and personal info, see and email their section rosters and create their own TA sites immediately.
• We have moved to roster-only private directories although some instructors still prefer a classwide generic password.
• There is a long list of ideas and suggestions requested by faculty and I'd have to say that those discussions are what makes this project so interesting.

Design Goals

easy to use, easy to administer

At most it should require a one-hour demo

rely on server-side as opposed to client-side programing wherever possible

Faculty & student PCs vary so widely we couldn't count on Java or Javascript to work across all their machines. I think we only have two JavaScripts (Popup Links & a special Discussion Board warning for the History Dept's version of the Discussion Board); the rest of ClassWeb is entirely "server-side" software (see glossary). No Java programs up till now, but it might be time to start reconsidering this rule.

change as little as possible

In other words, don't take away what people are used to.

ongoing improvements

One thing I knew was that we would be making changes and fixes constantly.

do it manually till there's a pattern, and a need

This is obvious, but not every special request needs to be incorporated into the entire program. Sometimes we'll do something by hand, or install a special purpose script for one class, then if we find it's useful and needed, we take the time to incorporate it as a new feature.

Components

Database

Every Class Page is basically a query to a database of classes and instructors and students. This is supported by daily downloads from the Registrar and Campus Telecomm's Faculty & Staff Directory. Many other tables have been added (see complete list) as we convert more of ClassWeb to be database driven. Your first step will be to figure out how you'll get your own data, and what structure it will have. At the back end, we're using MySQL. If you choose something different, you'll have to change the database calls in the scripts.

We haven't figured out how to query the Registrar's Microsoft SQL server directly from Perl on our Unix box, so we have an intermediary NT box running a Visual Basic program to grab the data, put it in flat files, then FTP it up to our Unix web server. See Figure 1

Figure 1: Unix - NT - Microsoft SQL Server Download Process

Class Websites

Class websites each have their own directory, underneath a directory for each quarter since UCLA is on the quarter system. Conceivably, each class could be entirely template and database driven, but uploaded class files need to be stored somewhere. So having a directory comes in handy. Plus, we haven't finished converting all the elements of ClassWeb into a database.

Each class website has a minimum of three subdirectories underneath a class directory: wwwboard, admin & private.  ClassWeb's File Upload utility allows files to be stored in either the class directory or the private directory. If other directories are created manually (by someone with telnet or FTP access) then files can be uploaded there as well.  The wwwboard directory is used to for the Discussion Board and admin is used as the entry point for stub programs that call central administration utilities.

Figure 2: Directory Structure for Aerospace Studies 130C Class, Spring '00

Entry Website

This is the where students, faculty and staff would go to find their way to a "term" (see glossary), department, or class, as well as to see examples and get to the TA portal. Every website needs an entry point. Ours looks like this (See UCLA Social Sciences Classes).

Central Programs

These are the PHP templates and Perl CGI scripts and admin utilities that make ClassWeb run.  Only "stub" programs sit in each class directory. They require a central "require" file, which in turn requires the current list of administrative programs and utilities. The stub program calls whatever subroutine is passed as a parameter. If none, it calls the main admin subroutine.

Cron jobs

Cron jobs are programs that run at a specific time daily or hourly to perform support functions for ClassWeb. 

• bbcheckdb.pl - scans all ClassWeb discussion board directories every morning and emails instructors a summary of new postings, if any.
• regcheck.pl - checks every morning for a fresh set of Registrar data in flat files. If it finds them, and their size hasn't changed by more than 10%, it backs up the database, dumps the Registrar tables, dumps them, then loads in the new data. It also calls a program to make sure that each instructor has a ClassWeb admin password and is in the correct class security groups.
• statsdb.pl - goes through each class website twice an hour to determine if a syllabus link exists and to record some other variables for each site. These are stored in the stats table for use in reports and the stats version of the dept classlists.
• hits.pl - runs just before midnight every night to go through web server logs and compile counts of main class page hits for each class.
• reserves.pl - check the UCLA Library Electronic Reserves website daily and parses it for Social Science classes. Those classes that have material on file have an entry added to the reserves table and it shows up as a link on the class website main page.
• faculty_download.pl - downloads the UCLA Campus Directory five days a week.
• dbarchive.pl - makes a complete archive of all MySQL databases on our server every morning. This ensures that special databases for faculty projects get backed up regularly.
• check_class_changes.pl - runs daily to compare yesterday's class counts with today's, to catch classes with changed course or "SRS" numbers (see glossary) and recently added classes.

Security and Authentication

We use three techniques, one of which is UCLA-specific, to limit access to the private and admin sections of class directories.   The UCLA -specific technique allows students to use the same ID and password that they use for telephone registration.  Therefore we don't need to worry about creating passwords for students and TAs. Unfortunately, instructors and staff don't register for classes, so they can't use that same system. 

1. Class private directory (generic password style) - A username/password would be created by instructor and then stored in a .htpasswd file and referenced in the private directory's .htaccess file. This is one of the simplest techniques Apache offers. See this Apache Week Article "Using Authentication."
2. Admin directory - Each class has an admin directory controlled by a .htaccess file similar to the one above, except that no usersnames are specified, only groups. One group for the instructors, one for dept staff, and the third is for central support staff.  Since we tend to set up class websites far enough in advance that the instructor has not always been assigned, it is easier to just rewrite the master groups file with each Registrar download.
3. Class private directory (roster only) - This is a mod_perl script that first does database queries to check if a given ID is a student, TA, instructor, special case or webtech. Then Students and TAs have the password they submitted checked against the UCLA ISIS Authentication Server (via a C Library call). Instructors, special cases and webtechs have their  password compared with one of the .htpasswd files mentioned above.  If the authentication is cancelled, this error screen appears. The Feedback form included there is the quickest way to solve problems and learn about special cases.

File & Directory Rights

The web server ID owns all the files. That way we don't have to deal with UNIX accounts. For the first year, when ClassWeb was all flat files and Perl scripts and I didn't really understand Unix groups, we made almost everything read-writeable by everyone (-rw-rw-rw), just to get it all working. Then, we realized what a security hole that was and we made everything owned by the same ID as the web server and the group "classweb" which included our programmers. 

But then the History Dept decided to start using ClassWeb but wanted to keep their FTP and Telnet control. One of our Unix administrators taught me about Unix groups and we made a separate group for each department with the same members as the "classweb" group, but with that department webtech as well. Now, the setup program assigns the correct group ownership to a class website when it's created. And we use the Unix chmod g+s command to make that group ownership "sticky" for files and directories created underneath.

One gotcha we found was that by default Sun Solaris seems to ignore group membership past the first 20 groups.  This isn't a problem for our dept webtechs because there aren't that many depts. It is a problem when a faculty member wants FTP rights to their class website. We could recompile Solaris changing this to greater than 20, but we werent' sure of the implications of doing that. With thousands of potential instructors and TAs in Social Sciences, that number could potentially be quite large and it might impact performance.  For now, our solution is to give faculty their own Unix webspace if they really want to FTP.  And they  can link to the material they upload there. ClassWeb was designed to save them from learning how to FTP, but if they already know it and want it, they've moved beyond ClassWeb. Which is fine.

Design Flaws

1. Authentication isn't integrated. It's done separately. If you post to the Discussion Board, go in the private directory, or go into the Admin area, you have to re-authenticate yourself each time.  Plan: Create a login screen that pops up whenever authentication is needed and that uses a combination of cookies and cached database entries to "remember" you.

2. The main Administration menu buries Prof and TA info under Main Page Edit.

3. Faculty names can potentially be in three different tables; We first look in profsloc table in case they've updated their info; then the profs table for their entry from the Campus Directory, and finally their lastname and initials from the REGprofs table, in case the only place they show up is in the Registrar download.  The problem is that Campus Directory info is often not suitable for Class website display. If a prof is in two departments, they usually pick one office and phone number to give out.  The way it is now, any entry in profsloc supercedes the other two tables.

4. Crosslisted classes aren't reconciled until AFTER the sites have been set up. We usually base the site in the home dept of the instructor unless that dept doesn't do class websites. Since an email notification goes out with each setup, faculty are often being sent info that soon changes. Also, some get irritated that we don't remember that their class sites are always set up elsewhere.

5. Special case students added to classes and stored in the board_extras table don't show up in the class roster or in the rostermail program. This should be an easy enough fix, but first we have to add an email field to the board_extras table. Another problem is that we should distinguish between private directory access and posting rights.

Notable Errors

• The authentication on the discussion board stopped failing for a month when a new feature upgrade with its own non-local error function superceded the real main discussion board error function. The correct one would exit after an error. The new one gave no message and continued.  This came about because the new feature code was written from a copy of another script and the un-needed error routine was  left in.   Testing should have found it except we only tested the new features not the error case of the existing authentication.

- Mike Franks
UCLA Social Sciences Computing

ClassWeb Open Source Main Page / UCLA Homepage / UCLA Social Sciences Division / Social Sciences Computing

Copyright © 2002 UC Regents and UCLA Social Sciences Computing.
Last updated on September 16^th, 2003.