Picker Overview

Deciding what to load (mainly browse.js, which is about 200 lines excluding spaces and comments)

Functions in browse.js decide which courses to load.

1. It reads the courses selected in the intro screen.
2. It finds the classes the user has previously selected, and loads their courses. a. Some of these classes are stored in a cookie (duration two weeks). b. Others are stored by MySQL and are linked to the user's kerberos ID. To get the courses stored on the server, a file called user.php runs; it returns both stored classes and stored class ratings from all users.

After deciding which courses to load, it picks which URL's and files need to be loaded. These are mainly coursews files. The static files are textbook data for each course, which we don't have for the new courses, and HKN and TQE data for Course 6.

I reworked a lot of this code over the summer; it's now about as simple-looking as it can be, although I didn't optimize it for speed. While loading this data, a function calls several other functions, like enableMiniTimegrid, to set up the rest of Picker.

Logging In (also mainly in browse.js, working with a couple PHP files.)

Users can log in with their Athena ID's by clicking a button. When they log in, everything reloads, this time using user data from MySQL. Picked classes from MySQL (classes the user picked a long time ago or on a different computer) are committed to a cookie. Cookie data is stored in MySQL when the user logs out.

It is also possible for a developer with a LAMP server testing Picker on localhost to log in. This doesn't use certificates but otherwise works the same way.

Loading and Processing Data (mostly in scripts/load-and-process.js, ~150 lines without comments and blank lines)

Each URL to be loaded is passed to Exhibit.importers["application/jsonp"].load, which loads the data and then calls the function processOfficialData to modify the data. This is for the data that comes from the coursews JSON feed. A parameter individualClasses (set to null or an array of classes) tells whether it is trying to load a whole course or individual classes.

In processOfficialData: If individualClasses is null(loading a whole course), processOfficialDataItem is called for each item (class) in the JSON object.

Special case: If the item is cross-listed and it is not its own master class, it is renamed to the name if its master class and most of its data is removed. Then its master class is added to a list of classes to load. The master are loaded after processing all data from the current course. This is because when several items are the same cross-listed class, only the master item has some important information. For example, say I try to load all Course 18 classes. 18.062 doesn't have information about recitations. It is renamed 6.042 and most of the data it does have (like prereqs) is removed. Then I load 6.042. The result is that these items merge into one, and its “course” attribute is [“6”, “18”]. This process is sort of messy and is new.

If individualClasses is not null, processOfficialData removes every item except items listed in

individualClasses and their sections from the json object, and calls processOfficialDataItem for the non-removed items.

processOfficialDataItem modifies a course's data, mostly to make it prettier. For example, prereqs show up as English instead of an array: “1.121, 14.122, or 15.416J”. Clicking on a prereq or a “credit cannot also be received for” class causes a popup of the class to appear.

Each static file is loaded using jQuery.

Timegrid (scripts/timegrid.js)

enableMiniTimegrid takes picked sections from Exhibit and creates a Timegrid. (10 lines)

Schedule (mostly in panel-switching.js, 30 lines)

When you click on “Full View”, above the Timegrid, it shows a big, printable calendar. The functions in panel-switching.js manage this.

Picking Sections (mostly in section-picking.js, ~60 lines)

These functions deal with picking sections. When a section is picked it is stored in an Exhibit database. SimileAjax.History.addLengthyAction is again used so that forward and back buttons can do and undo actions. Mousing over a section or clicking on it makes it appear in the Timegrid.

More Setup

enableClassList synchronizes picking classes and updating “picked-sections” in the Exhibit database, and creates the “pre-register these classes” button. (~40 lines).

submitBooksQuery sets up the url that clicking the Bookspicker button takes you to (~15 lines).

Stored Data

There are three places data is stored: In an Exhibit database, in cookies, and in the MySQL database. Functions in stored data deal with updating data from one of these sources to another, like updateStoredDataFromExhibit, and with accessing and storing this information, such as writeCookie and readCookie. ~60 lines that I wrote over the summer to replace a messier data storage system.

Unit Adder (~40 lines, scripts/unit-adder.js)

Adds up units and reported hours on picked classes, and sets up the HTML that displays this information.

scripts/user-data.js (~120 sparse lines)

Functionality for users to make comments, see comments, and click on stars.

Miscellany

scripts/browse.js:

Functions for loading one course or one class. (~15 lines)

Functions that set up Add More Courses drop-down menu. (~30 lines)

Function that makes it so that when you click on the name of a prereq, information about it appears as a popup. (~2 lines)

scripts/config.js:

Has data about courses. Also sets up colors for time grid. ~200 sparse lines.

Room for Improvement

Updated HKN data.

Storing favorites (starred classes) – They should at least be stored in a cookie so that they're not lost upon refreshing, and probably stored on the server.

Possibly Useless Things

possiblyLog

“New logging code to study facet interaction . Hooks into the proper logging facilities in the SimileAjax package if present (at time of writing this, not yet baked into the "official" trunk) 8/27/10” This sounds useful but I don't think it is doing anything. It uses SimileAjax.RemoteLog.possiblyLog.

(Update: Ask Ted Benson, eob@csail.mit.edu, about this if you are interested.)

Course ratings

Only logged-in users can rate courses, although anyone can see ratings. Ratings are stored in the MySQL database. Almost no classes have ratings... I don't know if this is because having to log in is a barrier, or if they just don't care. Obviously using official course evaluation data would be better.

Logging in

I seem to remember that there are only about 300 users in the database, meaning that only 300 MIT students have ever bothered to hit the “login” button. People might not know that logging in exists and is useful. It could be made automatic, although I'm not sure if that would still allow people without certificates to access the site.