Taking advantage of Web and Library 2.0

One of Hinchcliffe's recent posts outlined ten ways to take advantage of Web 2.0. As with many of his posts, it's very useful and I found myself using it as a litmus test for the projects I'm currently working on. I also started drawing parallels to many of the topics bantered about within the L2 meme. I decided to throw together some of those thoughts in a derivation of his list.

Encourage Social Contributions With Individual Benefit

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.

My point is, don't forget about the other side of the equation. More importantly, don't be afraid of enabling patrons in order to make something successful. You'll be pleasantly surprised at what they have to offer.

Make Content Editable Whenever Possible

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.

Our job is here is tricky because we want users to have a seamless experience. Finding those areas or "hot-zones" where content can be opened up to the public is something you'll need to spend a lot of time talking about. You don't want your site to come off as being condescending, ie, "Here's your little play area, have fun!". User involvement needs to be integrated into the entire website and OPAC experience.

Encourage Unintended Uses

You can never underestimate the creativity and ingenuity of the public. You may spends hours and hours of planning and development time on a feature, only to discover, once launched, that it is being used in a manner you never intended. In these cases, it's important to first determine the appropriateness of the new usage to see if a) it should continue and b) if it should be encouraged. In most cases, if the behavior is not interfering with the experience of other users, you ought to come up with innovative ways to encourage the unintended use. Often times, that's where the best ideas come from and where the best services are born. In these cases, it's natural to feel irritated that your idea is not that one being adopted, but don't take it personally. In fact, you should think of your idea as being a spawn point for something new. Run with it--don't fight the flow.

Provide Continuous, Interactive User Experiences

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.

Solutions to this problem may take a fair bit of extra work, but that is the situation we're in. There are ways to detect modern browsers so it's possible to provide "simple" and "advanced" versions of a particular service. Creative ways of circumventing technical limitations are also a part of the solution. Providing classes and support to those individuals who wish to upgrade may, perhaps, be a component. In the end, we face a greater technical challenge than our commercial counterparts.

Make Sure Your Site Offers Its Content as Feeds and/or Web services

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.

There are a number of determinations you need to make when creating a library feed. Of course, there may be other questions you want to ask. I'm pointing these out because you'll need to think about some of this as you develop these services.

  1. Determining what should go in the feed. What content is suitable for syndication?
  2. How should the feed be formatted? What should the feed content look like? Often times, you'll want feed data to be presented differently from the way it is on the web.
  3. How often should the feed be updated? Will the feed update nightly, hourly, or as content is generated? If a lot of content is generated on a regular basis, you might want to consider digesting it so you don't annoy subscribers.
  4. Will feed items update? Will pre-syndicated items update or will an update spawn another RSS story?

Consider adding additional development APIs to your system, such as consumable REST URIs or microformatted HTML. Doing that will greatly enhance your patrons' ability to develop third-party apps for your library.

Let Users Establish and Build On Their Reputations

One of the most notable reputation systems is Slashdot's comment rating engine. This allows users to gauge each other's credibility. It also benefits your website because it motivates users to interact, thus creating content. Other benefits arise from this. Reputation systems do a great job of enabling a site to self-police. Hinchcliffe writes, "The old adage of don't do anything you wouldn't want the whole world to know about comes into play here." We're toying with the idea of a reputation system at AADL because it's a very non-intrusive way that patrons can be involved and take pride in their involvement. It's also implicitly optional. As libraries, everything we provide needs to have the option of complete anonymity. Reputation systems can easily coexist with that directive.

Allow Low-Friction Enrichment of Your Information

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, low-barrier enrichment mechanisms, such as comments, tags, rankings/ratings, you can let the content become more meaningful over time. These need to be fast and easy tools that allow anyone to easily add their two cents.

Give Users the Right To Remix

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.

Mashups are a good example of how our content is being remixed. Just look at Ed's use of AADL's REST interface to create mashups in Amazon and Google Book Search. This is where our data is needed the most in a practical sense, so allow it to be there and provide the tools that make it possible. When users use your services in new an innovative ways, highlight and encourage it.

Reuse Other Services Aggressively

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.

You can take advantage of a lot of those services because many of them have very capable APIs and encourage that kind of usage. Be sure to check any licensing issues on their end, however. There are so many great web 2.0 applications out there that can be tapped into and there is no need to reinvent the wheel, as Hinchcliffe points out. This is especially true if you are a small library with fewer resources to devote to a project. Folks like LiB, Jessamyn and Jenny have great creative minds when it comes to figuring out ways to do this.

Build Small Pieces, Loosely Joined

I'm glad Hinchcliffe ended on this, because it really is the development model to use as we proceed down this road--be sure to read his explanation. Creating a core tool-set that allows your services to grow fractally will, in the end, shine through in the product and clear the way for rapid development.

I'll keep saying this until the bluetooth cows come home: ILS vendors need to do the same with their products. The huge, monolithic black boxes of the past are a tremendous liability now. It's time to stop being hamstrung. Read David Weinburger's book. Get familiar with the Web 2.0 structure and it's materials. Be willing to rearrange those disparate pieces into new, interesting, and exciting applications.

Much of this post focuses on Web 2.0 fundamentals as they apply within the library world. That doesn't necessarily mean they are intrinsically "Library 2.0". A lot of people are doing some fine work on their websites and a lot of it doesn't follow these guidelines. That is to say that these are not components of a "good" website--only components of a Web 2.0 site which, by its very nature, tends to parallel the ideas and thoughts of Library 2.0.

We've come a long way from the days of using Dreamweaver. If you're in the middle of a website redesign, good luck!

[tags]Library 2.0, Web 2.0, Libraries[/tags]


About this entry