Comments on: PRODing around Curriculum Design – what happened to content packaging?

By: Sheila’s work blog » Online environments in use in the Curriculum Delivery programme

Fri, 18 Jun 2010 13:17:33 +0000

[…] I posted previously, over 60 different technologies and standards were investigated and used across the […]

By: John’s JISC CETIS blog » The use of Content Packaging and Learning Object creation tools in the UKOER programme

Thu, 01 Apr 2010 14:22:40 +0000

[…] noted ( http://blogs.cetis.org.uk/johnr/2010/03/08/the-use-of-ims-cp-in-the-ukoer-programme/ and http://blogs.cetis.org.uk/sheilamacneill/2010/03/09/proding-around-curriculum-design-what-happened-to…) the perceived usability of available tools may influence the choice of packaging standard (whether […]

By: Sheilamacneill

Sheilamacneill — Tue, 16 Mar 2010 17:45:25 +0000

HI Lorna

Yes, lack of really easy to use tools has had an impact.

Sheila

By: Sheilamacneill

Sheilamacneill — Tue, 16 Mar 2010 17:42:47 +0000

Hi Sam

Thanks for your comments. I think is also shows how important vendor buy-in to standards are. I bet if BB had more support for CP we’d have a lot more usage.

Like you I like Warwick’s demo as it does make a strong case for having content in standard form and then it can have really flexible deployment.

Sheila

By: Lorna

Lorna — Wed, 10 Mar 2010 18:39:17 +0000

I’ve been thinking about the lack of CP use recently too. While I fully take on board David’s comments I’ve always thought of CP (and QTI) as being one of the more useful learning technology interoperability specs. I wonder if part of the problem is the fact that we expect people to use it as a spec, or as a conscious technology choice? Do users really need to know what spec their tools use? I don’t think so. Developers might, but not users. Users need tools that do something useful. So either the specs themselves are not useful or they have not been integrate in tools in ways that are useful. Reload is an interesting example, it’s a handy wee tool but I think the spec is just a bit upfront for most users. So I certainly wouldn’t advocate dumping specs, unless of course they really are useless, but I do think they need to be a bit less visible.

By: Sam Rowley

Sam Rowley — Tue, 09 Mar 2010 21:35:42 +0000

Speaking as someone with a foot in both curriculum design and UKOER camps, I think a big barrier is the surprising lack of support for content packaging at the technical level. We’re currently packaging Blackboard content for deposit in JorumOpen and have had to resort to exporting the course from Blackboard and hand-stiching a content package together to recreate the structure because there is no “export as a content package” option. Then, once a package is in JorumOpen it fails to display the structure correctly. The JorumOpen development team are working on this issue but given the timescale and publicity surrounding the OER projects, you might have thought this would be fixed earlier. If we migrate content from Blackboard to our Hive repository, the structure doesn’t come with it, so you end up with a bag of bits and have to recreate the structure by hand. Then, when you’ve finished knitting your content package, you need to pay for Icodeon (or some other viewer) to allow users to view it properly, i.e. package preview is not part of the repository feature set.

I suspect another factor that might affect the OER projects use (or not) of packaging is that often repositories are not learning content repositories (i.e. no integration with VLEs) and management of the repository sits naturally with library staff whose background is more cataloguing/Dublin Core/archiving rather than VLE integration/LOM/’live’ content. In that context, content packaging might not appear on the radar. We’ve certainly had that experience implementing our repository.

We see content packages as an integral part of managing and diversifying the delivery of our learning content. If we use a content package to capture course structure based on learning content in our repository we can deliver the same course via moodle, blackboard, standalone and other platforms. It’s not just about delivery, though. The content package provides useful information about the learning context in which the individual bits are used. The key issue is that end users need to be able to easily create, find, view and reuse packages (or their component parts), and that’s currently not up to scratch.

On a more positive note, I think the Icodeon Common Cartridge Platform Warwick demonstrated looks very good (shame it’s not available yet) and Giunti are pushing their Packager tool (package-based content authoring) so there are some packaging activities afoot.

By: Sheilamacneill

Sheilamacneill — Tue, 09 Mar 2010 13:12:06 +0000

Hi David

thanks for you thoughts. good points!

By: David Davies

David Davies — Tue, 09 Mar 2010 11:39:39 +0000

I think that content interoperability within VLEs – at least in terms of the space occupied by educational technology standards and specifications typified by IMS etc – was only ever a side branch of evolution. Perhaps like a lot of technical specifications around educational technology generally. Two driving forces that seem to be behind some of this, not the only forces for sure, are people interested in technical specifications because there are interesting problems to work with, researchers & developers for example, and commercial publishers of content. There’s nothing wrong with either of these, but none are doing what they do primarily because most teachers have declared problems that need to be solved by these activities.

You don’t need content packaging for example to be able to share most content. The OER projects are working with what actually gets shared between one teacher and another, rather than what could be shared between one VLE and another. It also probably didn’t help that there were never any easy to use readily available content packaging tools. But since when did an educational technology specification like CP ever come after a period of tools development and use by teachers and their students who had identified problems they had in their teaching and learning? Anyway, IMS common cartridge won’t make that mistake. Oh, wait…