Crawford, 'Trust Us' URL: ftp://ftp.lib.ncsu.edu/stacks/serials/pacsr/pr-v4n04-crawford + Page 26 + ----------------------------------------------------------------- Public-Access Provocations: An Informal Column ----------------------------------------------------------------- ----------------------------------------------------------------- Crawford, Walt. "Trust Us." The Public-Access Computer Systems Review 4, no. 4 (1993): 26-28. To retrieve this file, send the following e-mail message to LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET CRAWFORD PRV4N4 F=MAIL. ----------------------------------------------------------------- Michael Buckland and other researchers at the University of California at Berkeley have been doing some interesting research with an experimental front-end to the MELVYL system, looking at ways to improve user success with online catalogs. Buckland suggested some changes to improve retrieval during a program on "The Evolving Online Catalogs," sponsored by the LITA Online Catalogs Interest Group at the 1993 ALA Annual Conference in New Orleans; he's also published various findings and suggestions. According to Xiao-Yan Shen's report on Buckland's talk (in the Fall 1993 LITA Newsletter, page 21): In order to make better use of existing catalog records we should have more powerful commands such as FEWER and SUMMARIZE. FEWER limits the size of retrieved sets by assuming reasonable default preferences--e.g.: find subject napoleon might retrieve 4,580 hits. Successive uses of FEWER might do the following: -limit to Berkeley holdings (2,259) -limit to English-language (853) -limit to last 10 years (73) -limit to last 3 years (30) -limit to books (26) SUMMARIZE finds all the subject headings in all retrieved records and lists them by their frequencies. MORE finds more books with the same author or subject. Tossing Fish to the Users There's not a lot to say about MORE or SUMMARIZE. I can't imagine that you'd offer MORE without asking WHICH author or subject, which means it's the same related-record function that Dynix has had for roughly a decade, and is also in Unicorn, Eureka, and several other systems. + Page 27 + My problem is with FEWER--not with the idea of reducing search results by offering plausible limits. That's a fine idea, and one that should be suggested (or at least offered as help) whenever a result exceeds some defined number of records. We do that in Eureka (RLG's new patron-oriented search service), and so do a fair number of other systems. What we don't do (and this is what I question) is give users an option like FEWER and simply apply some predefined set of limits, one at a time. That's tossing them fish, in the old adage. I prefer to teach them how to fish: show them what limits are available and how to use them and let the users decide what limits make sense. I don't mean to pick on Michael Buckland (although he's certainly able to defend himself). I think what he's suggesting is one common trend in hot new search-system design: giving the users "what they need" without telling them how they got it. Trust and Skepticism One crucial part of "information literacy," although it isn't mentioned much, is skepticism. People still tend to assume that if it comes from a computer (or if it comes from the Internet), it must be right--a disturbing and potentially dangerous assumption. In this instance, it's important for users to be able to understand how they are reducing the size of their results, as well as the implications of those reductions. Using the example above, is it really fair to assume that books about Napoleon written since 1990 are really more suitable than those written earlier? Why would that be true? If newer automatically means better, then I assume that the newest biography of Robert Kennedy is the best one--right? And if a user is looking for material by The Beatles and uses this set of FEWERs, he or she will be a bit dismayed by the results, which include none of the recordings, none of the movies, but probably some discographies or fairly arcane books about some aspects of the group's career. But look at the example again and explore it a bit in online catalogs. The worst problem here is that "Napoleon" as a subject search is pretty awful. In Eureka, it returns more than 1,000 subject headings as a word search and only four titles as a phrase search. So, if you've narrowed this collection down, what are these books about? Jose Napoleon Duarte? Napoleon Lajoie (American League batting champion in 1901, 1902, and 1904)? Napoleon, Ohio? The Code Napoleon? Napoleon II or III? Or, most probably, Napoleon I? + Page 28 + Have we really done the borrower a favor by turning a poor search into an arbitrarily small result, one that may or may not have much to do with what's wanted? Not in my book. Sorry, but I don't trust computer-controlled choices, and I don't think others should either. About the Author Walt Crawford, The Research Libraries Group, Inc., 1200 Villa Street, Mountain View, CA 94041-1100. Internet: BR.WCC@RLG.STANFORD.EDU. ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive three electronic newsletters: Current Cites, LITA Newsletter, and Public-Access Computer Systems News. This article is Copyright (C) 1993 by Walt Crawford. All Rights Reserved. The Public-Access Computer Systems Review is Copyright (C) 1993 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. -----------------------------------------------------------------