PRODing around Curriculum Design – what happened to content packaging?

This is part of a post that’s been sitting on my desktop for sometime, however I’ve been spurned onto publishing it by the recent posts from my colleague John Robertson about the use of IMS Content Packaging and QTI in the current UK OER programme.

Part of the support function we at CETIS offer to a number of JISC programmes evolves around our project database PROD. We have (and continue to) developed PROD as a means of capturing information around the technical approaches, standards and technologies projects are using. This enables us to get a programme level overview of activity, what’s hot/what’s not in terms of “things” (standards/technologies) projects are using and identifying potential development areas. Wilbert Kraan has also recently blogged about his experiments around a linked data approach to information stored in PROD giving an overview of JISC activity.

John reflected that “In comparison to many e-learning development projects few projects in the UK OER programme are using elearning specific technology (more on this in a future post) and as a result out-of-the-box support for CP is not prevalent in the programme. There is also only limited use of VLEs in the programme”. In contrast projects in the current JISC Curriculum Delivery programme quite unsurprisingly as the programme is about course delivery, make substantial use of VLEs. In fact of the almost 60 different types of technologies and standards identified in use throughout the programme, the most prevalent is VLEs, with Moodle being used by half of the projects. But like the OER programme few of the projects are packaging their courses. In fact only 3 projects are using IMS CP and 3 SCORM. And in some ways that is probably down to the default export functions on tools rather than a considered approach to packaging material.

Now in many ways this doesn’t really matter. The world has moved on, we’re all working the cloud, linked data with relate everything to everything when, where and how we want it . . . So, has the content interoperability within VLEs exercise failed? Do the real users, and not those of use at the cutting edge of development, just not need to think about it? Are there enough, workable alternatives?

However I do think it is interesting that there seems to be some kind of gap around content packaging. Maybe this is due to a mix of bias and guilt. I have spent vast chunks of time in IMS meetings trying to improve the spec. Was it all just a waste of time? Should I really just go and open my shoe shop? Is IMS CC doomed to the same fate as CP? Well actually Warwick Bailey, ICODEON, gave a presentation at our distributed learning environments meeting last week which provides a pretty compelling case for use standards based structured content.

With the OER programme we’ve had a number of discussions in the office around people looking for ways to essentially wrap their content and CP just doesn’t seem to feature in their radar. I know that there are other ways of pushing out content but in terms of archiving and allowing people to download content CP is actually a pretty good option – particularly for learning resources. John also commented that another reason for not choosing CP could be that “detailed structuring seen as superfluous?” Well maybe, but actually, having structuring is really useful for end users. And for archiving purposes CP does have its merits too.

I suppose what I’m trying to say is that sometimes we don’t always have to look for the shiny and new, sometimes there are things out there that are maybe a little less shiny but functional nonetheless.

8 thoughts on “PRODing around Curriculum Design – what happened to content packaging?”

  1. 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…

  2. 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.

  3. 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.

  4. 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.


Leave a Reply

Your email address will not be published. Required fields are marked *