Recently in Lib Ed Category

The Backend

All this is stored in a FileMaker database. Emily can use this interface to oversee, override or edit entries.

What the Evaluator Sees

This is what the evaluator in the Office of Admissions sees:

What The Submitter Sees

Here are a series of screen shots showing what a student who submits a course for approval will see:

Internet Explorer 6 is troubled by unsecured data on a page. While other browsers give gentle warnings, IE6 tosses up a dialog box before every, single page. You can't dismiss it for the site or session. This was a real problem for the Liberal Education web application. Our colleague in Admissions couldn't process approvals efficiently. The fix was:

  • reroute links from "" to the secure path to the same content.
  • remove the jquery link "<script src=""
  • remove the Google font "<link href='"

Lib Ed: Close-Out

We held a close-out meeting for LAC's Liberal Ed Database project. In attendance were Christopher, Emily, Kim and Sarah. Let us first congratulate ourselves for completing a project that languished at the bottom of the priority pile for two years.

The Statement of Work, dated Aug 2008, sounds quaint as it worries over learning PHP, configuring servers, and following project management protocols. That these practices are second nature to us serves to demonstrate how far we've come in a short span.

Remarkable is how little the scope changed. Sure, we switched up how to accommodate old and new requirements, but the core of the project remained the same. This is a testament to the business process owners who thoroughly understood their needs and the system required to meet them.

As we scored ourselves against the Statement of Work, a few fails jumped out:

  • A significant piece of scope was dropped surreptitiously and without documentation. That the project didn't suffer without it is beside the point. I should have brought it to the attention of the stakeholders and given them an opportunity to make an informed decision.
  • A new stakeholder joined the project mid-stride. I could have done a better job bringing her up to speed, providing her a copy of the Statement of Work, and prepped her on the project management process.
  • We omitted an important constituency — advisers — from the testing and training phase. When the system went live they sent waves of feedback. We should have addressed their concerns earlier in the process and leveraged their buy-in for the launch.

The Timeline

I'm not sure what to learn from the timeline. Here's what we know:

  1. Changes to to Lib Eds hadn't completely settled out when we started the project. We actually benefitted from delays. In the end we built a system that serves the new requirements, not the old, and not some blending of the two.
  2. Other projects were given priority over this one and rightly so.
  3. Both LAC and IT underwent significant staff changes. Terry left. I jumped from contract to contract to perm. Both Christopher and I moved from LAC to OIP. Sarah was gobbled up by Peoplesoft. Emily stepped up. Kim was dropped in medias res.


The blog took getting used to but worked well for communication and documentation. And how slick was that? To simply send a link to another institution interested in replicating our work.


I spent 100 hours from Feb 5, 2009 to June 23, 2010.

Lib Ed: Wind Down

Woo Hoo! Lib Ed is live! Awww, but wait, there's more...

Pending Courses from Old Database

We still need to close the loop on courses pending in the old database. There's a lot of junk but on the chance there are valid submissions waiting to be acted upon, we should carefully scrub it. I've suggested a strategy.


I will schedule a training session with Emily (anyone else want in?) where we'll review the back-end database. At the conclusion of training, we symbolically "turn over the keys" to LAC, who from then on is responsible for training new users and managing the solution day-to-day.


We met with and trained the evaluator last week. She suggested several enhancements to the solution. We went live without incorporating them because to do so would have delayed our release and we need time to consider them. The suggestions are list below. If you want to incorporate them, we'll open a new project.

  • Add file upload capability so students can attach documentation
  • Add a way for the evaluator to recognize a re-submission following a request for more information
  • Collect the students EmplID
  • Add fields for resident or transfer credits
  • Add fields for local or external sponsor
  • Add rollovers or pop-ups that explain fields, processes or policies
  • Add fields to learn if the student has taken the course already
  • Add another field or change the label on an existing field in order to get the department in addition to the course number
  • Clarify what URL the student should provide (link to department or specific course)
  • Add field to collect term (spring, fall, winter)

When to Stop

I don't know enough about the subject matter to tell for sure, but I wonder if these enhancements extend our solution too far into the Office of Admissions. I don't advocate slamming the door as soon as it acheives our objectives. I want to dovetail with their systems or processes so there's a nice hand-off, making it easy and seamless for both staff and students. Perhaps there's a query, a feed, a printout, an automatic e-mail that achieves this.

I'm wary, however, that additional fields detract from the primary purpose of the solution; confuse the student by encouraging improper procedure; or create a back-door to Admissions that runs through the LAC. Another concern is the time required of IT staff to implement changes and provide on-going support. While we understand and endorse the concept of greater good, we are primarily responsible to OIP.


How's this for a timeline? Have I got all the critical steps?

Date Task
April 27 Train MG
April 27 - May 7 Allow MG to practice
May 3-14 Test new site
Present -May 7 Populate new database with courses approved under the new requirements
May 17-21 Make final changes based on feedback from MG and the testers
May 17-21 Prepare draft of new page with links to both old and new databases
Sometime between May 24 and 28 Implementation: shut down current site; redirect "submit a course for approval" link in old site; make old and new databases live
? Shut down old database completely and update site to remove reference

Data Conversion

I think we all agree on this:

  • The new database will be seeded with courses approved under the new requirements. This is the work Jessica is doing. The chart above gives her until May 7th to complete the work.
  • The old database will hang around until it's phased out; date to be determined.
  • Until then, the old database will be online as is. Students will be able to search courses approved under the old requirements.

We just have to figure out what to do with the ~170 courses in the old database with status "Pending" or "Need More Information." I propose the following:

  • Move courses with academic year 2010-2011 or greater to the new database for processing under the new requirements. Send the original submitter an e-mail explaining the shift and give them a link to their submission in the new site.
  • Clean up courses, marking many of them "Approved" (See Sarah's April 21 e-mail).
  • Leave the rest in the old database to be processed under the old requirements and work aggressively with MG to resolve every last course.

Lib Ed: Progress Report

| 1 Comment
Yet seem'd it winter still, and, you away,
As with your shadow I with these did play:

Test the Website

I will place a note on the Water Cooler asking LACers to test the site while I'm gone.

Build List of Approved Courses

Emily has a provisional database in which to enter courses already approved under the new requirements. She's going to enter a few herself then perhaps turn it over to her student worker to complete.

Lib Ed: Progress Report

| 1 Comment

Wow, the last time I worked on this project was July 10, 2009. It's back on the schedule for April 15th, which should be just enough time to:

  • review the wireframes we sketched
  • review the pages we coded
  • finish coding pages
  • scrub data and populate the database
  • incorporate the CAH (Central Authentication Hub)
  • make it live

Sarah asks,

Would there be a way to import data about new courses into the new database if we are collecting it in another format now?

I'm near certain the answer is Yes. Let's make data migration one of our first to-dos once we begin working in earnest. And when will that be? I've got two projects that sunset this week which should clear my schedule to dive back into Lib Ed.

Admin Interface


The user must authenticate and be on a short list of x500 IDs (maintained in a PHP array in the header) in order to land on any page in this series.

  1. All the info about a course is searchable. The search does not separate courses by new and old requirements.
  2. The results page displays matching courses with links to a corresponding...
  3. Detail page which displays all the info about the course. There's also a link to...
  4. Edit the information. The user will be able to edit any value including old requirements and new requirements. No validations or transformations are performed on the data. It's assumed anyone with Admin-level access knows what she's doing.
  5. The user gets a confirmation page with a link back to the search page (#1).

Student Response

  1. The submitter receives an email indicating action has been taken on the course she submitted for review. She clicks the link in the email, or
  2. She clicks a link in the list of courses she's submitted.
  3. In either case, she lands on a detail page displaying the info she submitted and the action taken by the reviewer.
  4. If the reviewer requested more information, the same fields are editable as when she first submitted the course and again, she has the option to submit for review or save for later.
  5. The user gets a confirmation message appropriate to whether she saved or submitted. Also on this page are links to likely next steps, including #2.
  6. If the user submits for approval, she gets a confirmation email.
  7. If the user submits for approval, an email alert is sent to the reviewer.

The Review Process

  1. The reviewer gets an email when a course is submitted for review. She clicks the link in the email, or...
  2. She clicks a link from her bookmarked page of courses pending review.
  3. In either case, she lands on a detail page displaying all the info submitted about the course. The only editable fields are:
    • Core Requirement: Select one of the following:
      • Biological Science with Lab
      • Physical Science with Lab
      • Historical Perspectives
      • Social Sciences
      • Literature
      • Arts & Humanities
      • Mathematical Thinking
    • Theme Requirement: Select one of the following:
      • Civic Life and Ethics
      • Diversity and Social Justice in the United States
      • Global Perspectives
      • Environment
      • Technology and Society
    • Writing Intensive: A single checkbox labeled "Yes"
    • Notes to the submitter: Optional
    • Notes for internal use: Optional
    • Notes for the public: Optional
    • Status: Required, select one of the following:
  4. Approve: Must have selected a core or a theme or checked writing intensive.
  5. Deny: Course is not approved.
  6. Cancel: When no other status applies. Might be used when it's clearly a duplicate for bogus entry.
  7. Exception: Approved for this instance but the course will not be among the results when searching for approved courses.
  8. Do Nothing: No action performed on the record. The course stays in the list of courses pending review.
  9. Need More Information: Ideally, the reviewer uses the Notes to submitter field to indicate what information is needed.
  10. The reviewer gets a confirmation message and a link back to the list of pending courses (#2).
  11. Unless the status is Do Nothing or Cancel, an email is sent to the submitter informing her of the action taken. If there's a value in the Notes to submitter field, that value is included in the email.

Submit a Course for Approval

Submit a course for review process flow
  1. Let's say the user doesn't find a course among the approved courses so she submits a course for approval. She authenticates before landing this page. Fields on this page include:
    • First Name: Required, auto-populated
    • Last Name: Required, auto-populated
    • Email: Required, auto-populated, valid format
    • Course Title: Required
    • Program City: Required, pop-up list of cities from Peoplesoft plus "Varies"
    • Program Country: Required, pop-up list of countries from Peoplesoft plus "Varies"
    • Sponsor: Required, pop-up list of sponsors from Peoplesoft plus "Varies"
    • Institution Abroad: Pop-up list of institutions from Peoplesoft?
    • Course Description: Required, transformed to sentence case on input
    • Course Number:
    • Course URL: valid format
    • Academic Year: Required, pop-up list of academic years going forward and back several years; a sensible default value
    • Notes:
  2. The application runs validations, transformations and creates a record in the database.
  3. Because the form is strict, the user is allowed to save her course for submission at a later time. The application skips any validations and transformations and creates a record in the database.
  4. The user gets a confirmation message appropriate to whether she saved or submitted. Also on this page are links to likely next steps, including #5.
  5. A list of all courses a user has submitted and their current status.
  6. If the user submits for approval, she gets a confirmation email.
  7. If the user submits for approval, an email alert is sent to the reviewer.


Search for courses process flow
  1. The main index page is a search page. Users do not need to authenticate in order to do a search. Users choose between two pools of courses - those approved under the old requirements and those approved under the new requirements. The page will have a link to information describing the difference.
  2. The results page displays matching courses approved under the new requirements or under the old requirements — not both! Basic info about the course will be displayed in a list with a link to a details page.
  3. The detail page shows more info about the course, including the description.

Project Round-Up

Lib Ed Website

I've scheduled a meeting for Emily and me to look at the nitty gritty of how this site is going to flow. I had begun working up wireframes when I was pulled into the Peoplesoft project. I recall being stymied by how, in a practical sense, these two sets of requirements will live in a single solution. Emily, plan on a working session. Bring a felt tip.