This is a nostalgic post; if you detest nostalgia, skip it. I was thinking about some of the 27 years I spent at RLG and some of the interesting things I did during that time. Not all, to be sure–I’ve forgotten a lot of it, sometimes deliberately (if projects never fail, you’re not taking enough chances…).
Specifically, I was thinking about how interesting it was to do what might now be called data wrangling–anything from large-scale data analysis and test runs through the grueling but useful task of session analysis (via log analysis). I did a lot of that during my tenure there (and some beforehand, to be sure–dating back to the days at Berkeley before I moved to the Library Systems Office).
Two fairly sizable projects have left semi-durable traces. I wrote a simple program to break down a batch of MARC records on a field-by-field basis: How often fields occurred, the total length of occurrences of each field, and the longest occurrence of each fields. Three big arrays in a fairly small PL/I program. In 1986 and again in 1988, we ran the program against a sample of more than 600,000 MARC records (the most recent 45 days of new cataloging and maintenance work on RLIN)
- The 1986 run showed up as several tables in Bibliographic Displays in the Online Catalog, published in 1986 (and coauthored by Lennie Stovel and Kathleen Bales). That book is based on another large-scale data analysis process, and I’ll get to that in a minute.
- The 1988 run showed up within a bunch of tables in MARC for Library Use, Second Edition, Understanding Integrated USMARC, published in 1989. Both runs came in handy when I was reviewing last year’s MARC analysis project–and unsurprisingly, field occurrence hasn’t changed that much over the last 17 years.
The second project was one that made a lot of sense in 1986–and probably no sense a decade later. Back then, you could assume that almost any online catalog display, whether local or (particularly) delivered over networks, would show 24 lines of 80 characters each, and typically require paging rather than scrolling to move up or down.
As part of a sponsored project, we wanted to look at a variety of possible catalog display formats given those realities–how they looked, how well they seemed to work, and how efficient they were (that is, how often you’d need to go to a second screen). We spent some time working on labels and various “kinds” of displays (e.g., cardlike displays, unlabeled displays, etc.). But we also knew that small-sample testing would yield useless results: Bibliographic data is heterogeneous, with records varying wildly in length and complexity.
So I prepared a program that could simulate a 24×80 screen for a given set of display criteria and run it against a large database–in these tests, either some 400,000 records (for all libraries) or roughly 40,000 (for a public-library subset). The tests were quite revealing–and, among other things, convinced me that “right-aligned labels” made the most sense for those fixed-width (that is, monospaced character) displays. It’s all in Bibliographic Displays in the Online Catalog.
Right-aligned labels? You’ve certainly seen them. Field labels all end at the same point,with a one-space gutter and field text following immediately thereafter. They’re extremely common in online catalogs. Stanford’s Socrates still uses them; so do, for example, Santa Clara City Library, my own public library, Cal State East Bay, UC Santa Cruz, Idaho State, Torrance Public, and many others. It had (and has) the advantage that you could simply ignore labels if you wanted to focus on the text–and that short labels wouldn’t get lost in a display that also had long labels.
I mention that in particular because I take partial credit for popularizing the idea, in my 1987 book Patron Access: Issues for Online Catalogs. It wasn’t my idea, to be sure, but I helped spread the word.
Anyway, back to the data analysis:
Those projects were public, eventually, A lot of others weren’t. From the beginning of Eureka (RLG’s end-user search system), I used data analysis and log analysis to try to improve the system. Session analysis–recreating the steps of a search session through anonymized log data–is slow work but can be incredibly useful. That was most evident in a set of upgrades during the pre-Web days of Eureka–changes we called the “Do What I Mean release.” We were able to reduce the “error rate” of users in a command-driven system from a fairly significant proportion of commands to a rate so low it was hardly worth tracking, mostly by finding common ambiguities and dealing with them appropriately.
I continued to do log analysis and session analysis in the web version(s) of Eureka and was able to get some interesting results. Most of that’s disappeared, along with the system itself. In any case, since the data analysis was being done specifically to try to improve a system, it didn’t result in formal publications.
Maybe this post is triggered by a recent discussion elsewhere on evidence-based librarianship–including the notion that maybe wonderful new possibilities shouldn’t be hampered by a desire for evidence that they, well, actually do anything. That gets into a whole thicket of issues–do we know what to measure? what constitutes success? is it OK to use evidence of disuse to shut down old services–that I don’t want to get into. Mostly, I remembered that I spent a lot of time, probably several working years in the aggregate, finding and analyzing evidence. I like to think I was damn good at it. (I suspect that, with today’s tools and computer power, I could be even better–although asking the right questions is still the most important part of such research.)
Yeah, I still play with factual research, having this foolish belief that facts matter. But it’s at a different scale and with different tools. And what I do is pretty much public; that’s an improvement.
