learning objects must die

A recent joint announcement from two of the pillars of the open education community, McGraw-Hill and Microsoft, threatened to breathe new life into the concept of “learning objects”. David Wiley responds with a refresher on the concept of the Reusability Paradox – basically, if something is super-useful in your context, it’s likely not very useful in someone else’s. That’s where the concept of Learning Objects™ falls apart.

The Reusability Paradox typically leads designers of learning objects to attempt to “strike a balance” between effectiveness and reusability. This generally results in materials that are neither particularly effective NOR particularly reusable across contexts.

- David Wiley

What’s ridiculous in the McGraw-Hill-Microsoft announcement is that they’ve built some magical new platform to let people rip/mix/burn or reduce/reuse/recycle or reuse/adapt/share media.

They’ve bolted what is basically a clip art insertion and annotation tool into Powerpoint. With some interactivity. So, you can plop various bits of media into your Powerpoint file, draw and narrate it, and this is somehow a new thing. Revolutionary. I mean – it looks like an interesting media authoring tool. Like Adobe Presenter or a bunch of others. I’ll be checking it out. But it’s not a Learning Objects™ platform. It doesn’t need to be. That branding just confuses things, and smells like they are trying to meet the checklists provided by investors.

For some background, I spent a few years many years ago building Learning Objects stuff. I built the first fully functioning higher education learning object repository in Canada. I wrote a proposal back in 2003 to extend the LOM specification to make reuse of learning objects more feasible, and extended that in 2004. I was involved in building a platform based on reusing media as learning objects in rich online presentations. I’ve been there. This stuff isn’t new, and it isn’t magic. We went down some deep and dark rabbit holes trying to chase the promise of Learning Object Reusability. It didn’t work out that well. Much of what we did wound up devolving into unintentional DRM, whether through the selection of closed file formats such as Flash, or through obscure proprietary (but documented and “open”) metadata and content packaging formats. We did as much harm as good, but with the best intentions.

The one thing that makes it easier for people to make stuff and to adapt it for their contexts? Share what you make. Share it openly. And let people use it. That goes far further than any Learning Objects project or platform.

Baking your media into Powerpoint or Flash or PDF makes it harder for people to use and reuse your stuff. Do it if it serves your purpose, but don’t do it with a coating of Openwashing – you’re not making it easy for people to use it.

Make stuff. Use stuff. Reuse stuff. But don’t try to brand Powerpoint as a Learning Objects platform. Learning Objects must die.

Remembering CAREO

Today is a memorable day. It’s the day that CAREO, the learning object repository we built at The University of Calgary, is being officially decommissioned. Unplugged, mothballed, and put into storage. It’s been a wild rollercoaster ride for these 6 years, but that ship has sailed. Back in 2001, when CAREO was first created, there was a need for a concrete prototype of a repository. Other available software didn’t quite do what we had in mind, and it was relatively easy to just go ahead and build some software to test out some ideas.

I was just coming out of the First Dot Com Bubble Burst, having just gone down with the ship at an eLearning company in March 2001. So I had some free time, and wanted to learn something new. I was asked if I could put together a working repository, and naively said “sure”. I’d never built any server software, but wanted to play with WebObjects. This was the perfect opportunity. The project picked up a shiny new PowerBook G4 (400MHz! Holy cow!) for the repository to be built on, and I got to work from my home office. Things went well, and I was using EOModeler to implement the nearly-final IMS LOM metadata specification as a set of 80-or-so tables with joins all over the place. Oy.

The first alpha version went live from my home office, served up over my home cable internet connection, and using DynDNS to make it available. Worked like hot damn. The hardest part of the whole process was in learning to stop thinking so hard and just let WebObjects work its magic.

Soon, CAREO was scaled up, features added, and content contributed. A server was acquired (a shiny new XServe rev 1.0). It was a self-contained, standalone repository. Others started to show some interest, and I had the pleasure of working with Brian Lamb, the Learning Objects Discoordinator at UBC’s OLT. We set up a copy of CAREO on a UBC XServe. Gerry Paille set up a copy of CAREO at Peace River. There was a copy at the University of Ottawa (they actually got significant funding to run their copy – much more than we ever saw to cover the building of the thing in the first place…).

Over the first 3 years of CAREO’s life, there was a flurry of development activity. I added features such as wiki pages and threaded discussions tied to each learning object. A “theme engine” was built so people could customize the look and feel of the repository application interface. A custom “SciQ” K-12 science repository was built, and used in the Alberta science curriculum. I added RSS feeds for the “newest objects”, “top objects” as well as for user-defined searches. Support for Trackbacks from other software was implemented, letting people add context to the learning objects via weblogs or other trackback-enabled services.

The custom relational database for storing metadata was replaced with a multifunction generalized XML-in-MySQL store written by Julian Wood, along with adoption of the JUD XML-RPC API. A repository using an API to connect to the separate data store. People could use the ALOHA client application to manage their learning objects – adding metadata, uploading media, etc… and CAREO would pick it up automatically because it was talking to the same abstracted metadata store through the same API.

A bridge to the EduSource network of learning object repositories was built, making it possible to search from one repository and find learning objects scattered throughout the network through a custom inter-repository API. That API and network cost a lot of money and time. And didn’t work as well as Google.

I spent a fair amount of time experimenting with native XML databases to store the LOM metadata – BlueStream XStreamDB and eXist have both matured so much over the years. A Sherlock search widget (this is pre-Dashboard) was built to let people search the repository from their desktops. Installers were built to make it easier to get your own copy of CAREO on your own server.

Heady times. And most of the work was done with surprisingly little financial support. We were able to do a hell of a lot with what we had, though.

Then, things pretty much stagnated. Development stopped, as we focussed on higher priority (i.e., funded) projects. Other software matured to the point where it was difficult to justify maintaining a custom repository application. If I were to start from scratch now, I could deploy a more fully-featured repository powered by Drupal without having to write any code.

Over the years, I’ve been asked several times by people investigating learning object repository software to implement at a national level. Each time, I said that although the source code for CAREO is available, it would be a much more effective use of resources to just go ahead and use Drupal. Work with the larger community, and don’t write (or sustain) code that you don’t absolutely have to.

CAREO was important, back in 2001-2004, as a prototype. As a sandbox for trying out some of these concepts. As a place to easily host metadata and content and try the repository model. From that perspective, I think it was a huge success. Without CAREO, I would likely still be saying that we need centralized institutional repositories to tightly manage resources.

But, because of CAREO, I now know that we don’t need repositories at the institutional level. Personal repositories are much more powerful, effective, and manageable. They’re called blogs, maybe you’ve heard of them? And small pieces, loosely joined. Want to manage photos online? Use Flickr. Videos? Use YouTube/GoogleVideo/etc… We don’t need a monolithic institutional repository.


And now, it’s Halloween 2007. And we’re about to decommission our CAREO server here at UCalgary after 6 years. The software has been acting up, and it’s just not worth the time and effort to figure out what’s gone krufty. So it’s time to put it out of its misery. Farewell, CAREO. Thanks for the good times. I’ve learned a LOT about software design, information architecture, and metadata. More importantly, I had the pleasure to meet and work with a LOT of awesome people, all working on similar projects because they believe (as I do) in the greater good. Sure, we were naive, but we meant well. And now, hopefully, people will learn from our successes, failures, and mistakes, and not be doomed to repeat them.