Click here to receive your FREE subscription to Campus Technology
12/28/2006
Innovative features, says Brooks, come from a variety of sources—generally, via the staff working with faculty and students. One current development effort, question pooling, would allow a group of instructors to access a large pool of test questions. A faculty member could either select the questions or have the system select a number of questions from the pool, so that students are presented with a random set. “That [idea] came from the instructors understanding that they share tests back and forth,” says Brooks.
Typically, as Brooks’ team receives requests, gets ideas, or must modify the system to address changes in legal requirements, it’ll go through a requirements analysis, then do prototyping to “flesh out the ideas,” she says, “to mimic the behavior in a simple way before we build something big and complex.”
Working with Sakai required a similar approach—though “it’s a little more complex and interesting,” Brooks says. A couple of years ago, for example, the Stanford team worked with a group from Indiana University to develop testing and quizzing functionality. Even though IU is a much larger university, the two schools came together and developed a common set of needs requirements. The meetings, she says, became “really interesting because staff on both sides got a lot of new ideas for things they could try; new functionality within the system. There was a lot of give-and-take about what the system could do, but also regarding screen design and user friendliness (and how to build it in), with both sides sharing concepts and coming away with new ideas.” The effort resulted, she concludes, in “staff development as well as a more comprehensive system. When we were done, we all got more than we would have gotten separately.” And that, she explains, is why participation in Sakai has been so rewarding. “Stanford has written 25 percent of the code in Sakai. That means that we’ve gotten four times more software than we’ve written.”
MIT: The Best CMS Is No CMS
Phil Long, senior strategist for the Academic Computing Enterprise at MIT, recounts his school’s long and storied history in developing technologies that have contributed to course management and collaborative learning. Among the major initiatives: iCampus—the collaboration between MIT and Microsoft Research that funds research by MIT faculty in the area of educational technology—and OpenCourseWare, which publishes course content from MIT.
iCampus, says Long, is developing tools that could be “called” from a CMS. In this sense, he says, the CMS presents the “surrounding infrastructure”—the place that “represents the location a student might go to for Chemistry 101.” But in the course of working with Chemistry 101, he explains, there might be a lab the student has to complete. “In that context, she might connect to the iCampus online remote lab for semiconductor testing and, using the iCampus iLabs system, invoke and conduct the experiment online via her browser. Then she’d come to her course management environment to find out about the day’s events associated with the course, to scan notices, and to submit her iLabs experiment work to the teacher.”
Long sees the link between course infrastructure and course content as a force for pushing innovation in course management systems. “Not to disparage them, but the people building a CMS probably would have no idea how to build a [chemical engineering] experiment, and they shouldn’t be expected to,” he says. “But if they build the CMS properly, they should be able to present a good interface that says to the tool developer with a specific tool in mind, ‘This is how we would connect to you. And here’s the kind of information you need to present back to me, so we can work together.’”
But Long maintains that the ultimate innovation for CMS is its absence altogether. He envisions a future where there is a series of core services that work together but are not necessarily wrapped into a single software program. “Those core services will provide an infrastructure on which to build and attach very specific software tools for specific disciplines and problems. I think we’re moving in that direction, but we’re not there yet.” He explains his thinking: “Any major course management system—Blackboard, Sakai, WebCT—is presented as a big package. You get it and you install it. At the back end, you have a big set of computers that runs the databases, manages the [background operations], etc. And when you connect to it, you have to be authenticated via the authorization model that the particular package employs. That’s the way we currently build things. But we’re starting to move toward building these things in a way that separates those functions so they can evolve and develop semiautonomously. For example, my campus uses the Kerberos authorization system, and we would like to evolve the development of Kerberos without having to reimplement it within every single software package that we use.”
Long is speaking about the move toward service-oriented architecture and implementing best-of-breed functionality. Ultimately, he says, “those services should be provided separately, so that you use the best grouping of them that makes sense for your particular need.” He sees a scenario in the course management environment in which “people can build, add, and aggregate tools independently for a collection of the functions that, at the moment, are thought to be the best combination of things you see in this environment.”