Kassblog

Yesterday, I managed to get our podcast page to look like the rest of our site. One consequence of the popularity of blog software and other content management systems is that it’s easy to adopt the templates of the new software, because they tend to be okay (especially in the case of blog software), and it requires an additional step to change them. On our internal sites, I don’t mind some visual inconsistency, because these sites are intended primarily for our internal audiences. For example, our home page, library site, forums, and photo gallery all use different templates.

For our external, public site, the story is completely different. Our public face is a marketing piece designed to attract applicants, alumni, and prospective employees. The visual look does have to be consistent. Luckily, the Nucleus blog software I use for our podcast page has a very flexible skins/templates structure. Check out the resulting page, for which I copied the HTML from our main site and substituted Nucleus skin variables in the proper places.

The only catch was understanding the relationship between skins and templates in Nucleus. Skins drive the process, containing all of the HTML for the page wrapper — the main design of the page. However, the content itself is formatted using templates. So you call a function and a template from a skin. For example, the UHS skin I created contains the function <%blog(UHS|20)%>, which tells the software to display the first 20 blog entries using the UHS template. This template formats the pieces of the blog entries, such as the title, date, and body. There is an additional level of template formatting: when you call another function such as <%date%>, you must specify the date format in another part of the template, in order to define how the date is formatted. Otherwise, the date just comes up empty.

Although the built-in templates are great, full control allows you to fully integrate a content management system with the other components of your web site.

It’s time for us to replace our aging Sagebrush Athena library software. Commercial titles rule the school library space, although most are priced for larger schools and districts. We have found only two popular solutions, Sagebrush InfoCentre and Alexandria, that are priced appropriately for a small school such as ours. Our commercial experience with Athena left a bad taste in our mouth, as they did not upgrade the buggy web client for four years but rather released a new product (InfoCentre) that will cost us a thousand bucks to get via upgrade.

While adopting InfoCentre is the easiest path forward, there are several aspects of this choice that make us uneasy. First, will this product languish for years as did Athena? Second, the interface boasts an unchangeable bright green color. We would like to make our library online catalog integrate visually with the appearance and content of the rest of our site. Third, although InfoCentre would allow us to search the collections of other libraries, they have to also run InfoCentre for that feature to work! Why lock ourselves into that proprietary, commercial model?

Koha, the open-source library system, is seducing us like so many other open-source applications before. Koha offers all of the basic features of low-cost, commercial solutions. An OPAC web interface for user access to the catalog. A web-based librarian interface to track patrons and collection items. A “book list” feature for patrons to list the items they plan to check out or build a starter bibliography. “Virtual bookshelves” that either the librarian controls or anyone can edit — this will be most useful for teachers who want to build lists of items relevant to class research projects.

Critically, Koha also provides the openness and control that we are seeking. Template files for both the client (OPAC) and librarian interfaces are easy to find and modify. The software is written in PERL, dear to my heart, making it likely that I would be able to add special features we want myself. If it does not already exist, I could write a http request tool to add search results from public libraries through WorldCat to every catalog search. Finally, I am confident that I would be able to hijack the login scheme in order to integrate Koha into our single sign-on intranet web site.

Does the choice between open-source and proprietary change because I am leaving UHS in seven weeks’ time? If I can finish the installation and migration before I leave, then the school will still be better off than if I had helped them migrate to a commercial product. They will have free, working library catalog software with a pay support option available to them from LibLime should they need it.

What We Have Learned So Far

In two days of research, Nicole (our librarian) and I have figured out some of the basics about Koha. First off, Koha is the open-source project. You can download the package, review the documentation, or join their community by email (no forum, alas). LibLime is the commercial spin-off that provides pay installation and maintenance support. Too bad that their rates are a bit high: $0.02 per MARC record import and about $2,000 for an annual support contract. Looks like we’ll first try to go it alone.

Koha just held a user conference in Paris last week and is holding a developer conference there right now! The primary goal of the developer conference is to prepare version 3.0 for release. We were going to try installing version 2.4 this week but now plan to wait for version 3.0, especially because of this next issue. Z39.50 only works properly on Linux installations, not Windows. Z39.50 is the protocol used to download bibliographic information from the Internet — essential when adding new items to the collection. Of course, we have a Windows web server because of the ease of integrating web server authentication with Active Directory. Usually, this is no problem, but for this product it causes this significant feature hitch. We hope this will go away with version 3.0, which is using a different method (what is “Zebra”?) to provide Z39.50 support.

Koha lists the system requirements as Apache, PERL, and mySQL. I was hoping to use IIS, but the install docs indicate that .htaccess files are needed to set up some features of the site. IIS doesn’t use .htaccess files, controlling security through directory permissions. I will have to learn more about what the .htaccess files do and find out how to replicate these functions under IIS.

I would love to hear from those who have installed Koha and imported records from an existing collection. It would be even greater to speak with someone who’s done it on Windows Server with IIS. Finally, does anyone have a lead on whether the 3.0 release will make it on time? It’s exciting to think of the possibilities for our intranet.

GoogleFight