I'm pleased to be taking part in a SirsiDynix Institute program next Wednesday, Feb. 22nd.
Yesterday, I attended Michael Stephen's presentation, Weblogs & Libraries: Communication, Conversation, and the Blog People. He gave a great presentation on blogging in libraries. I don't really need to be convinced on the merits of blogging, but I wanted to hear what he had to say and how he's pushing the message. I'd recommend a listen to the archive if you missed it.
You can hear him again next week when he joins Michael Casey and myself for a conversation with Stephen Abram. Be sure to register, read, and attend!
[tags]SirsiDynix, Webinar, Web Seminar, Steven Abram, Michael Stephens, Michael Casey, Library 2.0[/tags]
As promised, I've been keeping some very simple metrics on the usage of a virtual card catalog service that I quietly added to the 
Now, marking the cards up is one thing--it's a fire-and-forget process, it doesn't even require a user to be logged in. Adding a card to a collection is another. Adding a card requires that a user be logged in to a valid account and represents, what I consider, a higher participation factor. This means that users are not only adding marginalia, but they are taking advantage of the ability to build card catalog collections. To me, this is really exciting stuff because it tells me that a) the service is useful and b) there is a market for this kind of stuff in a library setting. FYI, the query for this data is:
This is where I really started to feel my pulse quicken. These numbers told me that, despite a lack of advertisement, a substantial number of people were building card catalog collections. I have to be honest and say that I was expecting only 20 to 30 users participating after three weeks. As of 2/11, however, there were 75 users building collections! Check out the growth over time: 2, 6, 22, 42, 58, 62, 75 for each date respectively. Of course, to put that in perspective, we have 20,955 registered users on our Drupal site as of 2/14--our regular users are an extremely small fraction of that, however. To get this data, I ran the following query:
I was blown away by these results. Simply amazing: virtually every person to create a card catalog collection also opted-in to sharing it. To me, this speaks volumes about the types of services our users want and it tells me that a good number of our library users want to interact with each other--a vital ingredient if you want a social OPAC. It also sheds a little light on the sophistication of our users--a lot of them are already Web 2.0-aware and will be sensitive to new services like this. Our commercial counterparts are doing a great job of softening the market for us--now all we have to do is provide the tools on our systems.
I think, as Hinchcliffe points out, that the key here is to provide individual benefit. That's the major challenge libraries will face when implementing web 2.0 technologies. That's why it's important to work inter-departmentally when drawing up plans. This requires finesse and creativity. While I was developing my card catalog proof-of-concept, I first released it without the component that allows users to build collections. By itself, the feature was "neat". It wasn't until patrons were given the ability to create personal collections, email and share cards that it provided individual benefit and became "useful". I learned a lot from that little proof-of-concept exercise and I'll take that with me as AADL launches into its next major development initiative.
This is an interesting one, because on one hand, libraries have been given the responsibility to provide authoritative information to the public. If you allow the public to start changing and editing content, you run into some very practical problems. It's important to have a very distinct line between authoritative and non-authoritative content. Commercial web 2.0 websites do not have that problem--their business models depend on the users to create almost 100% of their content and the users themselves decide what is mutable.
Hinchcliffe writes, "applications with lots of page loads are so five years ago." He talks about the benefits of stateful platforms such as Ajax and Flash. I agree with him that pages need to be more dynamic, but from the library point-of-view, we need to be a little careful here. If you were to look at the demographics of the people who use popular web 2.0 sites versus the patrons who access our sites, you would probably see an interesting disparity. Most likely, our users are significantly less technical and more of them may be using legacy hardware and software. We need to be very careful about not denying service via technical limitation. In fact, we have a responsibility not to.
You might as well face the fact that if you develop something that generates content, RSS or Atom feeds will need to follow. Libraries and RSS make very good bedfellows as the endless discussion about it shows. Judicious use of feeds is the key. Having a prefabricated routine for generating these feeds is a very good idea, especially if you plan to create a lot of them.
One of the most notable reputation systems is 
If you open up your website to public input, you're going to get a lot of unpolished information and content. The general idea here is that you don't want to obsess over the clarity, conciseness, and content of this stuff. In fact, you shouldn't be touching it at all. Instead, allow all of it to be in a constant state of change. In a library setting, this hearkens back to the authority issue. This content is definitely non-authoritative, but by allowing users to continually add to it using what Hinchcliffe calls, 
This is where we've got our commercial cousins beat. We want to spawn derivative content from our data. When it comes to data that we own, licensing is not an issue. Of course we need to give users the ability to do so. 
Chances are, a lot of your existing users already use a number of web 2.0 services. Reusing them in your own site can bring in a level of familiarity and comfort to those users and truly enhance their experience.
After a fair amount of work, I'm releasing an update to the iii-xmlopac class. I've been sitting on this update for awhile because it's a fairly big update and I wanted to make sure it was performing like it should. I highly recommend that anyone using this class update because a number of fairly critical bugs have been fixed, including a messy tangle of UTF8 encoding issues.
