More Moodle Thoughts
Now that I’ve had more time to poke around in the Moodle specs and roadmap, and get a broad sense of what developers are already up to, I’m starting to hone in on the types of features that should really be taking priority. It’s easy to come up with a laundry list of ideas, but the real work is reducing to the essentials.
The profile pages are surprisingly under-developed, probably because the social functionality has been built in-house. OpenSocial and Facebook API integration plugins seem like obvious next steps, although there are some political issues when it comes to what types of platforms should be supported, and Moodle also has an international base, which means that my Facebook may be your Orkut or Bebo.
Aside from basic social integration, the immediate educational value of integrating outside platform is the Repository API. An API for importing content is much stronger than the proposed API for importing files . We were prescient enough at Box.net to see that we’re increasingly moving away from files, and toward content. That was the genesis of OpenBox.
Just as important than taking in content, if not more important, is the Portfolio API for spitting content back out. If the Repository API and Portfolio API are done in sync, the same code base can be used for the same content platforms. Aside from that, we’ll want a general purpose Flash object for content. AMFPHP and Matt Bury’s FlashMod are promising, although I’m pretty sure SWFObject isn’t compatible with Flash Lite. We have to consider that mobile devices may end up being a significant form factor for Moodle content access, so that’s not something to be taken lightly.
Moodle, and its users, have a lot to gain from better platform integration. I’ll keep my fingers crossed for version 2.0.
