Aug 062012

Update 10/4/2012: LibX is now in the Chrome Webstore!

If a user installs directly from the webstore, they won’t have an edition activated.

To ensure that your users will activate your edition upon install, follow these instructions.

Update 10/3/2012: We are really close to making LibX for Chrome comply with manifest v2, expect it to appear in the web store soon. Ironically, after we were 90% done with the necessary changes – converting from the eval-based JsPlate to the eval-free AngularJS framework, Google reneged on their prohibition of eval() – it will be reallowed in future versions of Chrome.


LibX for Chrome is currently broken, and it’ll take a long time to fix it. Use LibX for Firefox instead.

Google really took us by surprise. The changes to LibX to conform to Chrome’s expectation would be tremendous, and at this point we cannot say how/if we can make them.


As of 7/31, Google changed how to install extensions in Google Chrome.  Previously, LibX users could click on a link with a .crx file and the extension would be downloaded and installed. According to the new policy, users can no longer simply click. If a user clicks, they will see this instead:

Users then have to download the .crx file, save it into a folder, and then drag-and-drop it into the extension tab, as described under “Steps on adding extensions from other websites“.

Obviously, this is an unsatisfactory situation. We are currently investigating whether it is possible to make LibX available via the Chrome Web Store.

How to set up LibX with the Summon API

 Posted by on June 25, 2012
Jun 252012

A key goal of LibX 2.0 is to integrate with services such as Summon, which provides an API. Whereas LibX 1.5 mostly provided links a user could click on to initiate a search, LibX 2.0 aims to provide the resulting information directly to the user.

To contact Summon, LibX has two options, which we call “Summon Widget” and “Summon API (via proxy)”.  The Summon Widget service is less detailed and does not show circulation information, but can be used immediately by any Summon customer.  The Summon API (via proxy) requires an API key and it requires that you run our proxy on your machines where the API key is located, but it provides more detailed information. The Summon API also requires that the URL of the Summon proxy be included in the edition configuration.

An example is shown in this short screencast (0:47) which demonstrates live how Summon is contacted when the user hovers over an autolinked ISBN, as shown below:


If your institution subscribes to Summon, your edition can make use of these services as well.

As pointed out above, nothing needs to be done if you’re content with using the Summon Widget API, except you must make sure that Summon appears in the first position in the list of catalogs.

If you wish to use the more detailed Summon API (via proxy), you are required to install a proxy service that LibX can contact to search Summon via the API. Unfortunately, such a proxy is necessary because accessing Summon via the API requires a key, and this key must be hosted securely on a server belonging to your institution. Fortunately, it is very easy to set up. All you need is an Apache server that can run PhP scripts, and you’re good to go. All you need to do is to drop the PhP scripts provided into some directory, add the key. Full  instructions are on this page.

Then, you’ll have to tell LibX where to find the service. This is also described there.

If anything isn’t working, don’t hesitate to contact us at libx.org@gmail.com

If you have ideas where to include Summon results, let us know!

Reading New York Times articles with LibX

 Posted by on June 21, 2012
Jun 212012

Stephen Francoeur asked on the LibX mailing list about the New York Times Libapp that allows users to read NY Times articles through their institutional subscription.  Here’s what it currently does. When a user visits a NY Times page and the paywall goes up, a display appears offering the user to look for this article in Lexis Nexis. This idea is based on work by James Van Mil at U Cincinnati Libraries.

It looks like this for this article. Note the gray box on the top.

When the user clicks on this box, a search is issued against Lexis Nexis using the byline, the heading, and the date of the article.

If the activated edition has a proxy, the provided link is proxied, else a direct link is provided.

LibX tries its best to follow the specification provided by Lexis Nexis for how to create URLs. For instance, it strips out “unsearchable” words such as “the”, “this”, “a”, “not”.

The notification will not appear unless the page refers to an in-print article or editorial of the New York Times. (You can check this for yourselves by looking at the source code – it must contains a tag <h6 class="metaFootnote">A version of this article appeared in.... As future extension, we could implement looking up articles in other papers with whom the Times has a partnership or owns, such as IHT.)

Readers are invited to relay their experiences with searching for the New York Times in Lexis-Nexis (what works, what doesn’t), as well as with other sources that index NY Times articles and how to use them. Note that this LibApp doesn’t rely on any edition maintainer information, it simply displays a link to Lexis-Nexis. We could add other providers to which a portion of LibX users is likely to have access.

Here are some URLs I’ve tested this application on:

How The Deficit Got This Big, July 24, 2011.

Wooing the First Dresser, February 12, 2012.

PS: the name “Paywall Buster” is of course misleading since this LibApp, unlike some rogue user scripts, doesn’t actually restore the page content for users without subscriptions.