AADL.org Goes Social

I have a good excuse for dropping off the face of the biblioblogosphere for a month.

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):

(Download Movie ~88 MB)

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.

SocialPACs, Community and… Sourdough.

An interesting, but low-key thread unfolded over at Panlibus earlier last week. I found it to be a good starting-point for a larger discussion about how Web 2.0 and Library 2.0 technology and software could come together in a cohesive manner, instead of the traditional ad hoc, piecemeal, vendor-driven method.

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.

Why bother: the impact of social OPACs

I was reading a trackback the other day to my post, Library 2.0 websites: where to begin from Michael Dunne. He makes several very good points, but one, in particular, caught my attention as something I really haven't articulated yet to myself or others. On the subject of the social OPAC, he writes:

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]

Tagging Subject Keywords

DaveP announced on his blog yesterday that he had created a tag cloud of subject keywords from his Horizon database. It's really sweet.. check it out.

Kudos Dave!

Then he went one step further and released some generic code to allow others to do the same.

I'm anxious to port his work to a PHP class. I'd also like to use some kind of sliding scale to generate proportional tags for different orders of magnitude. There is a drupal module called Tagadelic that sort of does this, but the author is still searching for a more meaningful algorythim.

Anyone seen some math for long-tail?