Middlebury

Course Catalog

Contents

About The Project

Course information needs to be easier to browse overall as well as fed dynamically into our new college website. The Course Catalog project will re-envision how course information is accessed online and automate the delivery of information from the central systems (Banner) to a variety of locations within our web presence (department websites, online catalog, search results, faculty pages, course websites, etc).

Course information and descriptions will be contained in a database fed from Banner that can be used to display slices of that information on the departmental sites. This database will contain both information for the current term as well as past and future terms.

Planning for this project began in January 2009. Completion of the first phase of the project is slated to coincide with the launch of the new college website in January 2010.

The result of this project was the development of the Course Catalog application (hosted on GitHub).


People Involved

Primary Team

  • Janis Audet - Academic Affairs
  • Renee Brown - Academic Affairs
  • Bob Cluss - (Dean of Curriculum)
  • Adam Franco - LIS (Web Programming) - Technical lead
  • LeRoy Graham - (College Registrar)
  • Jeff Rehbach - LIS (ETI Area Director) - Project manager

Other contributers

  • Mike Schuster - LIS (Banner)
  • Mike Roy - LIS

Minutes and Meeting Notes

Project Links

Migration of Data to Banner

Course descriptions are currently unstructured text in the MCMS. These will need to be moved into Banner and possibly reformatted.

Non-course specific text information, such as degree requirements and departmental philosophy will remain in the CMS and be linked to from the dynamic course catalog application for reference.

Implementation Steps:

  1. Determine field in Banner most appropriate for storing course description.
  2. Determine format of text and decide whether to use HTML formatting in text blobs for descriptions.
  3. Determine difficulty involved in entering course descriptions into Banner.
    1. If simple, schedule staff time for data migration using INB forms.
    2. If complex, schedule staff time to prepare spreadsheet for import and to write import routine.

Periodic Dump of Banner Data to Read-Only (e.g. MySQL) Database

Implementation Steps:

  1. Determine what Banner data will be exported. Optional in italics.
    1. SCBCRSE: courses
    2. SSBSECT: sections
    3. SIRASGN: instructors
    4. SSRATTR: course attributes (e.g. SCI, PHL, LIT)
    5. SSRMEET: meeting times
    6. STVBLDG: Building Code Validation Table -- Would be useful if we want to print out pretty location names.
    7. STVCIPC: CIP Code Validation Table -- Is this 'programs' (as in departments plus things like ES)? Would be good to have for printing out nice names for cross-listed courses. Bio/ES, etc.
    8. STVCOLL: College Validation Table -- If listing Breadloaf, Monterey, Abroad courses, would be good for printing out location.
    9. STVDEPT: Department Validation table -- Used for printing out nice department names rather than just codes.
    10. STVSCHD: Schedule type validation table -- Nice labels for each of the section types "Lab", "Lecture", "Senior Work", etc.
    11. STVTERM: Term codes -- May be needed to determine which year/semester a section is in.
    12. If we are going to export enrollment information, we  will also need an enrollment table
    13. We will need a table of person information both for listing instructor names as well as for listing student names if exporting enrollment information. This may be a case where it will be easiest to have Mike create a view of just the person information we need and then export that simplified table to our MySQL database. Person information likely needed:
      1. id (or whatever key is used in the section/enrollment tables
      2. name
      3. department
      4. email
      5. extension
      6. office location
      7. type (student, faculty, staff)
    14. If we are going to enable academic advisers to view student choices, we will also need a mapping table between advisers and their students.

For the instructors: name and ID number are found in SPRIDEN (the central identity table), which then relates to tables containing the rest of that information. However, it might be better to get this information from the Active Directory. We can look up individual records in the AD based on PIDM and get all of that information from a single "table". The AD also has Office Hours for all Faculty, which are not contained in Banner. It's a separate DB lookup, but limits the Banner access required for this program and gives us access to a bit more information.

For the students: we would likely want to export enrollment information directly from Banner, but need to keep in mind this can't really be a "live" feed and we'll need a notification on the catalog that enrollment numbers are X number of hours old and a link to SSB to check the live data.

  1. Reproduce Banner table schema for those data in MySQL database.
    1. Will need to meet to determine which of these are required as per step #1
  2. Create PHP script to handle data export and sync.
  3. Set up service on web server to sync data nightly.


Here is the Kenyon Catalog Table Structure for reference and ideas on additional info.


Front End Catalog Application

Implementation Steps (only covers features for first release):

  1. Create front-end search form interface.
  2. Create front-end results display interface.
  3. Create an internal model to abstract the database details away from the HTML forms/display and other future clients (i.e. web-service provider). A possible interface for this model would be the CourseManagement OSID (detailed doc). This model will handle data access queries as well as security/authorization checks to ensure that users only access public, their own, or their advisee's data. This model will include:
    1. Courses (accessible by id)
    2. Course sections (accessible by id)
    3. People (accessible by id) which may be in the role of instructors or students
    4. A course/section search interface. May use a SQL "WHERE" clause or a slight abstraction. Also allow full-text searching using GSA or Lucene.
    5. Bookmarks (accessible by person id)
  4. Create RSS feed of description information to the GSA.
  5. Single Sign On integration.
  6. Create database tables to store user information, including user-to-course bookmarks, etc.
  7. Create "shopping cart" form for users to select courses.
  8. Create per-user report of courses selected.

To Be Determined:

  • What design template will be used for this service, given the likely transition of design as part of the web redo project?
  • Will we import user-to-course information from Banner and sync this with the local user information?
    I image the only local information would be bookmarks, not enrollment info, so there shouldn't be a need for synchronization. -- Adam

Data that will live only with the course catalog and not in Banner:

  • "Favorites" and/or contents of "shopping cart"
  • URLs to course-related web sites, E-Reserves, etc?

Platform

Database Type/Location: MySQL

Language: PHP

We will not need to allocate additional hardware for this. It can run on the production machines for administrative web applications (diesel/fission) or on a dedicated virtual machine. The MySQL database can live on the dedicated MySQL host set up for Segue and other applications (coffer).

Features Needed for First Release

Browse/Search section listings by term, department, requirements, schedule, etc

This would be very similar to the Kenyon interface, but with the following changes:

  • Search based on courses meeting one or more of the distribution and culture requirements.
  • Allow choosing of future or past terms.
  • Link the department name to the department's listing.
  • Link to an "offering" view that will display all sections of the offering.
  • Link to an "instructor" view that will display all sections taught by the instructor.

Questions:

  • Should sections of the same course be grouped together, or listed separately as in the Kenyon catalog?

Browse course listings by department

  • Should be able to browse a listing of "canonical courses" in the repetoir of a department, whether or not there is an offering in the current term/year.
  • Also need to be able to list the "course offerings" for a department by term, as well as the individual sections available.
  • Jason Mittell notes: "supporting cross-listed courses to feed into lists for both departments is really important"

Display information on the course

  • Title
  • Description
  • Prerequisites
  • Distribution requirements the course fulfills

Display information on the course section

  • Title (from course)
  • Description (from course)
  • Additional description for a specific section
  • Prerequisites (from course)
  • Distribution requirements the course fulfills (from course)
  • Instructors
  • Schedule
  • Location


Create RSS feed of courses for importing into GSA for full-text searching

Features Desired for First Release

Log-in accomplished via the new Single Sign On system

Students can bookmark courses

A "shopping cart" or similar controls will allow students to choose courses or sections during their browsing and searching and keep them in a list that is available to them when they log-in.

Bookmarked courses can be displayed as a schedule

This will allow students to see an overview of the week and how the courses they have chosen will line-up. Might be good to highlight overlaps.

In addition to the general "bookmark", it could be useful to have a "my schedule" flag. The workflow in which this could be used is follows:

  1. Student searches through courses by term and department and finds and bookmarks many that they think look intersting.
  2. Student goes to their personal view and sees a listing of all of the courses that they bookmarked.
  3. Student adds 4 of the bookmarked courses' sections to their "schedule" and views a rendered week-calendar with conflicts highlighted.
  4. Student moves sections in and out of their "schedule" until they are satisfied with their choices.
  5. At registration time the student attempts to register for the sections in their "schedule". The other bookmarked courses still available in their list as backups in case a preferred section is filled. This prevents them from having to madly search for interesting, schedule-compatible sections during registration.


If we are also pulling enrollment information from Banner, the overview should have a toggle to show only enrolled courses, only bookmarked/MySchedule courses, or both. This will be helpful for students in working out their schedule during the drop/add period.

'Adviser View' to allow advisers to see students' choices

This will require additional data from Banner about students' adviser assignment so as to properly authorize faculty to only see listings of their advisees. As well, this will keep the listing of advisees short.

Features to Add in Future Expansion

Allow Faculty to see rosters for their courses

Display books for courses

This could include a listing of ISBNs, book citations, and/or links to the bookstore.

Allow browsing of LS, MIIS, Breadloaf, etc courses.

Provide web-service to allow other apps to access course information

Other applications that might wish to access course information:

  • Segue
  • Moodle
  • Personal home page widgets
  • CMS Department sites / Faculty profiles

Integration with Campus Map

  • Dynamic link to map entry for location information in search results
  • Show path to courses

Inclusion of Study Abroad Info


Allow Faculty to add links to course websites, EReserves, other materials

This could replace the current course-websites system and make the catalog the go-to place for all information about a course.

These additional links and information might live outside of Banner in the database that also stores user selections and other info.

Allow searching for courses with a filter for "doesn't conflict with bookmarked"

This feature would allow students to select several courses and then do a search for courses that do not have scheduling conflicts with their current choices. Often finding a 4th class that fits in with one's schedule can be a challenge. This search filter could aid that process.

Course information in the main website (Drupal)

'Online Course Catalog'

A 'Course Catalog' will be available in the main website that combines static content (major and program descriptions, general information) with dynamic listings of courses.

Department course listings

Department sub-sites will include the static and dynamic content of the online 'Course Catalog', filtered for only showing results from their department. These listings may be formatted differently than the Course Catalog part of the site if appropriate.

Faculty pages

Faculty pages will include a dynamic listing of the courses taught by a particular faculty member.

Search Results

Courses or sections matching search criteria will be displayed on a new search results page that also includes web-page results and directory results.

Powered by MediaWiki