A handful of people at our LJMU campus have seen the prototypes over the last few weeks. One feature which seems like it might be important is the ability to associate thumbnails to links inside each item. Aesthetically there is a clear advantage to allowing thumbnails to be supported.
As a project we took a clear line on copyright. First, we would help the user to find Creative Commons media by providing a tick box to filter in favour of CC By licenses on search fields, but wouldn’t mandate the use of CC materials. Second, we don’t store any media ourselves, we merely reference media that is already out there on the web (and reachable by a URL). The rational is simple: by only linking not storing we sidestep a host of legal issues to do with content duplication, distribution, access control and security. By not mandating specific licenses we permit users with private material (videos unlisted on YouTube) to use them inside the tool without opening them up to Creative Commons.
But thumbnails create a problem — should the tool create and store the thumbnails itself? That would certainly be the most user-friendly thing to do, but it directly violates our link don’t store policy.
After some thought, we’ve decided to provide a field to permit the user to link to an optional thumbnail, but not generate one ourselves. There are plenty of sites (Flickr, Picasa, PhotoBucket…) providing free image storage, and their service will be considerably better developed and integrated into other software than anything this project could develop. The problem here is that non-techie users have a nasty habit of linking to the image’s page, rather than directly to the image file itself (which is understandable, as some services like Flickr make it non-trivial to uncover the actual image URL). I guess we’ll just have to develop something that pulls the HTTP headers for the link provided, checks the MIME type to see if it’s reported as an image, and flags an error to the user if it isn’t.
It’s a crazy plan… but it might just work!