How to create your own Libapps in LibX 2.0

 Posted by on February 11, 2014
Feb 112014

In LibX 2.0, all code that runs in pages (for autolinking, etc.) is based on LibApps. You can see the LibApps running in your edition by selecting the “LibApps” tab in the Preferences.

It is possible to create your own LibApps via the LibApp Builder. The LibApp builder is a web interface, similar to the edition builder, that allows anyone to create modules, libapps, and packages. It uses a separate sign up than the edition builder, so you have to create a separate account.

To build your own Libapps, you’ll need to learn about packages, libapps, modules, and feeds. The best and most comprehensive documentation we have is Sony Vijay’s MS thesis. Sony is the primary author of the Libapp Builder.

Put briefly, a module is a small piece of JavaScript code that runs in a page. Multiple modules operate together in tandem to perform a function, this is called a LibApp. Packages are collections of LibApps (as well as other packages). Packages, libapps, and modules form a hierarchy – a tree, in CS terminology. Each package, LibApp, or module is describe by a unique URL at which it can be found. Here are some examples:

The LibApp that links ISBNs can be found here. It is really just a description of the modules it contains, for instance, this one. This LibApp is part of a package, which is found here.

The LibApp builder allows you to create, share, modify, and publish package, LibApps, and modules, without needing to understand the internal (XML) format you find in the links above.

What, then, are feeds? Feeds are a vehicle to serve packages, LibApps, and modules. Each of them is stored inside a feed, based on the AtomPub specification. That’s why we refer to them collectively as ‘entries’ (see atom:entry). A feed may contain multiple entries. But note that a package or LibApp may be composed of entries from multiple, different feeds. So for instance, you can create a new LibApp in a new feed you create, but it can refer to (and thus use) modules contained in other feeds (such as the LibX core feed, which we maintain).

To use the LibApp builder, you thus need to create a feed, and at least one package, one LibApp inside the package, and then you can add modules to it. It also includes a search interface so you can include modules others have created. For more information, read Sony’s thesis.

LibApps can be tested right from the LibApp builder. If you have LibX installed, it’ll tell LibX to temporarily download your LibApp code and run it. Once you’re satisfied, you can “publish” it, which freezes it and puts it at its final location.

If you’re an edition maintainer, you can subscribe your users to packages you trust. Since LibApps can do things that are potentially sensitive, we do not offer a search interface for LibApps and package that were created by just anyone (though anyone can create any LibApps), but rather only by users we trust. Nonetheless, as an edition maintainer, you can subscribe your users by specifying the URL of the package you want them to subscribe. Note that you need to specify the package URL, not the location of the feed. For instance, the LibX core feed is at, but the LibX core feed is at

We’d love for people to give it a try.

I’ll close with a small concern of mine. While we believe in the power of LibApps and the opportunities they provide, we are a little concerned that the programming model of packages, LibApps, and modules may be a bit confusing to novices. I do note, however, that it is possible to create single-module LibApps, in which all JavaScript code resides in a single module. These are, in essence, similar to Greasemonkey scripts.

Enhancing Search Engines with Summon

 Posted by on February 27, 2013
Feb 272013

The very first version of LibX provided a cue on the page that, when clicked, led to the user’s library catalog. While this cue is no longer shown, we now have an even cooler feature for those LibX editions that use Summon as their primary catalog.

LibX users have the option of viewing results from their Summon instance simultaneously when they search in  Google, Yahoo or Bing. Whenever a user searches for content in these popular search engines, the search is repeated in Summon so that the user can have Summon results, which includes carefully selected and licensed resources, at their fingertips. To avoid directing unnecessary traffic to Summon, the user can turn this feature off and on using a ‘research mode’ slider (use a single click on the slider).

If results are found, a popup appears with how many results were found; clicking on the popup leads the user to the results found, as shown below for Google, Yahoo, and Bing. As for other LibX Libapps that incorporate Summon, editions may use either the Summon Widget service or the Summon API (via proxy), as described here and here.

We can include this feature in other pages where cosearching Summon would make sense – let us know what these are!
This feature has been developed by Anand Swaminathan (

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

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.