Sneak peek: LibraryThing for Libraries

Update: Comments also broke out on the much shorter note I wrote on the main blog.

I'm giving two talks at the upcoming Computers in Libraries conference (April 16-18) in DC. And LibraryThing will be unveiling a major new thing*: "LibraryThing for Libraries." We've been developing it for a few weeks, and it's time to start talking about it!

How it works: LibraryThing for Libraries is composed of a series of widgets, designed to enhancing library catalogs with LibraryThing data and functionality. The achievement is that the widgets require NO back-end integration.

We're serious. Just add a single Javascript tag, and one

tag for every widget you want to display and we do the rest. To make sure the widgets use your library's version of a title and that some widgets only refer to books you have, you also need to upload a file with ISBNs in it—just ISBNs or all mixed together in MARC records or whatever. The whole thing should work with any catalog.

Sneak Peak: Here's a demo page, inserted into the New York Public Library catalog, showing "Similar Books" and "Related Editions."**** Please note that we are NOT working with the NYPL, and they did not approve this. But it shows how our widgets can integrate with an OPAC (in this case Horizon). I can't imagine they'll mind seeing what we can do.

(sneak-peak link and here's what it looked like before)

Pricing: LibraryThing for Libraries will have both free and paid widgets. In keeping with our policy on thingISBN, our "related editions" widget will be free—allowing any library in the country to "FRBRize their catalog" without paying LibraryThing or anyone else a dime.** The paid widgets will include book recommendations, tag-based browsing, ratings, reviews and so forth. We'll only be releasing two or three at CIL, but the rest will come out over the next few months.

Help us! We mocked it up on the NYPL because haven't enrolled any US public library beta testers—just two academic libraries overseas. LibraryThing's data is strongest in public library catalogs, so they make the best examples. If you want to see what widgets would look like in your library, let us know. All we'll need are a big file with ISBN in it. We can show you what it would look like without you changing anything in your actual OPAC. If you send us your data in the next week, we'll give you six months free if you end up bringing the widgets live.

Lastly our vagueness about pricing is not secrecy, but uncertainty. We want it to be cheap enough for it to spread everywhere it would be welcome, and not fall victim to the sort of procedural delays a big-ticket OPAC decision would entail. But beyond that, we're not certain. Tiny libraries should pay less than large ones. What should we peg it to? Budget? Librarians? Employees Does anyone have any idea what features like recommendations and tag-browsing would be worth to a library.

Expect more sneak peaks as we get closer to the conference! Next-up: "How do we integrate with your OPAC without integrating with your OPAC, or Is Altay an amazing JavaScript programmer or what?"

Obligatory footnotes:
*I hate the terms "product" and "service." Blech. LibraryThing is reflexively open, but we didn't live up to our principles on this one. We're entering a "space"*** occupied by some frighteningly large and well-established companies, and got a little scared about revealing too much. But, what the heck? We're young and quick and have data the established providers don't.
**If we end up with lots of libraries using this service, and nobody using paid widgets, we may eventually need institute some sort of charge for the bandwidth and ISBN storage. But the related editions will certainly have no marginal price. If, as I anticipate, many libraries who are using "related editions" also use another widget, there will be no problem.
***A weasle-word for "market," although at CIL we're also literally entering a space, or rather a 'hood with some well-established territories. There may be knife fights.
****The widgets are JS, but the demo page shows only the "rendered" HTML—the HTML after the JS has done its work. The integration requires some exceptional JavaScript-foo, and we're keeping it under wraps for now.