Breaking the ALA cycle

If you've ever been on a committee that ties its work to the library association's two-times-a-year cycle, you know how frustrating and inefficient that is. With only two working meetings a year it takes many years to get anything done. This accounts for some of the slowness of the accomplishments of our profession. And obviously that pace is not serving us well in this fast-changing world.

As proof that it can get better, I cite a recent project I was on that was organized by the ALA Office of Information Technology Policy. Our goal was to produce a set of principles relating to digitization and digital resources, to get those principles reviewed by a wide professional audience, and to have them passed by ALA Council so that they would enter into the ALA Handbook as association policy. We did it all in barely over a year by harnessing the (less than perfect) technology of the ALA web site. Essentially we placed our principles on the ALA Blog and sent email to all ALA units asking for comments. We had prepared the way by visiting numerous meetings at ALA in Seattle but definitely had not managed to contact every potential respondent. Over two months there were thousands of viewings of the principles and many dozen comments. We also received comments via email. By the time we presented the principles at ALA Council in Washington, D.C. we had some major groups signed on as supporters, including ALCTS and LITA. We also had visible proof that our work had been made public and reviewed.

This was a relatively small project, but it gives me some hope that we can break out of the cycle of working on ALA activities for only four days twice a year. If we are going to move our profession forward, we have to be able to harness the technology to get needed work done. Blogs, wikis, shared editing of documents -- if we do it right, the two meetings can become times when we get face-to-face with each other for the pleasure of each other's company, and not to sit in a windowless room editing some document by committee.

Grace Hopper's Stone

Whenever I visit Washington D.C. I try to find time to go to Arlington Cemetery. I don't visit the famous graves. Instead I trudge along the main road to a point at the far corner overlooking the Pentagon, which is where my father is buried. Well, in-urned, actually, since he was not important enough for an actual burial. In the military, you carry your rank with you to the grave, literally.

It so happens that I pass by the grave of Grace Hopper on the way to the columbarium, and I always stop and pay my respects.

Arlington is nothing if not military. All of the headstones are identical (with a few famous exceptions), and no decoration is allowed. There are particular occasions on which you can leave flowers or flags (like Memorial Day), but the rest of the time it's just green grass and white headstones. So people have a habit of marking their presence by placing a small stone on top of the headstone. I find it to be very touching, a tiny bit of civil disobedience. I don't think I have ever been to Grace's grave when there wasn't a stone on it. To me it's a great reminder that others also visit her and care. So here is her current stone. And if you visit, please clean the bird crap off her headstone, and add a pebble if you can find one. (She's located at 59-973)

Some quick notes from ALA

Catalog front-ends are the new kids on the block in the exhibits. You can see Aquabrowser, Endeca, Primo, and others. It's clear that the separation of the user interface from the ILS is well underway. Aquabrowser has a new product for small libraries called Aquabrowser online where they will host a library's front-end for a monthly fee. This might be a great way for libraries to try out a front-end without having to make the full commitment of a purchase. It would also be an excellent way for a library to show its board the possibilities before asking for an allocation of funds.

There's a lot of buzz about RDA which is now looming on the near horizon. Work is going forward to begin training and implementation plans. At the same time, I have yet to speak to a cataloger who thinks that RDA is workable as a set of cataloging rules. I suspect that what has happened is that the JSC, in its desire to define a neutral set of data elements, has created a product that is neither a rigorous set of data elements nor a set of cataloging rules. I can't help but see this in familiar terms: "stay the course." In other words, we've gotten ourselves into an expensive mess that we can't easily get out of. To admit failure is unthinkable after all of this time and expense. At least the RDA process isn't creating actual casualties. I blogged one of the RDA sessions at the ALCTS blog: http://blogs.ala.org/digiblog.php.

And if you think that e-books are dead, you should visit the 20-some booths exhibiting e-book products, as well as audio books. OverDrive is now serving up movies and games along with its e-book products, all mainly used by public libraries.

Google is here with one of the most mistaken campaigns I've ever seen at an ALA. They are holding a "find the info" contest that starts out: "You're an undercover government agent. Your mission, should you choose to accept it: find the info you need, and find it fast." Don't they know the history that libraries have with "undercover government agents?" However, there are prizes, so I assume that librarians are playing along. It's amazing what people will do for a free key ring or a post-it note pad.

Privacy Audit

I had the pleasure of working with San Francisco Public Library on an audit of their records relating to patrons and patron activity. This doesn't sound like an exciting activity, but in fact the staff I worked with there really got behind the project. Basically, we (they, really) ferreted out all of those nooks and crannies where patrons sign up for things, or where they leave some footprint in a system or on a sheet of paper. We looked at remote services and ad hoc practices in the branches, including use of things like MySpace and instant messaging to communicate with teen readers. There were some surprises (mainly files in the desks of those folks who feel they have to keep everything, just in case) and a few sticky issues (what to do with held books that are placed on public shelves? Use the patron's name? Use the patron's library card number, which they usually don't know?).

The final report to the Library Commission is online as a PDF. The actual results of the audit ended up being over 80 pages, with copies of all of the forms and all of the printed and emailed outputs from the library. You can see the blank forms that we started with here. And this is the Word template that we used for the final audit results, one page for each document or system. In my copious spare time (which seems non-existent at the moment) I will try to mock up a few filled in forms so people can see what the final data looks like.

In any case, here's a library that can now say "We know where our data is, who has access to it, and how long it is kept." That's pretty good.

Google source

I may be the last person to discover this, but I was alerted to the oddities of Google's "html" source in a book that I picked up in Turin -- one that is definitely critical of Google, but in a decidedly European way (where else could you find that there are numerous Marxist criticisms of Google and its power over information?). So I now ask you: have you looked at the source code for Google's pages?

First, do this: run your mouse over the buttons on Google's home page. (There are only two of them.) We've all had drummed into us that every .gif needs an alt text for the purposes of accessibility. Hmmm. No alt text appears.

Now, look at the source code to confirm that the buttons don't have alt text. Hmmm. No buttons. At least, no "img" tag. There's a lot of code here, and I can find this:

<input name=btnI type=submit value="I'm Feeling Lucky">

But there's very little here that I recognize as standard html. I tried running some basic accessibility tests on the page (I'm no expert in this area, so my tests may have been too simple) and there were some errors, but none of the ones I saw were considered terribly important. I don't know, however, if the accessibility testing software understood the Google source code, nor if typical screen reading software would be able to determine from the code that there are buttons and that those buttons have names. So if anyone has any insight into this, I would be very interested to hear it.

Note that all of Google's pages seem to use this non-html style coding. I'm willing to believe that it is more efficient this way, but I wonder about what it means for compatibility, for competition, and for users.