I had a great chat with Jon Udell and Ed Vielmetti last week during a recorded podcast that Jon has made available on his new blog. Jon is a great podcaster–he has the ability to make a session feel like a conversation and less like an interview which makes for a very interesting and enjoyable experience as one of the participants.
Anyway, we talked about superlibrarians and superpatrons within the context of Eric Von Hippel’s notion of “lead users.” This is an area that should be of great interest to libraries–specifically, how do we identify those lead users, then enable them to mash-up, remix, and create services, tools, and content. We can learn a great deal more from our users than we are currently used to and Von Hippel shows us how in a series of online videos and papers.
I mostly talked about PatREST–its history, what it is, where it might lead, and my decision to build a patron-oriented API on top of our existing ILS. Ed shared some interesting insights into his perspective as a consumer of PatREST and other non-standard distribution channels made available on AADL’s system.
So today, at AADL, we quietly rolled out dynamic item recommendations. That means that when you're looking at a catalog record, you'll be given Amazon-like recommendations ("Users who checked out this item also checked out these library items..").
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.
$rec_bibs = db_query("SELECT DISTINCT(bnum), COUNT(bnum) AS total FROM iii_hist_data WHERE mattype = '$mattype' AND bnum != '$bnum' AND uid IN ($subcrit) GROUP BY bnum HAVING count(bnum)> 2 ORDER BY RAND() DESC LIMIT 5");
if(!db_num_rows($rec_bibs)){return; }
while($rec = db_fetch_array($rec_bibs)){
// Do your business here
}
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 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):
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.
I've updated AADL's PatREST interface to reflect an addition I've made to the PatREST specification (now 1.3). This addition takes advantage of OCLC's Audience Level indicator. OCLC makes this information available via an XML web service. From their service page:
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.
A little over a year after launch, AADL's Drupal-powered site has been upgraded to 4.7 from 4.6. Those familiar with Drupal's release schedule and changelog will know that this is a substantial upgrade that puts us in a good position to be ready for the touted and forthcoming 5.0 release (for which there is now a code freeze).
Drupal 4.7 sports a number of great new features. I'm most excited about the new search engine which does a much better job of indexing the site and allows users to do an advanced search. Searches now actually return meaningful results. Other features include a new Ajax-enabled content creation system with nifty improvements such as re-sizable text fields, collapsible elements, a file upload system that doesn't require authors to leave their work, and live menu updates. On the development side, these new features are accessible via the new form-handling system. In other words, coders can easily incorporate these new Ajax elements in their own work. Theme developers will be happy with the ability to create an infinite number of regions--nice to achieve that highly-polished CSS look. I think a couple new block types were added as well.
Another great feature is the wiki-style revision system that allows editors to roll-back their work and leave editorial log messages (a very useful feature in large, collaborative environments). Commenting benefits, as well, with the ability of site administrators to manage and moderate multiple entries at once. Finally, Drupal 4.7 supports free tagging. Not something we're using at this point, but, from my point of view, it means that the engine is there for future module work. I have a feeling I'll be using those hooks for some forthcoming feature upgrades on the website itself...
The upgrade was fairly smooth. Drupal ships with an update script which ran flawlessly, but that's the easy part. A fair amount of prep-work was done ahead of time to ensure that all of our custom modules were 4.7-compatible. Basically, this meant updating all of our form-handling code to handle the new system. We also segregated all of our own code and theme information from Drupal's using the multi-site capability. This means that we can easily keep track of our own work without it getting mixed up with the vanilla code-base. This wasn't completely necessary, but it was worth the work because it'll make all future upgrades much easier to do. Doing things this way is also in-line with my philosophy of never touching stock code unless you absolutely have to.
The long and the short of this whole upgrade means that our users will probably not notice a lot of difference, but we're now in a good position to work on AADL 3.2. And that they will notice.
I had a great chat with Jon Udell and Ed Vielmetti last week during a recorded podcast that Jon has made available on his new blog. Jon is a great podcaster–he has the ability to make a session feel like a conversation and less like an interview which makes for a very interesting and enjoyable experience as one of the participants.
