Monday, April 11, 2005

Why We Need a Course Management System - Part 3

A significant part of being an instructor is dealing with logistics. Assignments must be collected and returned. Students say they've added the course some time during the first 10 days of the semester. Have they? Grades must be assigned, not just to the instructor's internal gradebook but to the campus' official grade recording areas. And this is not just end of term. There are reports to fill out for Minority Students, Athletes, and mid semester grades for Freshmen. The logistics issues are an annoyance for most instructors. For those who teach large, multi-section classes, these issues subtract substantially from the joy of teaching.

It is worth commenting about the Banner Student System in this regard. The problem, to be blunt, is that the software ignores our long standing business practice in teaching. The particular issue is that there is no class object that corresponds in Banner to "the course." All the class objects in Banner are "sections." There will be a section for the lecture and different sections for the recitations. The instructor who wants to find out which recitation section a particular student is in and who doesn't have that information somewhere else, will have to go into each of the Banner recitation sections till the particular student is found. This is annoyingly inefficient, doubly so because of the price tag on Banner. The campus through the Division of Management Information now produces a shadow course roster system because of these deficiencies in Banner. For an instructor who has some facility with Excel this course roster system is a real boon. There are many instructors, however, including some who teach large classes, who lack facility with Excel. They really could use something that is easier to work with.

There are also convenience issues for the students. At present (where we have not yet implemented a campus portal) students may have to know many different urls (one per class) to find the class homepages. If all their courses had at least a minimal presence inside Illinois Compass, that would make this an easier task. Beyond this, there is the need for the students to learn the navigational structures and the peccadilloes of negotiating with the software in multiple systems. At some level, it is good for the students to have the resiliency to use multiple systems. But once having attained that resiliency dealing with yet one more system is mostly a pain. There is a convenience benefit being in the same environment for all classes.

In a different area, there is the issue of protecting student privacy online. We refer to these as FERPA issues. Here the problem is that the liability is born by the institution - the penalty for being in violation is loss of Federal grant money. Hence the campus is under mandate to encrypt any transmission involving grade information. Grades shouldn't be sent via email. Doing so violates the campus Information Security Policy. We in the Academic IT organization (CITES) are the custodians charged with providing a mechanism that is consistent with that policy. There are many instances of course management systems supported by departments that have passwords transmitted as clear text and hence they violate the policy. The irony here is that the users frequently like those systems better because they are faster. Using ssl slows things down a bit. But that is necessary. And the respect for student privacy is a value that needs to be promoted on campus. Because we are a big and bureaucratic organization (I'm referring ot the University as a whole, not just to CITES) there is a tendency for many to circumvent the regulations in an effort to produce something that is more user friendly. On the student privacy front, however, it would be best for all members of the campus community to adopt the approach that CITES has taken with Illinois Compass. That would be doing the right thing.

To achieve these various ends the course management system must be integrated with other systems. These integrations requires sometimes complex programming that is best rationalized by doing the activity at scale. So CITES needs to be in the business of integrating its systems with others. The software that CITES supports must have interfaces (these are called APIs) to accommodate the integrations. The Vista software has the APIs yet Illinois Compass is an immature service, in part because many of the integrations that are currently in place need to be re-done or expanded upon. In particular, we have discussed internally building out the roster functionality that currently exists, so that much more data would be brought into the system (for example: section, student identification number, and Internet email address). This would be done through the grade book API in Vista. Furthermore student status (whehter they have dropped or not) can be brought in so that with a simple query (that functionality is already built into the software) the instructor could see only those students who are currently registered, without deleting the record of work done by those students who have dropped.

Another integration that would follow soon thereafter would be to enable instructors to submit grades directly from Illinois Compass into Banner. This too is being discussed. And something else in the offing, when the next version of the Vista Software has been released, is to get the student iCard photos linked from the gradebook area, so an instructor will be able to match a name with a face.

These services are critical to provide to instructors and students. Their quality of life is much enhanced by the provision of these services. The best way to provide these services is via the course management system.

No comments:

Post a Comment