Content Management Project Needs

Occidental College

College Catalog
The process of updating the college catalog each year is a cumbersome one and goes something like this:

• The Registrar's office sends out to each department on campus (via campus mail) a hard copy of last year's catalog content. Each department reviews the hard copy, marks changes and provides new content and then sends the updates (via campus mail or sometimes via email attachment) back to the registrar's office.
• The updated content is then sent to an outside contractor who produces a Quark file with the updated content. A hard copy is produced (again), this is sent out to the various departments for review and approval. This may happen two or three times until the content is correct.
• The Registrar's office reviews the changes at each step along the process and must be able to do. The reasons for this are, besides proofing for typos and other errors, they verify the accuracy of the changes (i.e. official policies are not changed, courses which have not be approved are not added, etc...).
• A final proof reading is done. The outside contractor produces the final Quark file which is then provided to the printer and which is also used to create a version of the final catalog in the form a Word document.

This Word document is then used to create the web version of the catalog. This is done by hand: each section is created by cutting and pasting form the Word document into the corresponding webpage. All links must be recreated each year: e.g. references to other parts of the web document ("see the section on...") and all anchored/bookmarked which link to each course description. The entire process can take up to a week to accomplish.

An effective Content Management System would have to address, it is hoped, the following issues:

1. Better management of data.
   The data takes many forms during the entire process and is typed-in and re-typed-in at several points. Likewise, the data is often cut and pasted from one form to another, this can result in errors and discrepancies between version of the catalog (i.e. the printed version and the web version). Any effective system would have to have one central source for the data (a database (thank you, thank you very much!)) and would be able to output the data in multiple forms (XML).
   
2. Approval Process
   The process would have to allow for easy approval of content several stages in the process.
   
3. Ease of Data Entry
   Any editor or interface (whether web-based or in another form) would have to be easy to access and easy to use.

Reed College

1) Catalog (and other publications) on the Web

The current process of developing and editing the catalog copy, and publishing it to the web, is cumbersome and error-prone. The registrar and publications office engage in a multi-step editorial process to receive, edit and publish catalog content. After extensive editing in Word, the catalog is laid out in Quark. At the point the catalog goes to the printer it is also delivered to the web department for publishing on the web. Given the option of the Quark or Word version, we have found it easier to create the website from the Word files. The resulting site contains 55 web pages. There are several important features of this process:

• The faculty and other departments provide content.
• The registrar exercises editorial control over the content to ensure course information is approprite and accurate. When new copy is submitted, the registrar must be able to tell what has been changed.
• The publications department exercises editorial control to ensure grammatical and stylistic consistency. Spell checking, global search & replace, foreign languages, and support for other special characters are required.
• The faculty and other departments approve the final edited content.
• The publications department needs to use a sophisticated publishing program (like Quark), to obtain the print results they desire. For example, the pages are printed in signatures, rather than linear pages.
• Academic department pages contain an anchor for every course number so external applications can link to the course description.

We propose to create new processes and technologies to facilitate catalog production. There should be one authoritative data source that can be used to create both print and web versions of the catalog, while remaining sensitive to the editorial requirements of various dearpments. In addition, we would like to enable web-based catalog submissions from faculty and other departments. Certain catalog content such as course descriptions, faculty lists, and degree requirements, also needs to appear in other web pages. Ultimately we hope that these processes can be applied to other publications such as the faculty handook, stuent guidebook, governance documents, and technical support materials.

2) Department Web Pages

Department web pages are notoriously difficult to keep up to date. Academic departments, with their ever-changing membersip, are particularly troublesome. Efforts to enable distributed maintenance of academic department pages have been spotty at best and distract faculty from developing their course web pages. Much of the content that appears on department pages - faculty lists, course descriptions, degree requirements, thesis titles - exists in other forms, though those forms may be difficult to use on the web. We would like to develop a content mangaement system that enables us to capture data from other sources, or enable simple web-based submissions, and readily publish it to departmental web pages. Further, we would like to publish this information in a way that enables departments to have an individual look and feel, though basic organizational uniformity may be required.

Swarthmore College

STATEMENT OF PROBLEM: Swarthmore has distributed responsiblity for all aspects of departmental websites to each academic department and most administrative departments. As a result, the College's web site suffers from inadequate and out-dated content at the levels of its institutional site below the College's centrally administered pages. Many of our departments would resist any attempts to institutionally template departmental pages, yet few have the resources to maintain their sites with current information. There is an unmet need to provide forms-based, database-driven content management modules that can be used as components to build departmental sites without fixing the aesthetic elements of the pages themselves. Such modules need to be easy enough to use that relatively novice computer users can update data on their web pages without having to directly alter any HTML documents.

PROPOSED: We would like to create or modify several stand-alone modules that departments could select to use on their web sites individually. Each would allow for the easy management of a fundamental content area common to College departments. Examples might include:

1) Department directory (room numbers, phone, email, etc. Pictures optional?)

2) Department calendar (lectures, administrative due dates, events)

3) Announcements/News (posting of articles or shorter announcements)

4) External Links

This is less of an issue for Swarthmore, but other schools might also want to have:

5) Existing course information. (This may be covered under another project heading.)

RELATED WORK: Swarthmore ITS has already developed a form-based news/announcements application that we routinely use for our own department's web site. [See <http://www.swarthmore.edu/its>. Note that there is also a backend system for managing the workflow of newly submitted articles through the revision and publication process.] With some modificiations, this could serve as a basis for a news system. We already have a program on campus (IT Associates) that is effectie at helping departments develop the design of their pages. If we can make these tools a part of our standard toolbox, we can help departments to incorporate them into their sites. This would enable many Administrative Assistants and other staff at the College to keep their site content fresh.

Vassar College

1) Catalog

Our current course catalog is evolves during the year, then is reborn anew each year. The process involves the following steps: The registrar and dean of the faculty co-own the document and college relations publishes the print and web versions. Any official changes must be approved by the faculty curriculum committee and dean of the faculty. My interpretation of this annual divergence and convergence is that last year's catalog belongs to and is updated by the Registrar, and the next version is owned by and updated by the Dean of the Faculty.

The registrar receives committee-approved changes throughout the year from the curriculum committee and passes changes to the college relations office for updating the web. In effect, the web version becomes the source.

The document is maintained as a PageMaker file by an off-campus typesetter. The "source" PageMaker document doesn't get updated at Vassar. College Relations has a copy and generates a PDF version and web version from it. This year college relations exported the PageMaker file to a database so the on-line version is fed from a database (actually, the database generates static pages which are posted). The web version, which contains changes, is printed and sent to each dept to propose updates. Faculty departments make proposed changes to the catalog *on paper* or electronically. In the future, submissions may be required to be electronic. The electronic version is *printed* and sent to the typesetter along with the other paper-only submissions.

Then the proofreading begins. The typesetter returns proofs which are proofread, returned, corrected, returned for approval, re-proofread, re-resubmitted for typesetting, and printing. Then the process begins anew with the PageMaker document returning to Vassar.

Adding to the complexity, the catalog is really two documents. The course descriptions are a major portion but just as important is the section on each department which contains a list of faculty, department description, majors' requirements, etc.The proposed solution is to have an authoritative source with version control (we have to maintain copies of old catalogs since major requirements do not change for an individual). This would be a single-source for all versions (print, web, wireless pda....) A built-in work-flow/approval process would be needed to allow on-line submission of changes and subsequent approval prior to committing changes.

2) Department web pages:

Vassar has discovered that a distributed model for department page maintenance doesn't work in our environment. Therefore, we have a member of the College Relations web development team designated as a centralized maintainer. She has designed several processes to make the process easier and during the school year has student help. Even so, the updating process is more than what a single person can oversee. And we keep adding pages to be maintained. Much of the information that changes most frequently is fairly consistent from department to department (e.g. faculty names, and contact info, course offerings, etc.), must be provided by the departments themselves which lends itself to a self-serve updating process if one could be designed to be user-friendly and require little technical knowledge.

The proposed solution would be online forms which update a central database with certain commonly used pieces of information on departments and individuals. This database would be used to dynamically insert relevant data into web pages. Note: we don't use templates so the system would need to be accessible from any web page (which might raise security concerns and require security precautions). The information could be re-purposed for directories, the course catalog, etc. Again, a work-flow would be needed for approvals and versioning.

3) Documentation

Technical support documentation is hard to create and just as hard to keep up to date. And we have to provide it in multiple formats. We are currently creating user documentation in MS Word so we can print it. For web delivery, we convert the Word file to PDF. PDF is poorly suited to this task. When someone logs in via modem to find out how to configure an email client, a 15 minute download is inappropriate. And in several cases the recipient will not be able to view the document when the download finally finishes. We need a single source solution for creating, maintaining, and updating such materials. As above, this could be accomplished with a web-based database with versioning and approvals.