Earlier today, Proquest hosted a webinar with Godmar Back and Annette Bailey on the work they’ve been doing at Virginia Tech to customize some aspects of the Summon interface. See their Code4Lib paper for the technical details. Much of the webinar consisted of watching Godmar Back think aloud, navigating the code, to show how they “reverse-engineered” Summon code to identify components of the AngularJS framework they could augment. They used a utility for deobfuscating the source code (Code Rascals W0rd of the Day: Grep) so that they could identify Summon developers’ custom directives that they could modify with their own JavaScript. At least, I think that’s what they said they did.
According to a recent interview with Proquest, the original motivation for all of this was to be able to capture user click-throughs in Summon results for Virgina Tech’s libFX project. Check out the “discipline ticker” for an example of what they were trying to do. But, of course, it opened up the possibility for other customizations.
Examples included being able to improve labeling of links, or to have certain facets default to an open state on search results pages, and to retain that choice after page reloads. Another example, demoed at the end of the webinar, was the insertion of local notices, such as simultaneous user limits, into certain result displays.
They acknowledged that considerable technical skills were necessary for sleuthing the Summon code. They also acknowledged what they felt were the “moderate” risks associated with “writing code that directly interfaces with vendor code,” and expressed confidence that the risks were manageable. A big takeaway from the webinar is that much is possible, even when dealing with seemingly inscrutable vendor interfaces. It would seem that what it takes is a culture that supports experimentation, and a willingness to invest the necessary resources into creating the best possible user experience regardless of whether a system was developed in-house or purchased from a vendor.