The tech specs on the Vassar College Catalogue

A technical walk-through of how the college catalogue is set up in our CMS, Cascade Server. It started as a note to another Cascade user, and might be helpful to others. A less Cascade-specific description of how the catalogue is set up is planned.

We just launched our 2010/11 Vassar College Catalogue with a combination of content from Cascade and content in MySQL (fed from the college information system, Banner.) The 2009/10 catalogue was entirely in the CMS. We’re going to look at it for a couple registration cycles to see if we should be pulling everything into the CMS again, which will help with creating other outputs like PDFs. I’ll describe briefly here how both catalogues worked, and am happy to go into more detail later.

There are two parts to the catalogue: front section describing the college (each office and physical resource), and the academic sections where courses are listed. The front section is set up exactly the same in both the 2010/11 and 2009/10 catalogues, so I’ll describe that first.

Front Section

The front section of the catalogue consists of two main headings, which contain a total of 12 sections:

Each section contains multiple subheadings and 1-3 paragraphs each. We’ve broken each of these up into individual pages in Cascade. This allows us to track how often and how much each subsection changes. We’ll also be able to reuse smaller portions of the content in other sites. For example, this is how the Physical Resources section is arranged in the CMS (brackets indicate folders.)

  • Physical Resources
    • Academic Buildings and Facilities
    • Admission
    • The Libraries
    • The Frances Lehman Loeb Art Center
    • Computing and Information Services
    • The Arts and Literatures
    • The Natural and Social Sciences
  • Residential and Social Houses
    • Main Building
    • Residence Houses
    • College Center
    • Campus Dining

In the online catalogue we’ve assembled each of these pieces into one page, as it appears similarly in the print version of the catalogue. However, in the future we hope to rearrange this content into a browsable series of pages with photos and related links.

In all, we’ve split up the main sections of the front sections into 148 pages in Cascade. This may seem unruly, but actually makes it easier to update and track versions of individual portions of content. It also opens the possibility of assigning particular sections of the catalogue to different editors if needed.

Academic Sections in the 2010/11 Vassar College Catalogue

In the 2010/11 catalogue we are utilizing two sources of content: Cascade and MySQL. Each academic section contains a version of the following layout:

  • Contact Information
  • List of Faculty
  • Introduction
  • Requirements
  • Course Listings
    • I. Introductory
    • II. Intermediate
    • III. Advanced
    • Approved Courses

The contact information (name of department, website address), list of faculty, and course listings are all in MySQL and not in Cascade. The contact information is maintained manually. The list of faculty and the course listings are fed daily from Banner.

The introduction, requirements, and approved courses are all pages in the CMS published to MySQL and as HTML include files.

A PHP script checks for all the parts and assembles them into a single page. A PHP script also works out the parts so each section of courses and the requirements can be included on department websites directly. For instance, on each department and program we list the Courses and Major Requirements within that site.

Academic Sections in the 2009/10 Vassar College Catalogue

In the 2009/10 catalogue we had a single hub for the content: Cascade. All the courses were fed into the CMS as one page per course using web services. We started with an XML file of all the sections and course information, and a programmer wrote up a script to port everything into Cascade, creating the folder structure and one page per course. We added pages for the introductory paragraphs, requirements, and approved courses. Again, a PHP script assembled all the pieces into the published page. The source of the XML for the courses was the catalogue InDesign file.

One challenge we ran into was how to get the courses to show up in the correct order. We named each course page with the course number, which could then be sorted alphanumerically. To get the course section headings (i.e., I. Introductory) we needed to make sure the folders in Cascade could sort alphanumerically, as when they are published to MySQL we no longer could sort by folder order. Some of our academic sections had special sections. For instance, this is how Political Science has courses arranged:

  • I. Introductory
  • II. Intermediate
    • A. American Politics
    • B. Comparative Politics
    • C. International Politics
    • D. Political Theory
    • E. Other
  • III. Advanced
    • A. Optional Senior Thesis
    • B. Advanced Courses
    • C. American Politics Seminars
    • D. Comparative Politics Seminars
    • E. International Politics Seminars
    • F. Political Theory Seminars
    • G. Other

To get the folders to show up in the proper order we chose names that could sort in alphabetical order:

  • i-introductory
  • ii-intermediate
  • iia-intermediate-a-american-politics
  • iib-intermediate-b-comparative-politics
  • iic-intermediate-c-international-politics
  • iid-intermediate-d-political-theory
  • iie-intermediate-e-other
  • iii-advanced
  • iiia-advanced-a-optional-senior-thesis
  • iiib-advanced-b-advanced-courses
  • iiic-advanced-c-american-politics-seminars
  • iiid-advanced-d-comparative-politics-seminars
  • iiie-advanced-e-international-politics-seminars
  • iiif-advanced-f-political-theory-seminars
  • iiig-advanced-g-other

Within each folder were one page per course. A PHP script assembled all the pages together.

We kept the folder heirarchy flat to make it easier to write the queries to pull the information from MySQL.

I have to sign off here, but hope to provide future posts into how the catalogue is structured in the CMS, and how we can improve it.