25 January 2010
Here, we have an ethnographer talking about why (outside of academic/elite contexts) Google is not widely adopted in China. (A variety of reasons: the Google name is hard to pronounce and spell in Chinese and there is not a widely accepted, Google-promoted canonical form; many, many users have their primary internet access through mobile technologies and are accustomed to an instant-messenger/Facebook-like paradigm, not an email/browser paradigm; Google is identified with a set of western values appealing to elites, but not appealing to the majority of the population, particularly in the presence of a heavily marketed, nativist alternative; Google hasn’t done a good job of outreach and market positioning vis-a-vis these difficulties.)
And here, we have an oncologist blogging about how he doesn’t (any longer) need to use particular library services, and ways proactive and tech-savvy librarians could insert themselves into his workflow, helping him while raising their profile. The thing I really liked about this post is that it’s an outside perspective on what the information workflow looks like — I think it’s too easy to just see our own parts of a workflow (and there’s a lot of information workflow in a library), but the library-external parts are where the new opportunities for relevance are. It’s a good reminder of the importance of having good relationships with your patrons and seeing things from their perspective, seeing where the needs are instead of hypothesizing about what they might be.
I read this article first, closed the tab, read a dozen more tabs (oh, eventful week, how you have destroyed my tab-reading flow), got to the one about China, and thought, hey, this is the same thing. Here, too, Google has its set of habits and expectations, and is finding itself irrelevant in a population which has a very non-complementary set of habits and expectations.
I’m looking forward to being a liaison between the library and…some outside, whatever it is. Seeing that outside’s perspective. Is this some sick, twisted aspiration — will it all just be herding cats? Still. There are reasons for the tagline Across Divided Networks.
7 January 2010
So my husband (a software engineer) and I talk a lot about this library stuff, duh, and it’s useful for exposing underlying assumptions that differ between these two fields of information geekery…
One of the things I’ve been thinking about is the structure of open source development communities. I’ve run Linux (albeit no more) and a lot of my friends are the kinds of codemonkeys who will merrily write a script when the world doesn’t do something they want it to do. I’m used to thinking of open-source development as people encountering things that are personally bothersome and fixing those themselves, when the software in question is something computer geeks use — Linux, Apache, funky lightweight apps to do whatever, et cetera.
But the assumptions in my head about how Koha and Evergreen and OPALS are developed are, I realize, different. I think of integrated library system development and I think of a small number of coders — from library consortia, academe, and ILS support companies — contributing to the codebase; I think of the vast majority of (potential) users as simply not having the ability to do that. In other words, I think of there being some latency and information loss in the communication between user and developer in a way there’s not with, say, Linux (where user and developer are the same person). In fact I imagine it must go both ways — that developers are not necessarily embedded in a library context (e.g. if they work for support companies) and therefore may not be heavy users of the system, and may not be developing that sort of intuition for the workflow imposed by the system.
Am I right? Am I wrong? Because I really have no idea, and it’s fun to use the blog as a way to learn things. (Thank you to all my lovely commenters who have pitched in on this. 🙂
It seems to me the nature of an open source development community, and the possibilities for the software, must be interestingly different depending on how greatly the user and developer communities overlap, but I do not really know how (aside from the suddenly crucially central role of support companies in the low-overlap case). Certainly, though, the idea that if software is broken or stupid you cannot just write something to fix it is a paradigm shift for software engineers, but not for librarians, which does complicate some of these conversations.
12 October 2009
Chronicle of Higher Ed article on discovery layers in library catalogs. Doesn’t say much I haven’t already seen (although if you have no idea what I mean by “discovery layers” do read it; it’s a good overview). I did like this bit, though:
“It’s sort of our answer to, Why it is you need a library when you have Google?” said Ms. Gibbons [vice provost and dean of the University of Rochester’s River Campus Libraries]. “What this is going to do is show how much you’ve been missing.”
Positioning libraries to stay relevant is, of course, a major obsession these days, and I liked how she phrased it — not exactly as “let’s present ourselves in ways that are familiar to the users” (although I do think that matters), but “by presenting ourselves in ways that are familiar to the users, we can better showcase ways that we are already awesome.”
Comments section is kind of disheartening. I shouldn’t be surprised that the demographic that reads the Chronicle is the demographic that is conversant with old-school catalog searching ;), but so many of the comments read as “fix the user, not the catalog” and…that just never works. Even if the user is uneducated about, e.g., subject headings (and let me tell you, one semester of library school showed me it is amazing how undereducated you can be about catalogs after even a humanities MA), even if the existing technology works really well once you put in the time to learn it — fixing users just never works.
It would make me sad if discovery layers made it impossible to do the sort of precise, controlled searching library nerds get good at, but another of the lessons of Google (or, for that matter, of any number of intimidating databases) is that your clean searchbox doesn’t mean you can’t have that functionality. But if you say to users “you can’t even play until you’ve spent a couple hours learning how” — well, just like my last post — that means there will be a lot of users you never get at all.
Make it easy. Or, at least: make the first hit free.
9 October 2009
I was at the NISO forum with my Library Automation class yesterday. Couple of interesting talks, particularly Annette Bailey‘s, and my notes have all these “blog this!” memos, none of which I’m blogging about right now because it turns out what I’ve been thinking about overnight is how her presentation reminded me of a chat I had with Jon Herzog once about women (or, more particularly, the lack of them) in CS.
One of the things that struck me about Bailey’s talk is that she’s made geniunely interesting and useful widgets, but she characterized her programming knowledge in very modest terms — not much above what I would use to characterize mine. And it was eye-opening to me that you can actually do something worthwhile without being some kind of a ninja.
Because my experience of programming in high school and college was that you could learn a little bit of code, and then make something that didn’t do anything useful, assuming it even worked, which, if it was one of those BASIC things out of a magazine, it usually didn’t. (“Hello, World” is charming, but not fulfilling.) And all the people who were actually doing interesting things with code knew multiple programming languages, and OSes, and had knock-down drag-out arguments about which commands were better in which situations and why. And, indeed, the ability to have those sorts of arguments seemed like the marker for membership in the club. And I didn’t want to be in the club, because arguments like that don’t play to my strengths, and anyway it seemed a bunch of obnoxious posturing. And if the bar for being in the club was that high, I was so far behind I might as well give up and do something else. So I did.
(Oddly enough, this hasn’t been my experience of post-collegiate code. I taught myself enough perl one summer to limp along making something partway functional. And I was able to do something actually useful and comprehensive for my databases class with shockingly little SQL and PHP. But mentally, I’m still in the “not a coder” camp.)
“Make it easy,” Bailey said. She can figure out enough stuff to do what she wants to do in a world without standards or APIs or any kind of handholding. She’s not dumb. But she just wants to make a damn widget to extend user experience in the midst of a busy job that doesn’t pay her to be a full-time programmer. She doesn’t, it seems, want to have to be in the club to make something meaningful.
And neither do I. And I don’t think I realized before last night that being in the club, and being able to do something worthwhile with electrons, aren’t the same thing.
18 September 2009
In my Library Automation class yesterday, the concept of satisficing came up.
Digression: satisficing is where I feel most acutely the cultural conflict between the librarians I read and talk with in school, and the software geeks I socialize with. So any time that comes up, there’s a lot going on in my head.
Someone noted how the nature of research was changing as new search tools become available — not, to be tactful, that the quality was suffering, but that people are drawn to accessibility over exhaustivity. A favorite classmate of mine leaned over and said, “How is that quality not suffering?”
Well, class is not the time to go into that, but here’s my answer to her:
Making search easier, making records and then content more accessible, means that more searches come up with something. It means that people are more prone to treat searching for information as a realistic tactic. It means that the generation of ideas, and the development of content and other products based on those ideas, is easier. It means we will have a world with more generation, more creativity, more content, more entrepreneurship.
And that content will cover our world with information kudzu which, like kudzu, will often have to be macheted away. Some of that content, those prototypes, those ideas, will be horribly flawed (broken, misleading, decontextualized) because they were based on incomplete or inaccurate information. But sometimes, the idea that exists, the product that exists, even if broken, is better than the idea or product that does not. I’m typing this on a browser with bugs on an operating system with bugs on hardware that’s getting increasingly apoplectic, but my life is better for having these.
So satisficing, yes, you are my little love for what you bring to our lives. But I think the cataloguers and old-school library theorists of the world have a very real point as well when they decry you. Because sometimes, the incomplete search really isn’t enough. There are objectives and applications for which good-enough is good-enough, but if I’m talking academic research (at least, past the undergraduate level)? If I’m talking, good heavens, medical research? Intelligence and security work? I would really rather the investigators not satisfice. And to this extent, the easy availability of patchy search, the least-effort temptation, really is a problem, and even a threat.
So there you go, M: the answer behind my expression.
13 August 2009
I’ve just started reading Tyler Cowen’s new book, Create Your Own Economy. (That is to say, I’ve just finished Chapter 1.) I should preface this by saying that Cowen is one of my great intellectual crushes and his blog, Marginal Revolution, has taught me a lot and strongly influenced my thinking on some matters (as well as introducing me to one of my other great intellectual crushes, Sudhir Venkatesh). And I say all of these complimentary things because I’m going to spend the rest of the post cranky.
Chapter 1, roughly speaking, is about two things: the information explosion in modern society, including the tools that both generate and help us manage it; and the autism spectrum as a frame for helping Cowen understand his own thinking, and all of us better manage that information explosion in our own lives.
Now, I’m fascinated by the autism spectrum. I will download/read anything I come across with Temple Grandin in it, I’m fascinated by the way non-normative minds both illuminate the norm and broaden the meaning of humanity, and reports (particularly self-reports) from that spectrum tend to be the most personally gripping of all dispatches from non-normative terrain. But I can’t stand the way geekdom, a few years back, flocked to the spectrum — or, rather, the metaphor of the spectrum — for self-understanding. There’s a reason the DSM includes differential diagnoses, and therapy, outside (and perhaps neutral) observers. The faddishness of self-diagnosis, the appropriation of the metaphor as an explanation (or perhaps excuse) for oneself without the actual diagnostic process and its consequences, the cherry-picking of personally useful or (dare I say) sexy elements of a descriptive sketch on a web site without taking into account the full picture…right. Drives me crazy. For all that it’s a fascinating spectrum and, even, sometimes, a great metaphor.
And then (page 9!) I hit the word “catalog”.
Librarians have a passionate conversation going on the nature and meaning and management of information overload. Part of this passion surrounds the idea of cataloguing. And one of the key things here is — a lot of librarians get apoplectic about the lack of cataloguing online (in the very services Cowen refers to — Flickr, del.icio.us, iTunes, among others. Cataloguing’s a technical term, a technical idea in librarianship. It involves high (often very exacting) standards for metadata which facilitate precise and comprehensive searches. (Which are, really, often neither as precise nor as comprehensive as some librarians would like to think, but let’s leave that aside for the moment.)
Cowen sees a world of technical tools helping us to manage information overload…I see a world of tools which, don’t get me wrong, I spend a ton of time on and am madly in love with, but which create as many problems as they solve in that. I can get freakishly excited about crowdsourcing and folksonomies and what-have-you, but they also have very serious flaws with regard to some of the problems that cataloguing, in the librarianship sense, aims to solve. The tools we have now are very nascent. Our ability to organize information with them is in some ways very limited. (Why does my iPod have three different genres with names like “Electronica/Dance”, except differently punctuated? Did the geeks at the wedding I was just at get around to creating a hashtag for their photo uploads of the event — and if not, how will I find out what happened after I left, and even if so, how many sites is it scattered across, and how many photos will I miss because they missed the message? Why does my task management software not freaking integrate with my calendar?)
The fact that I can even ask these questions is, don’t get me wrong, pretty cool. This sort of participatory, decentralized information culture is going to lead us in all sorts of great directions, even though few to none of them will, I expect, resemble cataloguing (and somewhere in the dusty corners of librarianship, people will be shaking their fists at the sky about this). But Cowen’s view of what is going on in information tools is so very, very different from a lot of the views I encountered in my Information Organization class.
And that’s the other thing that made it hard to read this chapter — hard because some little bat of an idea was beating its wings against the cage of the book, wanting to argue and break and go off some other way. It’s one of the major difficulties I had in 415 in reverse. In 415, I read librarians’ conversations on these themes, and they had so little in common with conversations, on the same topics, that I’ve seen socially, in the worlds of computer geeks and online communities; I kept ranting at the papers I was reading, when they’d say something was obviously impossible but I could point to real-world examples, when they’d make statements with fundamentally different assumptions than those I’m used to seeing and take them as absolute truth. And here, I read Cowen’s piece of the conversation, and it has so little in common with what librarians have to say. “Libraries” appears precisely once in the index (page 43!). A brief scan of the index suggests that none of the philosophies and technical contributions of librarianship make an appearance in this book at all — and Cowen has a tremendously wide-ranging intellect and is a heavy user of his local libraries. Among non-librarians, he seems one of the most likely to really know things about library ideas.
I kept having the feeling in 415 that if librarians and non-librarians are having separate conversations about information tools, culture, philosophy — and if non-librarians are the ones out there generating and using the tools, with or without the theories, in a flawed but fecund creative explosion — then librarians, convening slow committees to generate precise tools — will be obsolete and never even notice. Cowen’s book, thus far, does not bode well for this.
How do we bridge those divided networks? How do we bring some of those conversations, and conversationalists, into a common sphere?
21 July 2009
The always fascinating David Weinberger blogs on transparency vs. objectivity. Worth reading the whole thing — the argument gets deeper as it goes along. But here’s the part where I really started thinking:
Transparency prospers in a linked medium, for you can literally see the connections between the final draft’s claims and the ideas that informed it. Paper, on the other hand, sucks at links. You can look up the footnote, but that’s an expensive, time-consuming activity more likely to result in failure than success. So, during the Age of Paper, we got used to the idea that authority comes in the form of a stop sign: You’ve reached a source whose reliability requires no further inquiry.
Hence — to move the opening sentences from that paragraph to the close:
We thought that that was how knowledge works, but it turns out that it’s really just how paper works.
Of course just about anyone nerdy enough to chase footnotes knows that appeal to authority is a fallacy, but he’s got a point there: when it’s hard to do, you’re more likely to rely on the authority of the source, to seek out authorities who are trustworthy (or who have a cultural aura of trustworthiness clinging to them, like his newspaper example — at least for certain newspapers), and to have an intellectual edifice that depends on your ability to, well, trust without verifying. Blogs let wacky opinionated perspectives proliferate, but linking and searching substantially lower the cost of verifying, so objectivity’s role and importance decrease.
(The searching is key, though — link ecologies can, I expect, be navelgazing, and they often do a poor job of getting beyond our love of confirmation bias…)
So where’s the library connection? Libraries have historically been, I think, edifices built on objectivity. We’re the neutral observer. We’re the place you can trust, full of the sources you can trust. Authoritative knowledge! Come and get some.
I come across a lot of articles in my class readings written by librarians who are clearly getting the thrashing heebie-jeebies from this transition away from objectivity (and also, as it happens, comprehensiveness). Tagging, from faceless wild-west Internet crazies, versus sober and structured subject headings, assigned by trained experts? Wikipedia…(same argument)? And I admit, when I was teaching, it was frustrating to see my students head straight for Google when we went to our beautiful library with its excellent collection…
…but it wasn’t because they were going to Google over books; it was because they were going to Google without having developed the sophisticated cognitive apparatus you need when you can’t just trust a source. They didn’t have tools for evaluating the reliability of sites, nor even for situating their content within a broader body of knowledge they could have used to do that evaluation. Appeal to authority is lame, logically speaking, but it’s a good starting place while you work on appeals to your own intuition.
Anyway, that’s a digression. The point is, libraries have, I think, bought heavily into this culture of objectivity — historically, culturally, even architecturally. Many librarians relish their roles as gatekeepers, want the catalog and metadata that give you brilliantly precise searching if only you will master idiosyncratic syntax — and then bemoan users’ tendency to flock to an unadorned search box and keyword-search without a delimiter in sight — something they can do by themselves and, increasingly, anywhere.
I don’t think a lot of librarians, or libraries, know how to position themselves in this shift. So, ideas? What’s the role of a cultural institution, a neoclassical edifice, a, dare I say, neutral authority in a world of omnipresent always-on kudzu-like explosions of transparent information? Can the question even be answered with that set of adjectives and nouns? If not, how do they change?
12 July 2009
The part I’ve been munching through: apparently it’s really, really hard for libraries to keep track of their electronic serials and database usage. If you want to know which of the things you’re subscribed to are actually getting used and how (and what it’s costing you), strap yourself in for a long ride, because ILSes don’t have rich enough functionality to harvest that information for you. Some people buy additional systems on top to help, but even those require a lot of work if you want to extract useful data.
There are some good reasons for this. Libraries frequently subscribe to databases or journals as bundles (and may be required to do so by the publisher), and the usage codes may not disaggregate resources within the bundle. Libraries may subscribe as part of consortia, but need to extract data for their individual institution.
Still, though. This seems like a pretty obvious thing to want to do — keep track of your actual use! So why do the tools not support it? I welcome ideas from people who actually know something (which is not me!), but in the meantime, I’ll brainstorm some possibilities…
- It’s a genuinely hard technical problem. (And there are a lot of problems that need to be solved here — not just capturing the data, from subscription systems that apparently don’t natively provide it, but organizing it into a database that answers users’ questions, has a usable front end, and spits out data in formats useful for budgeters and other decisionmakers. That’s not one system — that’s multiple interacting systems, possibly produced by different organizations — and potentially problems that have to be re-solved for every database vendor and ILS combination. OK, it’s even harder than I realized when I started this bullet point and was just thinking about algorithms.)
- Libraries don’t prioritize recordkeeping and review of their serials and databases enough to exert pressure (market, social, cultural) on companies to develop this feature.
- ILSes offer a tremendous number of features; while libraries might want better serials tracking, they care more about those other features, so it’s those things that ILSes are competing on. (Although this doesn’t answer why an ILS that does well on those things, *and* on serials, doesn’t emerge and stomp on its competitors. But maybe it’s too hard (algorithmically or monetarily) to do that.)
- This is a place where the culture clash between librarians and programmers is showing; maybe they just aren’t talking to one another enough for the user needs to become apparent. Again, you’d think this would be a place where the company (or open source project) that does do a good user needs analysis to eat its competition — and there are niches where librarians and programmers overlap — but all too often they don’t seem to even have a common vocabulary.