From the XC blog:

The principal investigator for the project is Ronald F. Dow, the Andrew H. and Janet Dayton Neilly Dean of River Campus Libraries, with co-principal investigators David Lindahl, director of digital initiatives; Jennifer Bowen, head of cataloging; and Nancy Fried Foster, lead anthropologist for the libraries.

This first year of grant funding represents “Phase I” of the XC project, and one of the goals of that phase is to secure a number of partnerships for going forward. That’s where the partners meeting came in. In addition to getting a lot of valuable feedback from a group of about 30 people from a wide range of institutions, the XC project hopes to get a number of people to sign on to help the project itself with anything from consultation to actual development.

As a library geek, I had a hard time wrapping my mind around the scope and structure of the project until David Lindahl gave a technical overview of how the development process might work. XC is to be a highly modular project centered around a common framework. This will, hopefully, allow XC to be a ubiquitous product that works with any ILS. It would be up to the XC partners (and perhaps, ultimately its users) to create the “plug-ins” necessary to make it work with a previously unsupported system.

I have to say that I really like the proposed structure that Dave talked about, and as I mentioned at the meeting, there are a number of projects that are currently striving to do similar things, but none of them have really thought to harness the potential of the open source “community” like XC does. So I believe XC has a higher potential for success than some of the other projects like it.

That said, a number of very good issues were raised at the meeting. Foremost among them was the issue of governance. Who will ultimately be responsible or the project? Will it stay in Rochester? I think this issue, more than all others, is what made many of the other potential partners nervous. That, and the fact that the XC project is still very early on in the design phase. Justifying a commitment to the project is not easy for a lot of libraries. That, of course, makes my blood pressure rise. When I think about the fact that the prospect of working together with other libraries on a long-term project is a hard sell to library administrators, I get mightily frustrated. Librarians seem to always want the “sure thing” even if it means settling for mediocre. I’d much rather take a risk and go for the holy grail. After all, it’s just time and money, right?

Not that I’m saying that XC is the holy grail. Not at all, but, like I also mentioned at the meeting, XC is a lofty, idealistic vision for library catalogs. I like idealism. If we, as libraries, can get past our sanctimonious insistence that lofty goals are for careless upstarts, we might actually wind up with something we want, for a change.

So, who knows what the future has in store for XC. It’s one of those projects that will succeed beyond all our wildest dreams if it gets the support it needs. Or it could die on the vine due to lack of attention and care. Kind of like the rest of us.

This little feature uses data from our opt-in patron history system. Since we've been offering that system for about a year now, we've been able to accumulate over 300,000 data points. This is another great example of how to reuse your existing data to enrich use experience. Like I've said before, you need to use the data you have to its full potential--even if it's not the data's primary purpose.

Ok, so let's look at the nuts and bolts of this. I was able to cobble this together with two SQL queries. Actually, I was able to get the same results with a single nested query, but for some reason, non-cached results took upward of ten seconds, so splitting the query seemed like the right thing to do.

Anyway..

So basically, you can see what's happening here. First I get an array of all the other users who have checked out this item. Then I get a list of items that three or more of those people have checked out and display it randomly (so it's not always the same list). Pretty easy, of course you need to grow that data before it becomes useful. 300,000 records makes the results pertinent, 300 does not.

If you're curious, head on over to AADL's catalog and test it out.. you might stumble on something new.

The next step, of course, in all this SOPAC business is to try to determine how check-out patterns are changing and whether it will have an impact on collection development.

I just snapped this screenshot about five minutes ago of our tag cloud. As you can see, a real cloud is emerging. But let's look at stats for a second.

As far as tagging is concerned, 330 tags have been entered. 97 catalog items have been tagged with 245 distinct tags. 27 people have put tags into our catalog.

Stats for reviews are a little smaller, probably because reviewing an items demands a greater time investment on the part of the user. As of now, 21 reviews have been placed on 21 items by 16 people (4 of whom are staff members). That's about an average of 9 per day. I expect that will pick up as more users become aware of this service.

Of course, compared to a high-traffic social web site like Flickr, these stats are unimpressive, but for a single library, I think they are promising.

Library web site users tend to cross a wider spectrum of computer literacy, so the whole concept of reviewing and tagging may be completely alien to a lot of aadl.org's visitors. We're in a little bit of uncharted territory here, so I'll be sure to do a number of updates as time goes on.

It only took a year, but I finally got permission to go ahead with implementing what I've dubbed "The SOPAC" here at AADL. That would be "cute-speak" for Social OPAC. The SOPAC represents a slew of features that I've wanted to implement for quite some time now. I'm rather excited to see if library users will respond to these tools in an OPAC setting as much as Web 2.0 users have to commercial social networking sites. I'm fairly confident they will. Mainly, I'm relieved that I no longer need to talk conceptually about features I've been planning to build on top of the catalog.

So what is the SOPAC? It's basically a set of social networking tools integrated into the AADL catalog. It gives users the ability to rate, review, comment-on, and tag items. The concept is nothing new, but the nature of our systems do not yield readily to this kind of retrofitting--something I plan to really start tackling in earnest, but that's a topic for another post.

If you're wondering (and didn't know already), AADL's automation system is III which recently released a software package called "Encore" that does some of what the SOPAC does. We did not purchase it, nor do we intend to. Instead we're going to use the money we saved to buy a Lexus. *grin*

Anyway, I've been messing around a bit with Snapz Pro, and thought that since this is a pretty big upgrade to AADL's site, I would include a screencast covering most of the new features. So for those with 15 minutes or so to kill (ignore the screaming kids in the background):

SOPAC Features

The "front door" to the SOPAC is, of course, the main catalog search screen. Drupal's API made development of this code relatively painless. For example, the blocks on the right-hand side use Drupal's hook_block function, making the development of those blocks simply a matter of writing a function that would return the content. In this case, the right-hand column contains search, tag, and review information.

Let's take a look at some of those blocks:

These two blocks represent the contextual nature of SOPAC. The first block appears in the regular SOPAC, while the second is displayed in the use management tools.

Here are some sample review pages:

Top of review page:

Reviews themselves:

Public view of all my reviews:

Private view of all my reviews:

While writing a review, you can simultaneously add tags for the item you're reviewing. Or you can simply tag catalog items without reviewing them. Here are some same examples of the tag system:

Personal tag cloud (My tags in cloud-vew mode):

Personal tag list. This is where users can manage their tags. Delete, modify, view, etc.

List of items in the catalog tagged with "dogs":

Feel free to visit the AADL catalog to tag and/or review some items. You do need an account to create content, but you don't need a library card to get an account, so these features are not limited to cardholders in any way.

Because I feel that this version of AADL.org is a significant milestone, I've made a tarball of the source code publicly available for download. Included in the tarball is our middle-ware "glue" that allows us to interface Drupal with the III server in addition to all the SOPAC code and supporting libraries. Bear in mind that this code will definitely not work out-of-the-box but could definitely be made to work with any III server with XMLOPAC support.

You can download the package here, or from my files section.

There are a variety of ways to characterize library materials. The type of reader believed to be interested in a particular item is one. Such an indicator, generally known as the audience level, is potentially useful for a variety of activities, including the development of new ways to improve information relevance for retrieval, reference services (including readers advisory) and collection development. Audience-level filters could be implemented in existing retrieval systems to assist users in finding content based on their information needs.

This is not the first OCLC service PatREST has taken advantage of. PatREST has been incorporating data from OCLC's xISBN service for quite some time. By pulling in the data they make available, the data PatREST is able to return becomes significantly more valuable.

Because AADL's PatREST implementation relies heavily upon III's XML server, I've added OCLC's Audience Level functionality to the PHP XMLOPAC class code which is freely available from my files page or you can directly grab it right here.

Actually, that's fine, I have no problem with that, which means... They should have no problem with me incorporating Google Books into our hit-list. Right?

Now when users search the AADL catalog, they will be given the option to peek inside the books on the hit-list--that is, if there is a record over at Google Books. Basically, the first time that record is displayed in the list, the middleware queries Google Books to see if it has that item in its database. If it does, the middleware makes note of that in a MySQL table so that the remote query doesn't need to be run again. That way, future queries save time and bandwidth.

Looking at the Syndetics offerings next to it, this seems like a much richer and more useful resource. Enjoy!

** Update 1: 8/24/06 9:45 PM **

Ha! It looks like that was short-lived! (Thanks to Ryan for giving me the heads-up), Google apparently doesn't return the favor:

We're sorry...

... but your query looks similar
to automated requests from a computer virus or spyware
application. To protect our users, we can't process your request
right now.

We'll restore your access as quickly as possible, so try again soon. In the meantime, if you suspect that your computer or network has been infected,
you might want to run a virus checker or spyware remover to make sure that your systems are free of viruses and other spurious software.

We apologize for the inconvenience, and hope we'll see you again on Google.

And here I was, trying to be nice by caching the results... Guess we'll have to wait for the API.

** Update 2: 8/25/06 8:50 AM **

So, I think I found a way to fix this. Essentially, the way I was previously determining if Google Books has a record for and ISBN what by using this URL template:

http://books.google.com/books?vid=ISBN$isbn&printsec=frontcover&dq=isbn:$isbn

Now I'm using a different URL that does not return 404:

http://books.google.com/books?as_isbn=$isbn

If there was no record for that ISBN, Google would throw a 404. I think the fact that one IP was requesting so many 404s is what spooked Google, not the retrieval rate. Also, I noticed that I could no longer use wget on the command-line to grab the data--Google would return a 403 (Forbidden). So, my thought was to ditch PHP's file_get_contents for CURL which allows you to spoof a user agent. I took a peek at our apache logs and chose:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

So, instead of looking like a "virus or spyware", the script now appears, to Google, as an extremely zealous Google Books user. We'll see how long it lasts, but it seems to be holding...

** Update 3: 8/25/06 11:40 AM **

No go, they've blocked us again. I'm sending an email to the kind folks at Google Books, and we'll see if they reply. Until then, I've got a few more tricks up my sleeve... In the meantime, I'll leave the cached information active...

** Update 4: 8/25/06 4:07:PM **

Google scores major points in my book! One of the managers over at Google Books just emailed me to say that he likes the idea of the hit-list links and that he is going to see if they can accommodate these types of queries.

First, two new functions have been added to the service. One provides access to tops (or popular items) lists. The other provides access to the new materials lists. I believe these are significant-enough additions to the service that they merit the 1.1 version number.

The top items query is scalable by result size and can be paginated, just like the search results. In addition, it can be scoped by material type: books, cd, dvd, or bocd (books on CD). When applied to the AADL XSLT, it looks something like this:

The new items query is similar to the top query in that it can be scaled by material type, size and be paginated. You can also search new items using their subject headings--useful for querying those new knitting books, Ed... It looks something like this:

Second, and probably more importantly, I've finally drafted a specification for PatREST which includes an explanation of it's XML schema and some documentation for it's various functions. It's about time, I know. It can be found in the files section, or downloaded here. (PDF)

I'm not going to go in to too much detail about the two new functions in this post because the new documentation contains everything you need to know to get started with them.

In response to Hennepin's new commenting capability, Talis's Paul Miller asks the question, "Participation is an important part of moving forward. How much better might shared participation be?" What he's talking about is allowing other libraries to access Hennepin's comments in an effort to provide a more enriching search experience beyond Hennepin's OPAC, say, at Ann Arbor, or wherever.

What Paul goes on to propose in a follow-up post is a shared collectionof user participation much like the UK's archival project. This would provide a central database and, presumably a set of web tools to access and interact with the data. Libraries anywhere in the world would have access to add and read content. It would be a shared, collaborative clearinghouse of participation.

I'm all for it--but with some caution. Isn't that what Amazon is now? If you take away the e-commerce, Amazon is a collection of reviews, tags, and ratings on an insanely large amount of material. Interesting? Indeed. Useful? Of course. But I feel the need to point out that libraries are community-based institutions. They are supported by local taxpayers and are run, mostly, by members of the communities they serve. As such, wouldn't we want any social element that is incorporated into our OPAC to reflect the tastes and opinions and personality of our community? I think so, and so does Ed Vielmetti:

...here in Ann Arbor there are a lot of book readers, and it'd really be rather nice to read comments from people who shared the same town with you. If I want to read random untrusted comments from people all over the world there's already Amazon.

I mentioned some of this a while ago, though never specifically addressed the local vs. global social data repository idea. All this is not to say that in addition to community-driven social software we can't access and make use of a shared data store. In response to a comment I made to Paul's second post on this, Fiona Leslie made two very good points that she has seen come up repeatedly.

1. Libraries have reading groups and staff who create reviews, and there is no mechanism for getting those reviews "available" beyond posting them on notice boards, or perhaps on the library's web pages. A few of them have an OPAC implementation that allows the reviews to be viewed in their OPAC.

2. Libraries have few or no reviews, but they see the value in having them, and would really appreciate a kickstart by having access to a shared repository of reviews created by other readers and staff in other areas.

Ok, so I'll address each one separately. First, she is absolutely right, there is no de facto method of integrating participation in to our OPACs. This is compounded by the fact that our OPACs themselves tend to be unalterable beasts and we must rely on vendors themselves to make changes and enhancements to them. Many of you who follow what I write here know that's a contentious issue for me, but I'll keep my hackles down for now and simply remind everyone that this is another reason to demand a few basic rights from our vendors.

But even if we did all have unfettered access to our OPACs, or were resourceful and persistent enough to subvert the plain vanilla foisted upon us, what would a socialPAC look like? Fiona specifically mentions reviews, so lets stick with that for the purposes of this post. Actually, let's not, because it doesn't matter what the implementation looks like--that's the fun part you and your development team get to mess about with when you do your redesign. What's important is what we do with that review data after we get it and the value it adds to the process of searching for material. I'd suggest that the data be made available via two conduits. First would be the end-user interface. That is, the website or application patrons use to both consume and produce the content. How you weave this in to your OPAC is ultimately up to you (or... up to your vendor).

Richard Wallis weighed in ad responded to my comment. He writes:

So what are my assumptions then? Well firstly, the contributions of the citizens of Ann Arbor would be of great use, interest, and value to a far wider audience than just their district. Secondly, contributions to any global pool should be tagged as to their source and type. Thirdly, because of that tagging, selection of results should be able to be via many filters such as library, library authority or institution, library type, country, language etc.

So following through those assumptions in John's situation, I would hope that contributions for my community would add value to the global pot; be displayable locally in isolation as a coherent set; and optionally could be supplemented by those from other appropriate communities around the country and the rest of the world.

I suppose I was a little unclear in my comment on Panlibus. I'd agree with Paul that, once the data is in, it would be nice to have a way to share it with other libraries. And I also agree with Richard that there is a place for supplementing existing data with a larger pool. In fact, I believe we have an obligation, as libraries, to do some manner of both. I envision Ann Arbor's system providing a very lean web service on top of this entire system. Using this model, we will be able to share our community-driven social data beyond our borders. Libraries who do not enjoy the same community support that Ann Arbor, has will still benefit from the data. I believe this distributed approach to generating and maintaining socialPAC data will ultimately offer both redundancy and diversity. The thought of hundreds of libraries making their data available is certainly a more appealing alternative than that of the monolithic database. Metadata itself is an archive--it tells a story.

Fiona's other point was that kick-starting a service may be difficult, especially in communities that are not likely to respond to and prime a service like this. Personally, I think we all might be surprised at the response that socialPACs will have with our constituents. Almost everyone has an opinion, and most people want to share it. That aside, however, Fiona is right. There will be cases where social software is not successful, popular, whatever.

So how do you evaluate your own situation with respect to social social software? Can your community sustain a socialPAC in perpetuity in a manner that will continually reflect a unique attitude and personality? If it can, how do you get it started?

First, you're going to have to be honest with yourselves about the project itself. Do you want to pursue social software because it's cool and hip, or do you really want to change the way your users interface with your collection in profound and personal ways while building a legacy at the same time? You can get a good feel for the level of Web 2.0 participation your community engages in by using existing Web 2.0 services which often let you dial in on specific locales. This may give you a good indication of whether a program like this might be a success.

If you're convinced that your community will support a socialPAC, the next step is to come up with a a design and interface concept that will truly let your existing catalog shine while providing all the Web 2.0 immersion people expect. (easier said than done). This is where the innovators need to step in and start coming up with tangible examples of how this might work. I suspect that most libraries that do this will pursue a variation on a theme, but bear in mind that there are a lot of directions to take this stuff and in the end, it's the one-of-a-kind feature that will give your OPAC its fingerprint. I suppose that vendors will dial in on the more popular and successful models and run with those. I have no problem with that as long as they adhere to the Web 2.0 spirit.

What about the initial "jump-start"? While I was writing this, my thoughts kept drifting to sourdough and I remembered a good friend of mine who, on occasion, liked to bake sourdough bread. It was this person who introduced me to my first sourdough starter. A shapeless blob that lives in your refrigerator and which, on occasion, you feed. At any rate, he was telling me how some sourdough starters have very rich and colorful histories because they have been passed down, literally, through generations. Some are closely guarded, while others have been disseminated and passed around liberally. It's pretty fascinating.

But before I digress completely, Fiona's concern about kick-starting can be addressed if we make our metadata available to systems starting up. Instead of one or two large repositories, however, wouldn't it be great if we could choose from hundreds and all we had to do was send a request against a web service to get started? The tools are in place to allow this kind of interaction. All it takes is a willingness to communicate and share.

I suppose I may be searching for blue sky here, but Web 2.0 gives us a chance to do things properly from the beginning. Ultimately, the successful system will be rich with good data and useful to your patrons. The deeper significance of a unique repository will not emerge right away, but in time, you'll see how data, like buildings themselves, can add to the legacy of a place. Make it available to the larger library community and we'll see some very interesting things, indeed.

In addition, Ryan has written up a couple great how-to's on getting item data and featured lists from the XML. I, for one, had no idea it was possible to grab featured lists this way. Ryan Eby has been documenting III's XMLOPAC for quite some time now and he's certainly one of only a handful of authoritative voices on the feature.

David Walker is another, and a very industrious voice at that. Today I had a good chat with him on the Code4Lib IRC channel after he showed me his totally amazing catalog based off his equally cool Shrew project. What he's been doing is exactly what I've been looking for. Even though the Shrew project is currently written in C#, he has plans to port it to PHP5, taking advantage of DomDocument. It's a project I'm completely willing to commit some time to myself, if he asks. The shrew project is "a system that converts the Innovative XML Server into an SRU/SRW and OpenSearch server." He's put a great deal of time into writing XSLT that will translate the III server's output into MARC-XML, Dublin Core, or MODS 3.0. My XMLOPAC class for PHP5 utilizes an older version of his MARC-XML XSLT, but I think when he pulls off this port, the need for my code will go away altogether--his way is preferable.

We also discussed some inherent problems with III's XMLOPAC--of which there are a number, and some potential enhancements. Chief among them would be the ability to conduct business--placing items on hold and such. A lot of work needs to be done, but I'm feeling much more optimistic about my OPAC aspirations now and, thanks to David and Ryan, a renewed sense of enthusiasm. Thanks guys!

[update] Ryan reminded me that Rob Casson is the individual who was kind enough to provide hosting for the wiki [/update]

[tags] OPAC, XMLOPAC, XML, XSLT, Library, Code4Lib, PHP, C#, SRU, MARC, DomDocument, Web Services [/tags]

One of the questions posed to the panel was, where can Library 2.0 make a difference now? Where is the action?

I had mentioned four particular areas where I thought L2 could be a change agent: technology, policy, programming, physical spaces. It's important to note that these four areas of change are in no way inherently "library 2.0"--just a part of the conversation. I think it's also important for me to admit that beyond technology, I really cannot write with any authority about policy, programming, or physical spaces, but I can identify good elements in each and voice an my opinion as to what I believe is good practice in each realm.

It's difficult to have a conversation about what's new in librarianship these days without bumping into terms like RFID, blog, wiki, and IM. There's little doubt that technology is poised to play a defining role in the future of librarianship. The question is how, to what degree, and what will it look like? I certainly see perils--some of which have already manifested themselves, *cough* .. RFI .. *cough* D ... I think we run the risk of chasing our tails in a frenzied loop, driven by tech for tech's sake. Always remember that when considering new technology, be mindful of "the process"--your existing methods and how new technology will impact it. After all, we share a relationship with technology, we don't own it. If we're unrealistic about that relationship and where it's going to go, we run the risk of burning ourselves in a flash of limerent passion.

So, what is the good stuff? As always, my response is, "that depends". Lately I've been beating the OPAC drum because I believe it's a fundamental library tool that's being neglected and passed over for more interesting or hip technologies. I believe in the socialPAC--we'll see where that goes, though. Michael Stephens does an inordinate amount of work trying to get libraries to adopt blogging. We've realized some very positive returns from our blogging initiative at AADL. In less that a year, we've managed to accumulate a sizable archive of quality content that belongs to us and invites community involvement. The model works and it adds tremendous value to our organization.

APIs have become vogue and we're seeing both the term and the technology itself sink into the library vernacular--at least in the blogosphere among library techies. I think the fact that we've witnessed some real successes with technologies like mashups, metadata and microformat-based tools has given rise to a general acceptance that the API is a critical business tool. I'm keen to see what arises from projects like unAPI and OpenURL. The idea here is to get away from technology that no longer works well, or doesn't live up to today's computing standards.

I don't want to speak much on hardware, because that is a bit of a sticky wicket. The problem with hardware is that it's always there and I really don't believe that hardware provides as much ROI as the judicious use of software can. As long as you have the right hardware for the job and enough power to drive your applications, you're set. That's not to say that we shouldn't be experimenting and researching ways to use new hardware--we just need to be careful because hardware vendors often promise one thing while practicality demonstrates another--tablet PC, anyone?

I'm grateful to the administrators who toil over policy development. Well, I'm grateful to them when they produce policy that makes sense! I've always been of the opinion that if the majority of people ignore a particular policy, it's bad--I think there is a little bit of acknowledgement of that going on these days as we look around and see a number of institutions relaxing rules and taking the opportunity to foster environments that are more inviting and less punitive. AADL, for example, now allows patrons to enjoy a beverage anywhere in the library so long as it has a lid. The old stereotype of the cranky librarian shushing anyone who dares to converse above a whisper is slowly eroding. I'd like to see fines disappear--some libraries are adopting very lax fine policies. Fines do nothing but scare off potential users and disenfranchise those who have accrued a balance. Friendly phone calls ought to accompany invoices. Your facilities could have all the right components for an immersive library experience, but if the policies are suffocating, expect users to go elsewhere.

While we're at it, reconsidering organizational structure is not a bad idea. My guess is that a more Google-like approach to staffing in key areas may help foster innovation. In other words, libraries might benefit from flattening out the organization structure of its employees in areas where new ideas are being developed and tested. Staff members need to have a realistic sense that they can approach anyone else in the organization with ideas and proposals instead of scheming up ways of floating them through layers of bureaucracy with the fear that they may be trampling on someones toes. Bureaucracy is an innovation killer.

Good policy can also pave the way for radical transformation in programming. In addition to the regularly-scheduled programs like story times and computer classes, I'm continuously impressed with the quality of guest speakers and other events our community relations department puts together. Programming is such an important tool for reminding your community that the library is alive, full of hope and opportunity. Lately, with the addition of gaming juggernauts like AADL-GT, we're seeing an upsurge in the amount and quality of teen programming in libraries everywhere. Teen programming is tremendously vogue right now and is vital to the fiscal health of our libraries in the future. We ought to be hiring and encouraging the very best teen librarians we possibly can right now--they need to be courageous, energetic visionaries, much like our own Erin Hemlrich (who ought to be blogging!). Courageous, because aside from the perceived taboos that need to be broken in order to get teens excited about the library, getting teens excited is not easy--it takes guts to engage those hypercritical hormone-factories. Gaming programs have a huge potential for return, if done right. Eli Neiburger and Erin have put together a gaming initiative that would knock your head off if you saw it--it's so good that it actually impresses the kids who come to it. And come they do--well over a hundred participants often show up for events.

Programming is also receptive to the adaptation of new technologies. Creative and judicious use of streaming audio/video, VoIP, wifi, electronic signage, even our own existing databases can yield results that look highly produced and professional. Attention to detail and a mindset that demands quality will create a product that our users will respect, and in turn, they will feel respected by us. True, money plays into a lot of these programs, but not always, and not as much as one might expect by looking at the finished product--be wily and get it done right!

We've just successfully opened the new Pittsfield Branch Library--the latest addition to the AADL system. It's a beautiful library--my favorite so far. In addition to bright, airy, open stacks and a quiet reading room with a fire place that overlooks protected wetlands, it features a generous kids area replete with toys and game computers. Also, directly in the center of the building is an interactive Bernoulli machine exhibit--a joint venture between AADL and the Ann Arbor Hands-On Museum. The exhibit allows visitors (mostly the children) to press a pneumatic button that launches balls up a 20 foot tube where they are shot out into a spiral funnel that winds the balls back down another tube into a collection chamber with a spinning disc that sends the balls careening over buttons that light up various panels. The balls then fall back into a pinball-like queue where they can be launched, once again. It's really quite impressive. I also think it was a courageous move to put it in there due to both it's size and the amount of activity that it garners. It's definitely a draw for the 2-8 year-old crowd!

The point here is that physical space plays a major role in defining both the mission and purpose of libraries. I'm glad to see that larger and larger areas are being devoted to youth and teens. Having those resources brings in the stay-at-home parents with their children and starts a process of acclimation that primes the pipeline with future (tax-paying) patrons. Clean, accessible and uncongested computer rooms are essential to providing connectivity to those who may not have it at home, or who may not even have a home (we ought to be thinking about programming for the homeless, as well). Book stores have coffee shops, libraries should too, with free wifi so that the Borders down the street doesn't steal our business.

Okay, so I've taken a few scribblings and turned them into a long-winded brain-dumpish post. What can I say, I love what I do, and I believe that libraries are an oasis. Like most everyone else, I think we can do better. If nothing else, "Library 2.0" reminds us that it's an exciting and challenging time to be a library.

[tags]library, libraries, Web 2.0, Library 2.0, SirsiDynix, OPAC, innovation, technology, policy[/tags]

I have to confess I think he may be right, our library web sites are not places where you want to spend any time, and our OPACs are not fun places to be either. But then again, why should they be? Why should our library web site be a place where our students want to spend time? Is there something missing from their university experience that only our web site can provide? Why this fear, this sense that, unless we soon get up to speed we are all doomed?

First, I want to be clear that I don't think we are doomed if we choose not to implement social software in our OPACs. Libraries will not cease to function if we don't address the shortcomings of our online catalogs. It is very clear to me, however, that the OPAC is an empty vessel, waiting to be filled. Since their inception, OPACs have done the job intended by usurping the card catalog with stoic efficiency. Let's be honest, though and admit that something special slipped out into the ether when those large, cumbersome drawers were toted out and replaced by luminescent portal we now know as the catalog station. That's just the way it goes.

Much of what we lost was not due to function, but to form. Nothing will replace the look, feel, and smell of a dusty, old, age-cured card catalog, but it's been a decade, or two since we made the switch and I think it's okay to consider making our OPACs special. We've got a unique opportunity now as the planets of technology, internal discussion, and market penetration align. Perhaps now is the time to overcome institutional inertia and do something unexpected, if not radical. A social element belongs in the OPAC, our users are waiting for it and they'll soak it up like sponges if we give it to them. Web 2.0 provides both technology and a cauldron of ideas as to how to apply it. At the same time, a conversation that was once a distant murmur is gathering strength and it promises to disrupt policies and attitudes libraries have, for so long, conditioned themselves to be reflexive about. The public, meanwhile, has become inured with technology and complexity.

Let's not forget the role libraries play in a community. Perhaps the view from inside sometimes is only a view of ourselves reflected back at us, when in fact, the truth is that the public comes to us in need. Sometimes that need is small, casual. Sometimes it's the type of need that transcends record authority and can only be redressed by another in similar need. Are we really the final say on what the best resources are if someone wants help with teen pregnancy, domestic abuse, or cystic fibrosis? Can all of our collective training tell that needful person exactly what material best suits their situation?

Of course not. Our OPACs cannot be the golden kiosks we all want, but by inviting participation in the stewardship of a community resource, we can begin to build unique meta-collections that slide value, pertinence, and humanity into the search process. It may be that in that moment when a patron is about to turn away from the library, something catches their eye--a tag, a comment, some marginalia, perhaps, that puts the patron in front of the material they truly need.

The key component in growing social OPACs is community. Once you put the community you service into the process of delivering content back out into the very same community, you initiate a loop that will become exponentially richer over time as those neural connections glom on to each other. Findability is not the goal, but the activity and the experience which is why I say that OPACs have the potential to be fascinating places to visit and browse. They will not embody the comforting, muffled presence of the old card catalog. No, they'll be their own individual entities--borderless, shapeless creatures that somehow fit the people they represent.

That's a goal truly worth striving for.

[tags] library, librarians, library 2.0, web 2.0, OPAC, tagging, social software, search engines [/tags]

Much has changed in the last year with respect to the notion of a "library website". It's as though the clear, glassy surface of a morning bay has been turned and cast about by steel, unforgiving turbines. Many unsuspecting libraries are now caught in that turbulent wash, casting about for something, anything to hold on to as they begin the daunting task of "the redesign". The problem is, where do we even begin? If there was no gold standard before, there still is none, but we now acknowledge two things: Traditional library websites drain the life-force from patrons. Our OPACs finish the job.

So where do we go from here? Is there anything, anything at all we can use as a modus operandi as we, once again, begin the process of re-provisioning the obligatory library website?

Let me suggest five directives that may help get your creative minds turning. I want to talk about these not only because they represent common sense, good design, and patron convenience, but also because by using these directives as a kernel in your new project, you are sure to come out the other side feeling highly rewarded and sporting a new website that will invigorate your inner-geek for years to come.

Social software, as you are probably aware, was born of the read/write web. Partially due to persistent connections, newer software, higher bandwidth, and plain old human acceptance of the machine, the social web is a beautiful lace spun with minds, machines, and information. It is who we are as humans--it is community. just like the public library is community. So to ignore social software in the context of our library websites, is to ignore our communities. We need to find a prominent place on our mantle for it and ensure that our websites invite humanity in and give it right back. The point here is to extend the boundaries of the library, perhaps blurring the edges like watercolor so we're not quite sure where the library ends.

There are many ways to incorporate social software into your sites, not the least of which is the use of mash-ups, or the judicious use of an open source database like MySQL in conjunction with a little PHP, running on Linux, served up by Apache. Adopting open-source platforms and technologies in a library is not just financially beneficial. Philosophically, it's the right thing to do. We ought to be developing on open-source then turning around and making our work freely available to one another. We are libraries after all, we ought to act like it, not just in the stacks and at the circulation desks, but in the server rooms and IT departments as well. Don't forget the intrinsic benefits of supporting and pursuing an open sourced development program. Eric Raymond writes in The Cathedral and the Bazaar:

...we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

Joy truly should be an asset as you continue to plug away at your web project. If it is, the final product will reflect it. Open source allows success to be contagious as code is reused, changed, improved, forked, spawned into radical new ideas. That sounds like something a public library ought to be involved with, doesn't it?

I think it's time libraries took the notion of single sign-on seriously. We need to get away from the model where patrons are required to have their library cards handy every time they reserve an item. Who wants to have one set of credentials to access the OPAC and yet another to make a blog comment, or fill out an ILL request? Why not be like the rest of the world and simply require a username and password? Let me take this one step further, as well, and suggest that your new websites support session-based single sign-on--a useful little bit of web technology that has been around since, well, almost forever. When I create an account on a site I use frequently, I expect that I'll not have to keep re-entering my password every time I visit. Otherwise, I won't be visiting that site very frequently.

Single sign-on is not just about convenience, either. A unified user management system is a vital ingredient in the foundation of a cohesive online experience. Think about what your users will be doing, especially in light of the fact that you're going to implement all those great social software features. As I've mentioned before, the library website can be so much more than just a resource--it can, and should be a destination--a community touchstone. You can't do that if there is a functional disconnect between what you're offering and how you're offering it.

Single sign-on will prove to be a more difficult implementation than you may be thinking at the moment. As you scratch the surface, you'll see why, what will all the disparate software you'll be gluing together. After all, it's not like our vendors are going out of their way to offer and support open standards. We ought to, of course, for many of the same reasons I've outlined for open source. Open standards, however, gives us the flexibility both internally and externally to promote vital services in a timely and easily accessible manner. That sounds good, right? Adopting W3C standards will ensure that we've provisioned for any eventuality. Need to export? No problem. Someone wants to get Greasemonkey all up in your site? Go right ahead, Ed. RSS feeds? Absolutely essential. Want to offer a web services front-end to your OPAC? Why not use SOAP and throw in some WSDL so that potential coders can hit the ground running? Open standards, open minds, open doors.

Then there's the white elephant. Your OPAC--that malignant growth that looks nothing like the rest of your site and appears to have been coded by a CS 101 student who is contemplating switching majors to say, English. Insist on an integrated OPAC. Again, this may be a technical challenge, but nothing is impossible. If you find a way to tame the beast, you're going to completely transform the way your website operates. Ideally, the OPAC should be embedded inside the framework of your site so that you have access to all the site data and functionality during page parse. Once you've got control over what, where and when your OPAC displays, you'll find that a world of opportunity has opened up to you. While pondering a way to achieve this, you may find yourself, again, at your vendor's doorstep, whimpering, "please sir, may I have some more?" Unless the request is in an RFP, however, good luck. All we can do is chip away at them, in the meantime, there are ways of getting around that technical hurdle, but they probably require a programmer--a position libraries should consider adding anyway.

All this is an oversimplification of an arduously complex process, I confess. Sometimes, however, when you're not sure where to begin, it helps to consider all your options within a set of parameters. If I were to launch into a library website project right now, these are the "must-haves" I'd start with. For my part, these comprise an ideal that will stand a project in good stead as we continue to cast about in a 2.0 world.

[tags]Library, Libraries, L2, Web Design, OPAC, Development, Programming, Coding, PHP, HTML, HTTP, AADL[/tags]