Through ALA’s Adopt a Gulf Coast Library, Ann Arbor District Library has joined with Jefferson Parish Public Library to help raise funds for the rebuilding of their Belle Terre branch.

This press release was sent out today:

The Ann Arbor District Library, through the American Library Association’s Adopt a Gulf Coast Library Program, has been matched with a public library in Louisiana, with the purpose of providing assistance to a branch library severely damaged by Hurricane Katrina. Funds raised by AADL will go directly to the Jefferson Parish Library to help rebuild the severely damaged Belle Terre Branch.

Individuals who wish to donate may do so at any circulation desk in the Ann Arbor District Library system. Checks should be made out to the Friends of Jefferson Parish Public Library with ‘Belle Terre’ noted in the memo. AADL will forward the funds directly to this Louisiana Library which is so much in need. If individuals prefer, they may also mail checks directly to:

Friends of Jefferson Parish Public Library
P.O. Box 9391
Metairie, LA 70055

The Belle Terre Branch of the Jefferson Parish Library system closed after Hurricane Katrina ripped two large holes in the roof of the building. Before the damage could be repaired, Hurricane Rita occurred, dumping more rain into these gaping holes. The entire collection, as well as all computers, furniture, shelving, and content, was lost.

All sixteen locations of the Jefferson Parish Library system, which borders New Orleans on both sides of the river, suffered immense damage from Hurricane Katrina and the further ravages of Hurricane Rita’s winds. Nearly a quarter million items from the Library system’s collection have been lost.

Eager to offer assistance, the Ann Arbor District Library joined the American Library Association’s ‘Adopt a Library Program, which provides an opportunity for libraries of all types in the US to provide assistance to these libraries in need.

This is an excellent opportunity for the Ann Arbor Community to directly assist in rebuilding a library that is still suffering from this natural catastrophe.

The Downtown Library is located at 343 South Fifth Avenue in Ann Arbor. For more information, call the Library at 327-4560.

Yes, this is a two-way title, referring to both today's SirsiDynix Institute talk I was lucky enough to be part of and the topic of mashups. Despite the fact that AADL and the surrounding area was under attack and I was disconnected from the data portion of the presentation for the duration, it went extremely well. As usual, I'm humbled by the articulate insights of Stephen Abram, Michael Casey, and Michael Stephens. If you missed it, be sure to catch the archive when it comes out later this week.

A topic of discussion today was mashups. a mashup, for those who are unfamiliar with the term, is "a website or web application that seamlessly combines content from more than one source into an integrated experience" [wikipedia]. More than likely, you've encountered them already without even knowing they were mashups. These are bits of code that can allow you to either incorporate external data sources into your own site or, conversely, can make data streams available from your site that can be "mashed in" to remote sites. Recently, mashups have become a very vogue topic.

The first ever mashup camp drew to a close yesterday. It was the brain-child of David Berlind and Doug Gold. Essentially, It was a collection of mashup authors from around the country and, ostensibly, the world who gathered to share their creativity and brainpower. Notably, among them was Ann Arbor's Ed Vielmetti. He's reported back on the "camp's" progress--be sure to check out his blog.

But what does this have to do with libraries, and why should we be paying attention to this? Well, beside the fact that mashups are the new, hot technology and we should be keeping up with all new, hot technology, mashups have enormous potential to redefine he library boundary both in terms of the technology itself and the people creating it.

Immediately, we can see the potential on our own sites by bringing in highly-polished, powerful tools in ways that enhance the information we already have to offer. A good example that Stephen Abram cited, was the ability to use the Google Maps API to provide very specific, very user-friendly directions to library branch locations. What makes mashups so exciting is that creativity and innovation are the key elements at play in the construction of these things.

The fact that new, high-level scripting languages and development engines like Ruby or Ruby on Rails, even, are being developed make the assemblage of Web 2.0 APIs a fairly easy endeavor. As a result, we're starting to see our patrons get into the groove as they begin to spin their own creations. Ed Vielmetti's Amazon mashup is a great example of this. He's written a Greasemonkey plugin that sneaks item availability into an Amazon record. The subversive nature of these things really tickles my fancy--it allows us, as end users, to do things that would mortify any sales team. We need to laud the use of our data wherever our patrons decide it should be.

Mashups are about individual empowerment. As libraries, we need to be able to step right in and lend tools to our users that will allow them to start creating these unintended uses. Again, this requires us to have... that's right, suitable APIs! The PatREST project I'm working on strives to do just that and I'm so grateful that Dave Pattern at Huddersfield has joined me. We've been able to create a bilateral push for this by producing near-identical results using two very different systems.

The mashup also poses some fundamental questions about the library's reach--where it begins (from the patron view) and where it ends (from our insider's view). By enabling users to spin our library tendrils into any place they like, we're creating a very ambiguous border on our OPACs, which, in turn, causes the entire ILS to recede into the background and play a significantly different role. Increasingly, it's just the business logic we want.

And so, as a whole new generation of Frankensteins are born, can you say that your ILS ready? Can you deal your data out under the table? With sleight-of-hand, we're going to make the library insidious.

[tags]Mashups, API, Web 2.0, Library 2.0, Programming, Coders, Superpatron[/tags]

Either way, hop on over to Michael Stephens' blog and take his survey on instant messaging use by librarians.

His last survey canvassed a good number of librarians about blogs and the results were very interesting indeed. What really impresses me, however, is Michael's ability to make his survey results jive into something meaningful and inspiring. You can hear what I'm talking about if you listen to the SirsiDynix talk he gave last week. (Audio should be online in the next couple days)

Be sure to take a few minutes and help him out.

[tags]IM, Instant Messaging, Library, Library 2.0, Michael Stephens[/tags]

If you haven't yet, be sure to read Michael Casey's latest post on evolutionary technology in the library. We can all find some common ground with the technologies he and his group have been working with. We can all share, on some level, the same successes and frustrations with technologies like "staff and public wireless in the branches, RFID circulation and self-check equipment, mobile librarian tablet PCs, and PDAs for management staff". But as he points out, things are starting to shake loose a little and we're seeing some changes.

technology, at least right now, is in an evolutionary phase, whereas only two or three years ago we were still in a revolutionary time period where new ideas were rocking the library boat on a regular basis.

I think he's correct here. If you look back at blog entries, seminar topics, and conference talks over the last few years, you'll definitely see their content trending from what technologies are available toward how do we use these technologies and now we're starting to see, look how we're using this technology. A natural progression, to be sure, but does it say anything about the nature of library innovation in 2006? I think the other side of the technology equation is, and always will be, the people.

Clearly we need to remove the expectation that technology will always offer sensational new tools that can be inserted into library operations and result in exceptional returns.

We cannot ignore the "people factor" -- that is, the librarian 2.0 element to all this. Without the dedicated front-line staff to whom we present these rapidly changing technologies, none of this would matter. We may provide the blogs, but it's our staff who are the bloggers. We may provide internet terminals and free wifi, but the desk staff always field the first questions about all of it. Communication, patience and gratitude are key elements in the synergy between IT and the librarians as they, more often than not, embrace these revolutionary technologies that are relentlessly foisted upon them.

And while the pace of change may sometimes seem insanely fast, the speed of progress may be infuriatingly slow--but bear in mind that it is progress. The construction of some of the worlds most magnificent cathedrals took lifetimes to complete.

[tags]Library 2.0, Librarian 2.0, Web 2.0, Libraries, Librarians, Technology[/tags]

I love that every now and then posts like this one from Sarah Houghton crop up. And while most ILS vendors do a pretty good job of ignoring the dissatisfaction outright (I know ours does), I like to think these posts must still get under their skin--even if just a little bit.

This latest maneuver against our vendors' flanks consists of several posts in addition to Sarah's. She links to a post from Steve Oberg who, in turn, links to a very interesting post at It's all good.

Sarah has every right to express the frustration she does with vendors. They are still, in many ways, serving to stifle some great innovation at a time when innovation is both vital and time-sensitive. I think that's the impetus for this frustration, now. Working with existing systems is outright infuriating and the promises we get from our vendors are like those you might get from an addict who owes you money: "I'll have it for you next week, I promise!"

I found Steve Oberg's observations to be particularly keen, though I do take issue with one point: "By and large, lack of deep pockets and resources to research and quickly implement new products or features". I believe the problem is not money even though vendors may see it that way--they are looking at the marketplace which is generating a perpetual demand for widget X, Y, and Z. Ultimately, I see this as a problem that is internal to our libraries and not with our vendors. Oberg almost touches on this with another point, "More attention [is] given to librarians’ needs than library users’ needs". Except, I would phrase it, "More attention is given to librarians' needs than the needs of those who work intensively with the ILS." In other words, the tech staff. Libraries have been incredibly reticent when it comes to letting technical people make the technical decisions. The result? Vendors who are given laundry lists of nonsense by folks who really don't know what they're asking for.

Alane at It's all good has a marvelous paraphrase of Pat Sommers, CEO of SirsiDynix:

Pat was responding, if I recall correctly, to a question from the floor about why ILS vendors don't innovate more quickly. Pat remarked that his company spends $10 million a year tweaking their systems to respond to requests from customers, and that left scant time and resources to make big changes. Robin rephrased this to describe all that activity as "building twiddly bits."

I'm glad Pat Sommers called us out on this. We are ultimately responsible for giving flight to an albatross that draws both vendors and libraries away from the marriage between our vision of tomorrow's library and 21st century technology. In reality, all we really need is the simplest of solutions: the ability to innovate on our own. But what will that take?

First, librarians need to stop asking for silly little twiddly bits. Libraries should be listening to their IT departments and vetting requests through them. If you don't have an IT staff, then a part of the solution is reevaluating your staffing needs so that you have some technical people on-board--this can be as simple as canvasing your existing staff, looking for someone who wants to make the move into geekdom. I believe that a coder-on-board sign is simply a characteristic of most 21st century libraries--it's not enough to employ the best librarians you can find, you need to get passionate, interested techies as well. Ideally, library schools ought to be considering the merits of a CS track. Courses need to be developed that synthesize coding skills with library science. The more technical know-how that is mixed in to their customer-base, the better chance vendors have at getting sensible feature-requests.

But it's not just us. ILS vendors need to wake up! An entire new business strategy needs to be extolled. What should that strategy look like? Vendors need to enable library staff with tool-sets in the form of standards and APIs. Of course I've been over this time and time again, but the fact is, most vendors are not hearing this. Maybe I'm feeling the fatigue that sets in after months of subverting the intended use of our system, but quite frankly, I hold little hope that our vendor will decide to pursue a strategy that champions community dev. In fact, during a recent visit to AADL, we were told by a top III executive that we have all the APIs we need. Apparently, he seemed unfamiliar with the entire notion. What we've accomplished is in spite of our ILS, not because of it. He was visiting under the pretense that they were very impressed with what we'd done with their system--I thought, "great, this is encouraging--a chance to open a dialogue". As it turned out, he was just using AADL as a sales venue for another customer. The irony makes me grit my teeth. It's a good thing I was on vacation that week--I might have told him that we've done things to their system that would make Paris Hilton blush. (I would have thought it, at least.)

There is real frustration among the people who are working with these systems, but it should also be said that some vendors are making an effort and seem to be truly "getting it"--or at least trying to get it. It's not entirely fair to castigate them all. They are not just some dark uber-force, brooding "out there" among the turbines of a ravenous capital market. It's important to take a good look at your own ILS and vendor to determine whether they really have your best interests in mind. You may just find that they do. If that's the case, use every ounce of that good fortune to your advantage because many of us are not so lucky.

[tags]ILS, Integrated Library System, Library, API, OPAC, Programming, Library Vendors[/tags]