Risks of using embeds in digital collection sites

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.

Web Services Update – July/August 2013

We’re more than half way through what qualifies as “summer” here at the Library, so it seems like a good time to give you an update on the feature work we’ll be tackling between now and the start of the fall semester.

Chapbooks: We’re in the final stages of work on the digital collection site for the Chapbooks Project.


This project marks the first time we’ve uploaded content to the Internet Archive, allowing us to not only improve the accessibility of the materials, but also take advantage of the IA Bookreader to make it easy for users to read the chapbooks online.

Ming-Qing Women’s Writings Digitization Project: We are working on a number of enhancements to the user interface as well as the back-end of this digital collection, changes that have been requested by Professor Grace Fong and her research team as they continue their work to develop this valuable resource.

Intranet: We’ve started working on setting up a Drupal-based intranet for the Library. We’ll be keeping the first iteration as simple as possible, providing departments and groups within the Library with a space to publish policies, procedures, and other information for Library staff. We’re also looking into providing some form of notification system that will allow users to be notified via email when changes are made to all or part of the site.

Home page: incorporate feedback we’ve received over the year and through survey we ran in X. objectives: simplify the search box + WCL emphasis, better access to key library services, simplify presentation of news and events.

Branch pages: Our plans for branch pages haven’t changed: simplify the layout and make it easier for branches to post news and announcements to their pages without going through my team.

Site organization: Continuing with the overall theme of simplification, we’ll be starting to move forward with changes to the site structure, changing both the labels and organization of pages on our site. At the top level we’ll be combining the “Help” and “Resources for” sections into one section, as well as creating a new “Contact Us” section to make it easier for people to get in touch with the Library. There will also be a number of changes within each section that we’ll be making in consultation with the various content owners.

Another big change is that we’ll be correcting the URLs of all the main sections of the site, removing the “library-” element that is a carryover from an older design. The URLs for the top sections will most likely be changing to


This change means that in effect every content URL on the Library web site will change! We’ll be working with content owners to update links and identify high-priority URLs (ex. URLs in printer materials) that require some form of automatic redirect. We expect that the clarity that this will bring to our URLs will be worth the short-term disruption caused by the change.

Finally, in addition to these structural changes will be investigating several new UI options that the central web group has made available in the WMS, features that will enhance the display and usability of the site menus.

Librarian profile pages: Our work on implementing profile pages for librarians has stalled as we’ve encountered issues with the stability of the McGill Profiles module that have yet to be resolved by the central web group. We’re exploring alternative approaches and hope to be able to move forward on this soon.

Resource icons: We’ll be adding two new resource icons for librarians to use with their subject guide: Free resources and Open Access resources.


Once this is implemented, the existing library-resource-free will display the globe icon automatically without any intervention required. Librarians will have the option of using library-resource-open if they want to promote the OA nature of a specific resource. Rather than try to come up with a set of strict guidelines on when to use free and when to use OA, we’ll provide the capabilities and let each librarian decide for themselves. Over time, we expect that a set of best-practices will emerge.

Details drop-down: We’ll be adding a new mechanism that will allow librarians to add details to a resource, and to have those details hidden until requested by the user.


(This is actually a re-implementation of a feature we used to have in the old WPS system.)

As was mentioned before, we’ll be consulting with content owners and other stakeholders on all of this work throughout as we move forward. Questions, comments, and feedback are always welcome, so please don’t hesitate to get in touch!