Things have been moving along very well in the Evergreen development project since my last PINES Executive Committee Report. We are now actually ahead of schedule and the project is running more smoothly than we initially expected and planned for. We hope this bodes well for the rest of the project.

Many important things have occurred this week. First, we have released the “pre-alpha” OPAC to the PINES Subcommittees and Executive Committee for review. (We are also referring to this release as the “Demo OPAC”). The purpose of this OPAC release is to gather feedback from the PINES libraries, and to gauge if we’re heading in the correct direction. So far, the comments have been overwhelming positive. Note that this OPAC demo is only accessible from Georgia public libraries. The link for the PINES version of the OPAC demo is: http://spacely.georgialibraries.org/OPAC/ NOTE: the demo period for the OPAC is complete.

Secondly, on a parallel track, we have also released a public version of the OPAC demo that is accessible from anywhere. This OPAC is hosted on a much smaller server and has a small database, but the basic functionality is identical. Its purpose is to gather any feedback that may come from non-PINES folks. The address for this public version of the OPAC is: http://spacely.georgialibraries.org:8080 NOTE: the demo period for the OPAC is complete.

On a third front, we have released our first batch of source code. This first batch of source code contains some of our core transport and foundation code. More technical folks may wish to download it from our download section.

There are some specific OPAC functionalities that I’d like to point out. Note that we designed this OPAC using the focus group notes as guidelines, and the vast majority of this functionality comes directly from those notes:

Ability to see call numbers and information for local copies as soon as possible.

Grouping of various editions, formats, and versions of a title together under a single “meta-title”. This functionality, as you may imagine, is particularly difficult to manage, and it isn’t working as well as we would like. It does work most of the time, but it fails in some cases. Typically, this is because of incorrect or incomplete MARC data. With more database cleanup and further refinement of our matching algorithm, this will get better.

Forgiving misspellings. This functionality is available in a rudimentary form now, and we plan to further tweak and enhance it.

Ability to use the browser back and forward buttons.

Added content such as cover art. We are examining 3rd party offerings of cover art and book reviews. In this demo, there is cover art available.

The libraries are listed in alphabetical order.

The OPAC is browser independent.

There are no session timeouts. However, we are considering adding session timeouts in the future to sensitive areas such as the “My Account” area.

ObCSSPedantry: I’m really surprised to find — especially given the complex XUL skins you’re working on — that your demo’s stylesheet has no attribute set for the body element’s background-color attribute. Yes, I’m the kind of person who keeps their default background set to the classic “silver” color just so he can catch people doing this. Also, while you’re to be congratulated for ending your font-family list with “sans-serif”, I must say “Boooo!” to putting Helvetica ahead of “Bitstream Vera Sans”, which is the /de facto/ Standard Sans Serif Font on the free Unices these days (and far prettier than the ancient Helvetica Type1 that X comes with) and “Extra Boooo!” to setting the font-size to “x-small” (really, really bad accessibility there).

Shawn. Thanks for the input. We have to keep in mind, however, that the purpose of this demo was primarily to allow users to test the functionality of the OPAC. As far as the design goes, we will likely be requesting artistic/design input from external sources. For example, there will be different styles for accessibility, different graphics, different fonts – you name it. In other words, much of what you see in the current demo will change. I was curious (for my own sake) how you would suggest solving the font size issue (i.e. default fonts are usually big and ugly). I was able to train Mozilla/Firefox quickly, but IE seemed to ignore (or abuse) much of the font CSS I tried. Just curious…

I installed the snapshot on Debian testing without much trouble. The important packages to apt-get are mysql-server memcached libdbd-mysql-perl liberror-perl libcache-memcached-perl. You’ll also need the experimental jabberd2-mysql package (search at debian.org), which requires libidn11 libmysqlclient12 libpam0g zlib1g. There may be other perl modules that I already have installed that you’ll also need, the form is usually lib{module-name}-perl, or you can search for it or use CPAN.

By the way, is there going to be a openils-users or similar mailing list?

Yeah, I was thinking about the “only a demo” thing while I was typing, but I also thought “well, demos are supposed to show where you’re going”, so I commented anyway.

I’ve tried to come up with an answer that doesn’t sound either wholly dismissive or like spew from Jakob Nielssen (of whom I am not fond), but I don’t think I can. The truth, so far as I can determine, is that if you are going whole-heartedly adopt the use of CSS for style and conformant (X)HTML for content delivery, you cannot “solve” the font size issue. You have to accept that the user may have some completely ridiculous default settings which make your page look like something done by a fourth grader with a copy of Dreamweaver.
If you compensate for possibly-huge default fonts by slamming the size of the whole page down, you make it impossible to read for people with rational font sizes.

But your target user is a library, so (stop me if I’m going off the rails here) I’d think that it might be mostly safe to assume that the default font size won’t be 800px. Also (honest question) what does IE matter? XUL doesn’t work there any more than ActiveX works in Firefox, so I had assumed that dealing with IE’s hideous CSS quirks wasn’t an issue. It certainly would make things easier.

I’m probably just insufficiently informed of what’s actually going on, and I’m a spec-loving pedant by nature (but a spec-loving pedant who’s been out in the trenches). I’m totally cheering you guys on; I still can’t believe that UGA is actually doing something *right*.

Shawn. We appreciate your feed back very much, so please keep it coming. Unless/until we have a UI designer we will need that kind of feedback in order to make everything look good. The core team here are system level developers. We make it work and then get help making it pretty.

The reason that we’re worrying about the default font issues in the demo is that the OPAC will be web app, and since (perhaps unfortunately) IE still has around a 90% share of the browser market we have to think about it. We designed the site in Firefox, and realized it looked in IE — as you put it so well — like it had been designed by a fourth grader ;). We went back and attempted to find a happy medium and discovered that, as Bill said, that’s a HardThing(tm).

Our staff client, the software used at the circulation desk and by the catalogers in the back rooms, is what will be written in XUL and will be much easier to control as far as the layout and styling is concerned.

Again, thanks for the feedback, and check back later for updates. It may be a while before the public demo is updated, but we’ll try to get as much user feedback regarding UI tweaks and usability issues incorporated as we can.

Shawn, one small correction: we’re not UGA, we’re the Georgia Public Library Service. We’re actually a sister agency to UGA; we’re both administratively under the Board of Regents of the University System of Georgia. (That agency is over all public universities such as GA Tech, GA State, etc.) UGA and the other academic libraries are part of another library system, GIL, and are currently not participating in this project.