Learning Object ( The Buntine Oration - Reflection 2)

Every time the term "learning object" is mentioned in any education/technology discussion forum, it seems a question of what is learning object is inevitable. In his Buntine Oration, Stephen pointed out the early visions of promoting re-usable, small chunk of content being used to support learning. Early effort, including EOE foundation back in 1996 has started to collect "learning object" in the form of Java Applets. There were over 2600 Java applets for educators to use, mostly freely. However, it seems to me that this website has been neglected for a while now.

I argued that if we use the word "learning" in "learning object", the object must have something to do with learning. Conversely, if we use the word "object", the "learning object" must have some characteristics of "object". We wrote:

The issues of reuse, grain size, technical properties or even the basic question of "what is a learning object?" are not central issues in the education community.

So, if the technologists are bringing a concept from another field (computer science/software engineering) into this argument, I would have expected that the term will come over with all its previous researches and things learnt. Here, let me just briefly list out those elements which are essential in an object-oriented programming paradigm:

Hosting environment: an object cannot instantiate itself without a hosting environment. This hosting environment is the container where objects live and die. I believe there is an over-ambition when this concept was first introduce into education technology: any digital content in any environment! Today, it would be fair to say that the container should be the browser where most of today's eLearning takes place. Then again, the browser technology is a moving target. My own first effort, virtual apparatus, was a victim of this constant technology base shifting.

Communication between objects: one of the key promise of OOP is that objects can participate in a collaboration, each object does its own job. In order to do that, the container hosts more than one object and manage the object's life cycle. The container also provides a mechanism for objects to communicate. I thought the de facto communication between objects hosted by a browser can be done via "liveconnnect" and Javascript. However, the problem I faced when I was developing the virtual apparatus framework was the constant inconsistency of the implementation of "liveconnect" by each version of the browser and supporting technologies.

Encapsulation: This is one of the key benefit promoted by the early education technologist. All the internal operation of the object is hidden from the "object assembler". As long as the container can send a valid command to the object, the object will perform its job without the "programmer" worrying how it is done. Unfortunately, this also contradicted one of the early observation of how teachers work. Teachers used to select material, cut and paste and produce their own version to suit the observed need of their students. With encapsulation, the unit of operation is now a complete object. Teachers won't have the technical skill to get inside the object, even if they have, this is beyond the promise. This has led to a lot of discussion about grain size and technical properties. This is counter-productive for education.

Interface: closely associated with encapsulation is the concept of interface as a contract. The object assembler needs a consistent way to send command and information to an object even if the object has undergone several generation of revision and development. The discussion of "learning object" focussed on the learning object metadata, which I think, is more about "discovery" than as a standard interface to work with the object. In this paper, we talked about three standard interfaces: management, learning and instructional design. These are high level concept and implementation are yet to come.

The closest definition I have seen to possess these object qualities and are designed with the intent to be used in a teaching and learning environment is SCO in SCORM. Still ADL prefers to call them "shareable content object" and NOT "learning object". SCOs are lived in a browser (well defined host), with a standard interface to communicate with the host (actually via the host to the back-end LMS). But up to now, the SCORM specification still limits the launching of only ONE SCO at a time, i.e. SCOs cannot co-exist within the container to co-operate to do one job.

The key refection I have when I read Stephen's Buntine Oration is:

Should we put the term "learning object" to rest and return back to use the more accurate and appropriate terms such as learning resource, teaching resource or just resource? If we truly believe in the value offered by the OOP, may be we should get serious about defining and agreeing on a term and improve on it.