This morning I read the news that Getty Images was going to start allowing people to use their images for free for non-commercial uses. This would be accomplished via an embed mechanism common on many other media sites where the sites provide some HTML code that you can paste into web pages or other online services. The code will retrieve the image from Getty’s servers whenever the web page / blog post / tweet / etc is viewed.
While certainly a useful feature and one that will make it a lot easier for people to share these photos legally, the use of embeds does raise an issue that I think librarians need to be aware of:
“Embeds from Twitter and YouTube are already a crucial part of the modern web, but they’ve also enabled a more advanced kind of link rot, as deleted tweets and videos leave holes in old blog posts. If the new embeds take off, becoming a standard for low-rent WordPress blogs, they’ll extend that webby decay to the images themselves. On an embed-powered web, a change in contracts could leave millions of posts with no lead image, or completely erase a post…”
This reminded me of a discussion I had earlier this week regarding the potential use of embeds in a future digital collection site. Specifically, one of the curators was interested in using TimelineJS to create and embed a timeline as supplemental content to the digital collection itself. The TimelineJS allows you to create a timeline on their site and then provides you with code that you can paste into your own web pages. That code retrieves your timeline from the TimelineJS web site and displays it in your own web page.
I can understand how this kind of functionality is attractive to librarians, since it allows you to provide enhanced content, integration, or functionality on your web site with very little effort. In addition, there no need to go through your likely-already-overtaxed systems group to implement the same functionality on the library’s own servers. You can just cut-and-paste and you are done!
In some cases, this approach makes complete sense, especially when you are dealing with information or content that is temporary or transitory. (Note: There are risks relating to security and privacy when embedding someone elses code on your web site. Do your homework!)
When we’re talking about digital collections, however, our timelines stretch out some. Most folks expect digital collections to be available for a long time, sometimes persisting as-is, sometime via a series of platform migrations. For me, if a curator invests their time in developing a timeline to accompany the digital collection, I want to make sure that timeline, like the digital objects that make up the collection, is available to visitors for as long as the site exists. If I use an embed to pull the timeline from another web service, there is a good chance that in 2, 5 10 years that the embed will fail resulting in an empty space on my digital collection site.
There are ways to mitigate against this problem. For TimelineJS we could grab the source code and run it off our own servers, but that requires time from the systems folks and becomes yet another web service that we are committing to run and maintain. In many other cases, setting up a local instance of the service isn’t even an option. At the very least, make sure that you have some sort of local copy of the content that you could use to recreate and/or replace the embed should you need to. For example, if we decided to embed a timeline using TimelineJS we’d want to try to grab a static image of the timeline as well as the source data the curator uploaded to Timeline JS to create it.
The ability to embed content and functionality from other services into your library’s web site can be an effective way enhancing your patrons user experience on the site, but remember that when it comes to building digital exhibits and collections we need make sure we don’t sacrifice long-term access and preservation requirements to our desire to just get things done.