Fish4Info is a library portal designed to meet the needs of K–12 librarians, but it certainly can be used by other types of libraries. The heart of the system is a library catalog (most certainly NOT an OPAC) that is fully integrated with the rest of the portal. The vision behind Fish4Info was a desire to create a positive library experience. I wanted to change the typical library catalog which is often used as a pass-through to information into a destination where students would stay and interact. This means that the catalog had to become more social. To accomplish this, we fully integrated book reviews into the catalog along with ratings and tagging. We are also using tags to offer recommendations for similar books. This gives students a reason to come back to the catalog even to search for books that they have already read! My wife, who is a school librarian in a K–12 library, told me the other day that her students love Fish4Info. They are exploring the library collection in a way they never did using the OPAC.

In addition to the catalog, we also included a place for news updates (i.e., a blog), and a one-click feature that promotes books to the front page to highlight them in a featured list. The portal also includes a calendar for upcoming events and a pathfinder module that can include books from the catalog, databases from your subscription list, and Web sites. Web sites are drawn from an integrated del.icio.us-like social bookmarking tool we call Library Links [see figure 26].

A bit over three years ago when I started in this position, my first day on the job was a vendor demonstration day coming at the end of a bid process looking for a new automation system. We found ourselves rather underwhelmed by all the choices. I was especially unimpressed by the OPACs. As someone new to the library world, I couldn't understand why OPACs insisted on giving students access to MARC records. Our users aren't looking for MARC records, they are trying to find books. So Fish4Info was born from my saying that we could do better ourselves. It took a couple of years for us to figure out how. We didn't know how to create an OPAC (search was the problem) but we began with book reviews and had huge successes. A little over a year ago, IBM released their OmniFind Yahoo! Edition search engine with a free license up to 500,000 records. We used that to crawl our books as nodes and generate a basic search interface. Now we have migrated back to using Drupal for search, and have very carefully constructed the environment so that users can focus on finding instead of searching. The whole goal was to create what we referred to as a “positive finding experience.” Thus our logo, Your search is over, find it here! [see figure 27]

The real secret of Fish4Info is that we didn't have to code the whole thing. While we like to talk about this portal being developed by the School Library System of Genesee Valley BOCES, which sounds quite impressive, there are only three of us working on the project. Only Andy is a real programmer (and he was an English major), and we all have primary jobs that we have to work on. As such, we turned to the open-source Drupal framework to provide the back end for the system. Drupal has a vibrant development community who have provided the basis for many of the modules we are using (book reviews, library links, calendar, etc.). We have made a few contributions back to the Drupal community including a MARC module that converts MARC records into Drupal nodes. Drupal is such a powerful framework that it can be extended to do almost anything.

Primarily, it allows them to actually create an online community. Students have individual logins so they can write book reviews and otherwise interact with each other and the books they are reading. Since it was designed for schools, it is set up to be a secure environment. Nothing that students write will be published until it is reviewed and approved by a librarian. This has helped us get past the initial concern that is sometimes encountered in schools when it comes to “social” software.

This also lets librarians focus on creating a learning community. Between featured book lists and pathfinders, librarians can guide students and teachers to excellent resources. Some of our librarians have fully adopted this and are having great success.

While the book reviews are very cool and have been shown to be very educationally beneficial, I have to admit that my favorite part of Fish4Info are the item details pages. From the beginning, certain things were banished from Fish4Info. The word search was one of them (only shows in the logo), but more importantly were col. ill. and other AACR2 formatting strings. Titles do not have a “/” at the end of them, authors are displayed first name first, and the number of pages in the book is just a number and doesn't also talk about how tall the book is. Our whole goal was to put the book cover (from Amazon API) and summaries (from the record) at the top of the details page as the two things our users would be looking at. Everything else that is necessary is there, but parsed out to display in English [see figure 28].

From a technical level, support for 13-digit ISBNs. On a user level, one of the things we really want to work on is bringing FRBR to our holdings. Our school users don't care as much as academic users about which edition of the book we have. Having a book cover that matches what is on the shelf is critical, but we want to do more to support looking at one page for everything that is Hamlet: books, movies, criticism, etc.

We really aren't sure. Everything is being released as open source to the Drupal site to enhance further work for libraries. We are looking very closely at the University of Rochester's eXtensible Catalog as a more powerful search that could be extended with the Fish4Info front as a theme. There is quite a bit of excitement around our region about using Fish4Info, so we are looking at piloting it in a few more districts in neighboring systems.

The Idaho Commission for Libraries assists libraries to build the capacity to better serve their clientele. That's our mission statement, and it succinctly reflects what we do. We were previously called the Idaho State Library, and we are still involved in the usual state library activities, just sans-collection. We do network and consortia building, grants, Talking Book services, and more. Of course, we have our E-Branch project, providing Drupal-powered Web sites to, mainly, public libraries.

Many of Idaho's libraries are in remote rural settings and limited on staff and funds. For years we've been trumpeting the value of having a Web site as a low-cost way to reach out to patrons and provide, essentially, a virtual branch. What we'd found, however, by those libraries that had created sites was they were often out of date or extremely limited in design and function. “We had a volunteer doing the site, but [she or he] has gone off to college now,” was something we heard from a number of libraries. We conducted a review of all public library sites in the state, using a list of ten criteria that included such questions as:

• Was the library's name clearly presented throughout the site?
• Did they have their address and hours?
• Could you access their catalog online?

Etc.

Pretty basic stuff. We discovered however that among approximately 140 public libraries, only six met all ten of our criteria, and many of the libraries sites were so out of date they were advertising access to periodical databases no longer in our statewide contract, and still many others just didn't have any Web presence at all [see figure 29].

Over the years we'd conducted training sessions on HTML and Web technologies, even going so far as to provide Web site templates at one point. These were well-attended and received good feedback, but it wasn't very often that we saw what we'd taught put into practice. It eventually occurred to us many of our libraries didn't have the time to put what they'd learned into practice, or at least, not until they'd forgotten much of it. The barriers to entry: knowledge of the technologies takes time to learn, and time was what they were already short on.

I'd begun considering coding a content management system from the ground up, but thankfully found the consideration of such a project daunting and turned instead to evaluating open-source solutions. Drupal version 4.7 had recently been released, and was a significant improvement over previous versions, some of which I'd evaluated over the years. After testing Drupal's multisite capabilities—i.e., its ability to host multiple sites off a single codebase—I concluded it was a perfect fit for our project. It was “free,” standards-compliant, and dedicated to accessible design practices.

The most important functionality for our libraries is simply the ability for libraries to login to their site, browse to a page, and edit the contents. This ability alone has removed the largest barrier to updating their sites. They don't have to understand HTML (though it doesn't hurt!), FTP, or how to build a site. They need only know how to use a Web browser, edit content, and click Submit. It's nearly as simple as writing an e-mail and clicking Send.

In all fairness, it gets more complicated when the libraries want to start using images in their content or create new navigation schemes, but by the time they want to do this, they're hooked, have bought in to the service, and are trying to do “more” with it. That's a good problem to have.

Multi-Site

One of the great advantages of Drupal is that you need the code only once on your site to create many Web sites. Since the content and most of the configuration are stored in the database, you can use multiple databases with your single download of the Drupal code. Fish4Info and E-Branch in a Box are both taking advantage of multi-site configurations to manage multiple sites.

Multi-site works perfectly for library systems serving members with similar needs. The system can download and maintain one common set of modules and themes that libraries can choose from and individualize for their own usage. The system can then take ownership of the higher level tasks like code maintenance and training without needing to be involved with the day to day operation of the content on the website.

There documentation for setting up your multi-site configuration is in the /sites/default/settings.php file. Read the notes very carefully, and consult the Drupal Web site for problems that may arise.

That's something we came up with early on during the project. Our initial roll-out involved a training session with participants wherein they'd prepared their site's content ahead of time and we assisted them with loading it into their pre–laid out sites. I'd still hold that under perfect circumstances a library could accomplish this in 30 minutes. In reality, however, not all of the training locations we secured were ideal—some of the computers were locked down a bit much, for example, and some folks took a little more time to get acquainted with their sites than expected, and we ran into instances of folks who'd prepared their content in Word—which complicates the process, since Office likes to “overthink” things when one does a copy and paste (see figure 30).

They can be overwhelming, definitely. How we've dealt with it is by not giving libraries access to all parts of the interface, and for those advanced things that we do grant access to, we've sometimes used the metaphor that these sites are a lot like a car with all the extras—if you don't know what something does, you probably don't need it worry about it, but it's there in case you want it. Like a winch.

Early on I decided, for better or worse, I'd like to make the system as transparent as possible so someone could see, for instance, which modules are installed in their site, thus enabling them to do their research and enter into a dialogue with us about what their site is capable of doing. We do impose limits on what functionality we provide, since we can't support everything everyone wants to do, but I think we've done the right thing by allowing those dialogues to occur.

Initially the “killer” feature that raised eyebrows was the TinyMCE WYSIWYG editor, which allows folks to edit content in a Word-like environment, but were you to ask me today if I started over would we use that, I'd say, “No.” TinyMCE is Word-like—in that it looks like Word and on the surface behaves like Word, but ultimately it's an HTML editor and underneath it all it's manipulating HTML, which can be confounding for a person who doesn't understand how HTML works. Folks get hung up, for instance, on trying to use an H3 tag to make something bold and can't understand why it makes the whole paragraph “bold.” It's because the H3 is a structural tag and a block-level element and is not for presentation … , but folks don't understand that, so they erroneously markup their code using WYSIWYG despite us having spent a lot of time configuring the editor to try and limit them to good choices.

I've come to the realization that giving someone a Drupal site with WYSIWYG editor is like giving someone a sheet of paper and colored pencils and saying, “Have at it.” If you'd given them lined paper with a ballpoint pen you'd have gotten something completely different and would be focusing on solving different problems. People tend to get hung up on appearances with WYSIWYG.

That said, we've tried to keep our installations pretty close to Drupal's core modules. We have a few sites using CCK and Views to present book reviews, and have done some integration of modules and custom code to present online library card applications, but for the most part we're focusing on the essentials.

They have a choice of a handful of themes—with more on the way. We provide the ability to switch out some pages' themes so libraries can use summer reading designs when that's in season. And we use the Image Assist module to allow libraries to place images into their content.

The same one our libraries faced when they wanted to have sites on their own: time. This project was put into the mix among an already full slate of projects our agency is involved in, and I don't think any of us realized how much time it would ultimately require. When we started the project, I was the only technical person working on it and since then we have hired a Web designer, Eric Hildreth, who helps with the project and also has taken over the day-to-day tasks related to our own agency Web site (which uses Drupal as well). This last fall Eric put together a 70-page handbook on the E-Branch service, which we've posted online at http://help.lili.org/handbook That's been quite a help.

E-Branch Handbook http://help.lili.org/handbook

They love it. We've seen a number of library sites really take off and come up with new ways to reach their patrons—especially by marketing library programs. I heard just the other day from a participant who said she'd had folks at her storytime find out about it through the Web site.

One thing I'm delighted to see is that some of our sites have actually developed their own networks of support and help each other grow and add to their online Web presence.

We plan to continue to follow Drupal as that project releases new and improved versions, and subsequently we'll continue to provide training and support for our participants. At current we have 52 participating sites and a number waiting in the wings. It's our hope to continue help grow and mature these sites, and to bring more interested libraries into the fold.