It occured to me today that learning objects, and the “EduCommons”:http://educommons.org/ project in particular, could learn some interesting lessons from libraries and CPAN.
If you’ve ever built a perl-based project of any sort, you’ve probably used CPAN to grab and install modules. CPAN can automagically grab modules you need but don’t have (from one of an extensive series of mirrors), build and install them in appropriate places, and generally be quite handy. These modules provide basic functionality needed by some larger program. In this sense, learning objects are like perl modules or libraries.
As I have argued elsewhere, I think this “useful-but-not-quite-good-enough” view that programmers take of libraries and modules is the best way to think about learning objects, assuming they are scoped to reasonbly small sizes. You would never think of writing code that consisted solely of:
#include <time.h>
#include <math.h>
#include <stdio.h>
and nothing else. Libraries aren’t useful until you place their functionality within a broader context. And I don’t think we should expect learning objects to be too useful simply concatenated together. I’ve heard Jeremy Roschelle say that we’re crazy expecting to get lots of reuse of educational components, when the approach LOs are supposedly modelled on (OOP) does a poor job of actually facilitating reuse itself… However, I don’t think there is anyone who would argue that the C libraries don’t get reused, or that the modules in CPAN don’t get reused. So we should ask ourselves – what’s the difference between objects and libraries?
The difference is between (a) expecting wholesale, unedited reuse-by-concatenation, and (b) expecting to understand what functionality is offered by a module and expecting to build a little of your own context-specific stuff on top of the module.
Anyway, it was the notion of automagically following module dependencies within CPAN that got me excited earlier today. Within EduCommons there is currently a notion of a content package, which contains content separated out from any instructional strategies. Then there is a notion of an “educational content viewer” (ECV) with embedded instructional strategies that knows how to render, present, quiz, and provide embedded feedback for a content package. As they are currently scoped, the ECVs don’t really teach enough to be individually very interesting – especially since the only functioning prototype is the one for teaching paied-associates (facts). However, it would not be terribly difficult to allow people to build larger lessons that reference individual content packages and ECVs, which the EduCommons client could check for, follow dependencies, download, assemble, and present.
I think EduCommons is going to get even cooler…