Sonja M. Froyen

We've long discussed basing the programs area of the website on a content management system. Now we have the technology, expertise and time to make it happen.

But what do we mean exactly? We've always had FileMaker databases to organize and report on programs, tracks and students. Soon we'll move to Peoplesoft which is even more exacting. The website grew up informed by these systems but never tied to them. It's evolved organically and adopted it's own organizing element: the minisite.

Sometimes a program, sometimes a track, the minisite reflects the natural definition of an experience abroad. It's how we package and promote our products to students.

Which organizing principle should be the backbone of our content management system? Peoplesoft or Minisite?

Option 1: Program in Peoplesoft = Program in FileMaker = Program on Website

We base the programs portion of our website on the relationships among sponsors > programs > tracks > and terms as laid out in Peoplesoft. Our local FileMaker database will be populated with regular data dumps from Peoplesoft. Additional fields in FileMaker will hold descriptions and images which will be pushed to the web.

Cons:

• It's a big shift with the tough work on the front end. Someone (Programmers? Marketing?) needs to untangle the content on the minisites and apply it to the appropriate program or track. New content needs to be written. Duplicate content needs to be edited.


• Not all programs conform to the model. Some programs are really collections of tracks with uninspiring names like A, B, or C. Other "programs" are really tracks with enough critical mass to stand on their own. How do we present information to the public in a way that doesn't belabor the entity relationships required by database?


• We need to change the way we talk about our programs both internally and with students. Perhaps adopt a vocabulary and be consistent when referring to programs, tracks and terms.

• It's consistent, predictable and easier for the outsider to apprehend.


• It works well for searching, arraying results and making comparisons among programs.


• It's inevitable. The vernacular of Peoplesoft will spread to our internal organization and influence the way we talk about programs. Eventually, if not based on the Peoplesoft model, the website will feel out of step.


• It's efficient and accurate. A single input can be leveraged across multiple systems which will always be in sync.

Because Peoplesoft won't do all the tracking our office requires, we still need a local apparatus that mirrors and augments Peoplesoft. Just as in Option 1, we'll have a local FileMaker database populated with regular data dumps from Peoplesoft. But this data won't go on to power the website. Instead, we'll build a separate Minisites database to store long descriptions and images. Where possible, we'll leverage data entered in other systems but it will likely require re-keying.

Cons:

• Updating will mean keying the same information into multiple systems plus we run the risk of inconsistencies among the three systems.


• We commit ourselves to a system that requires more staff time to maintain and don't set ourselves up for future efficiencies.

• Content is already done. We just harvest the text and images from the current website and dump it in the database.