Originally the only content that was embedded in CLUMP was book covers and book previews/content available in Google Books. Access to other resources required users to follow links out of the system. Improving the content that can be embedded into CLUMP has always been something that we have wanted to tackle when we had the time.
When it comes to embedding content in a reading list we wanted to make it as easy as possible for the users. Most users have no problem using an embedded player, but adding one in some web systems can be very difficult. We could ask the user for specifics (like what site the content is on, what its unique id is, what format is the content in, etc.), but that would make it both awkward and time consuming for academics/librarians and force them to go back through their lists to update all the relevant resources. Also they would have to do that each time support was added for new embeddable content.
We also didn’t want to have specific embedded content types for list items as any content that can be embedded already fits into our existing content types. Adding extra metadata to the existing content types was also ruled out as this would make adding new items to lists far more cumbersome.
Our solution, that we have just implemented into our development version of CLUMP, is that embeddable content should be identified and handled by the system. It should recognise when a item’s URL points to a resource that it can embed and then take the necessary steps to embed the content. This way, not only is it easy for academics/librarians to add embedded content, but existing resources will start having their content embedded in their item level popups without anyone having to make any changes to the metadata.
New resource that will appear as embedded content include both YouTube and Vimeo videos, any video files in mp4, WebM and ogv formats and any audio files in a mp3, wav or ogg format. The YouTube and Vimeo content use their embedded players to display the content, while the video and audio files use the HTML5 video and audio tags to provide the user with a player in the browser without needing any additional plugins.
Using the the HTML5 video and audio capabilities has both pros and cons. Not needing to include any plugins is an advantage, especially with the increasing number of devices that don’t support flash content. Conversely though older browsers suffer from lack of support for the new tags and so won’t display the content, also each browsers that does support the tags supports them for a different range of media types.
Luckily when a browser doesn’t support the tags or the media type of the resource it doesn’t produce an error, it just doesn’t show the embedded content. Of course if the users browser doesn’t support any of the embedded content they can still use the URL to access/download the content.
Comments are closed.