How to publish your university catalog and class schedules online using the Cascade Server CMS

faculty bio sketchOver the last 2 years, Emory College has used Cascade Server to publish our academic catalog and semester class schedules to the web. Learn the trials, tribulations, and successes we've encountered along the way with data definitions, indexing, and web services.

Updates: Latest versions of Faculty bio code in August. Notes on further indexing-related changes and print-version styles explained via comment in April. Data definitions and stylesheets in February.

This presentation was given by Adelle Frank and Brian Williams at the Cascade Server User Conference, in Atlanta, GA on September 13, 2010. You can also view this presentation on Slideshare and watch the video at Hannon Hill.

A. Where we started

  • Catalog: Quickly-outdated print/PDF versions
  • Class schedules: in a quickly-outdated print format or in scattered, non-standard HTML pages on non-centralized departmental websites

B. Why we put our Catalog & Class Schedules online

C. Big dreams

  • Centralization. It will be possible to search, edit, and analyze one location.
  • Connected, share-able data model. Data should not need to be repeated, but should be linked to (i.e. shared) so that it can be maintained only once, but be up to date everywhere.
  • Consistency & quality control. The ability to use the same content in multiple places, but with the same fields, creates a more consistent experience for users and encourages quality control by distributed users.
  • Archiving. Create a CD copy of the catalog for non-internet-connected or IP-blocked users and archive both catalog and class schedules with the library in a static HTML format.
  • Content editing. Content should be easy to maintain and editable by numerous content owners.

D. Obstacles we already knew about

  • No authoritative feed from PeopleSoft database, only manual .CSV downloads and uploads.
  • Steep web services learning curve.
  • Catalog & website have intermingled content, so linking & archiving must be carefully planned.
  • Few standard structures exist for data, so need to create content type structures.
  • Standard naming & paths are needed to enable both Web services creates & easy XSL styling.
  • Limited resources & time (1 year!)
  • Manual data entry of catalog information (Thank you administrative assistants & student workers!!)
  • Initial lack of editor training materials, which would be key to a successful adoption of this new system.

E. Obstacles we found out about

  • Asset-render-depth in connected data definitions can lead to infinite loops.
  • Index block settings & render time: content type for choosing specific blocks & automated block creation
  • Weird data quirks:  Interdisciplinary classes; Faculty married vs. professional names; class schedules for multiple times, locations, instructors
  • User needs: rollover data from semester to semester for class schedules, so don’t have to re-type.
  • Web services + large publish jobs = SLOWNESS for all
  • Variable” is really a CONSTANT in XSL (Muenchian grouping SAVES LIVES!)
  • Hidden fields not so hidden. Can’t make forms user-friendly.
  • Users find it un-intuitive to upload a file/image BEFORE they can include it on a page; BUT we want control over parent folder placement.
  • Don’t move or re-name data definition fields OR ELSE … lose data & must re-write web services scripts
  • Permissions: granularity is challenging
  • Index metadata ONLY (not page XML inline), for detailed, numerous content.
  • Use a workflow for large folders to auto publish only pages that are changed, rather than slowing down the system by publishing all 1,800 class section pages every night, regardless of whether they've changed.

F. Where we are now

  • Catalog online in a Site using version 6.7 at
  • 5 Semesters of class schedules up in Cascade at (as of February 2011).
  • Sharing course descriptions, class schedules, and faculty bios into Departments that are in Cascade (already seeing quality payback, as departments are noticing errors in catalog data because it lives on their site, too).
  • Saving beaucoup $$$ with online-only catalog and class schedules.
  • Lost main Communications and content coordinator (!), quality checks are not occurring in as organized a fashion.
  • After just 1 semester of use, we got a really positive response to the online catalog and class schedules from students, faculty and staff.
  • No longer use paper publications, just mail out a postcard with the catalog URL or, for non-internet audience or IP-blocked Chinese students, a CD-ROM (using a separate, manually-activated Page Configuration & Publish Set).
  • Analytics easier, since all content is in one location.

G. Potential future plans

  • Change the way we do class schedules:
    • use a feed from Peoplesoft
    • Rollover default textbooks/descriptions
  • Archive catalog and class schedule versions with Library in a digital format (HTML or PDF/A).
  • Improve searching after College site is re-designed, as the redesign has now addressed the need for easier navigation.
  • Refine content types
    • Department (brevity)
    • Major/Minor (more structured)
    • Faculty (additional XSL for display; pull in faculty publications feed from annual reporting software)
    • Scholarships (create structure)
  • Create XSL transports to PDF or Word, for easier printing.
  • Create more training (videos & documentation) for end users, especially re: HTML.
  • Share
    • class section pages on Faculty and course description pages.
    • majors/minors with Departmental web sites in Cascade.
  • Hire person to update catalog content (and have them document how its done, both technically and in terms of business process/deadlines).
  • Create web services scripts to automate provisioning of Departmental websites with College-specific additions.
  • Consider imitating functionality in Cal State's catalog at: for majors and minors.

H. Main take-aways

  • Choose a dedicated person (or persons) to update and quality-check your content.
  • Prioritize which content you’ll structure first (since you can’t do it all).
  • Consider frequency of updates in whether a data-heavy project should go into Cascade or not.
  • Consider usability for editors when designing workflows, data definition field order, & training.
  • Be wary of indexing, metadata, recursion and overwhelmed publish queue issues.
  • Plan your naming & organization schemes in the BEGINNING (and be consistent).
  • Invest in acquiring web services and XSL coding skills.
  • Get to know your data (& data owners) in the BEGINNING.
  • Attend to critiques of online catalogs at

I. Building & coding details

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

1. Data model

The purple lines indicate current connections or links between content types.

The red lines indicate possible future links between content types that might be helpful to end users.

Data model sketch


2. Course descriptionscourse descriptions

3. Majors & minors

major and minors

4. Faculty page

faculty bio page

5. Department page

department page in catalog

6. Class section schedule

semester class schedules

7. Department web site

website of a department

8. Web services

web services icon

J. Video of Presentation


K. For More Information



Adelle Frank

Different XSL for Archival Copy/Print

We also realized that the Archival copy of the catalog, destined partially for a printable PDF, didn't need 1,400 pages of faculty bios. Instead, we created a separate XSL to display a list of all faculty with only essential information such as:

  • name
  • title & department
  • education.

Likewise, instead of 2,500 individual course descriptions, we created an XSL to create lists of all courses for an individual subject.

Adelle Frank

Removing asset links to department pages & moving data fields

The indexing problem we mentioned got even bigger for us whenever we tried to index the department pages inline.  To address this we made the following changes:

  • Removed asset links to deparment pages for the other types of content (especially faculty).
  • Created metadata dropdown fields with the system-name and display-name of all our department pages for those other content types.
  • Moved more data into metadata and the data definitions for the core content types (course descriptions, faculty bios, major/minors), so that index blocks of these content types would generate appropriate lists for the department pages.
  • Example: by moving department system name as well as rank and title into the faculty bio metadata, we could index faculty pages to create the different categories of faculty on the department pages, rather than having to edit both the faculty bio page and the department page when rank or department affiliation changed.

Adelle Frank

Feedback during Q&A session at Conference

A number of y'all had BRILLIANT things to ask and share during the Question and Answer time after our presentation.  Thanks!

Here is a selection of the things I can remember:

  • Catalog
    • There are legal issues with SACS accreditation re: archiving and substantive changes to electronic editions.
    • One college keeps an “errata” list of all changes made to catalog.
    • Adobe Pro has a "Create PDF from webpage" option that will turn an entire website (such as the one we publish for our catalog) into a PDF.
    • Zmags will turn PDFs into a flash publication/magazine.
  • Class schedules
    • You can use Cascade’s Database Publish function to push data into MySQL database, and then use ASP/PHP for interactive applications.
    • Another school uses PeopleSoft Messaging to get class data out of PeopleSoft.
  • Faculty bios
    • You can tie annual reporting database to faculty bios, so they are kept updated.
    • Cornell created VIVO for connecting faculty in fun & productive ways across disciplinary lines.