Why We Need a Course Management System - Part 4

This is the most speculative of the reasons because it relies on a technical vision that has not yet been broadly realized. My sense it that it will, but I could be wrong.

In a nutshell the idea is this. As we get more comfortalbe with the use of technology in teaching and learning we will want to use many different pieces of software, some of which might be highly disciplinary specific, some of which might fill a niche for reasons of expense or bandwidth use, and some of which may have broad use but which the course management systems don't have in them at present because the CMS development can't keep up with all the development in the field or because the CMS vendor doesn't think it can earn good return by including that tool in its package. The point here is that there will be a lot of tools. That is no different from the situation now.

The difference comes in the extent the tools talk with each other and in that way provide more value to the end user. For example, today we support the tool Respondus, which is good both for making assessments (quizzes and surveys) to be delivered by the course management system software and for getting reports out of the software about how the students performed. These tools interact. In essence the Respondus company has taken advantage of the APIs that the course management vendors have provided. (With Blackboard that is called Building Blocks, with WebCT that is called Powerlinks.) The point is that the functionality is much enhanced over what would happen if both environments are stand alone.

Now consider where we are a present, where the amount of this type of tool communication is minimal. As an example, there is some use of Moodle (an inexpensive to run open source course management system) on campus and some of that is fueld by tha the fact that Moolde has a Wiki. But suppose instead that there were Wiki tools that "plug into" the course management system. Then you could choose the Wiki tool of your choice as long as it communicates this way, likewise for synnchronous communication tools (Elluminate now has some following on campus), high level content authoring environments, and tools that are only used in advanced organic chemisty.

If the incremental cost is just for the tool and the rest of the functionality meaning gradebook, discusion area, etc. is provided by the CMS, then we have a much lower cost way to get diversity in functionality. Moreover, it is quite possible that to the extent these other tools are server based, that they may be supported by the department or college that wants to use them. The campus need not be the provider. We move to a partnership model where the campus provides the core functionality and the disciplines provide the more specific software.

The key to get this type of thing to work is have a CMS which accomodates the plug in capability and what the word accomodates means in this sentence --- how hard is it to achieve plug in capability in practice? There are two things going on here that are worth commenting on.

At the on campus level, and watching us support Illinois Compass over the last 18 months or so, there is definite learning by doing. We're much smarter about it today than we were a while back. The truth is we've hardly touched the Vista APIs becasuse we've been so busy implementing, but we now have another programmer to do this type of work and we have reached a level of maturity with our service that allows us to think more about these issues. As I wrote in the previous post, there are a variety of administrative integrations that need to be done to enhance the quality of life for students and faculty. My hope is that as a by-product of that work, we will become more experton APIs in the Vista Software and get a better sense on how/if we might realize this vision of lots of other tools pluggling into Vista.

At the national and perhaps global level is the Sakai project which is developing more or less with the plug and play idea and standards based inter-connectedness of various components. We hope that project succeeds, but unlike most other observers I don't believe the benefits would be much if at all on the cost side. Rather, I think that the contribution will be in enabling tool creation from a wide variety of sources and giving tool creators sufficient parameters that their tools will be able to interconnect. It is then an open question for me whether we'd be better of staying in the commercial CMS which has a revenue stream to continue development of its core components (assuming it satisfies the tool connectivity requirements) or to move to the Sakai environment even for the core function. That is too far off in the future to do anything but offer idle speculation. But now we can certainly define the vision.

And in that vision the CMS plays the role of the glue for all the other independent pieces. We can tap into the creativity of a huge number of potential creators of software without forgoing the benefits of the core functionality of the CMS, as long as we have the glue. That is the idea.