(blog title is a quotation from Paul Valery)
A cloud, wandering, perhaps lonely
It is hard when developing to say “finished” – most web servers respond badly to having a champagne bottle cracked over them and pushed into the Solent. So there is a point with a web page, when it achieves a final status – a point at which it will not change. In the world of Wikis and Pinterest this seems somewhat ye olde web, and even on a Great Writer’s project – how many books only have the 1 version? That never changed? Probably because it wasn’t worth going back to – is static content then innately bad? No, but perhaps it suggests a sense of being abandoned.
So following on from our take away blog post, and Jenny Gray from the OU’s blog post – we have been experimented with packaging up some of our collections. However, we’ve almost straight away ran into a wall – a wall called static content. We can make a common cartridge file solely containing URLs which point to our content – this is relatively simple, and given we’ve got code to make RSS and itunes RSS it’s something that is a matter of algorithm wiggling and then adding code to zip the file up. So common cartridge down, and then onto SCORM and Content Packages. Sadly, here we stop, because we’d need to give these files the pages (in rendered HTML), and not just the links to the pages; this makes the process a lot more time consuming if you do it dynamically. However, it also asks the question – should we offer this as a service before we have “completed” the page, and then, how do we gauge content as complete?
A downloaded package is great, but we have no way of informing the end user – if VLEs had a Drupal or WordPress like ability to refer back to the original provider of the package to see if it had changed this problem could be resolved, but without that you fall into an either deposition or embedding camp, both have innate risks and quality issues – but it seems that the sheer variance in packaging standards places a prohibitive overhead on content production. If we had the benefit of making the content work for one VLE, we could achieve this in a more simple way- but as we are “open” we can’t really provide, or justify the provision of a fordist one size fits all solution. We are obviously limited time wise, and so developing every solution just isn’t possible.
So, in the short-term, before our Engage event (which is now fully booked!) we don’t have any evidence of which method is best – we have coded a page embed system – so now literally any page on a site can be added as an iframe to any other page (formatted nicely as well), and we will see how people think about this, before we think about developing new materials.