Caveat Lector

Walt’s got a terrific back-and-forth on Wikipedia in this month’s Cites & Insights (and do I need to remind everyone it’s PDF? didn’t think so). It’s comprehensive, it’s fascinating, it’s occasionally snarky in the best possible way, and you should all go read it. I don’t have anything much to add to the burning question of Wikipedia’s inherent, contingent, or comparative merits or defects; we all pretty much know what I think already.

That said. Conspicuously absent from the librarians’ corner of the discussion is the merest hint of “Gee, what could we do to make Wikipedia better, or make something that’s better than Wikipedia?” Neither the Wikipartisans nor the deWikitractors (dear me, that’s a horrid coinage; sorry) can seem to find this mode of discourse—the builder’s mode, the architect’s mode, the designer’s mode.

I hate to keep harping on this, but it keeps smacking me in the face like a wet fish—and that fish gets raggeder and smellier every time I’m smacked by it. We have options other than merely accepting or rejecting. We can also build. We can also publish. We can also guide. Why aren’t we?

Along similar lines, Walt mentions a library blogburst on the topic of searching, how we love it and nobody else does. (I think Erica started it, but I could be wrong.)

I’m going to be a contrarian here, because every single other post I’ve read takes “librarians love searching!” for granted. I hate searching. I’m learning How To Search Good this semester, and I’m thrilled about that, but I’m not thrilled about it because gee, now I get to go do more searches! I’m thrilled about it because gee, now I won’t have to spend so much time messing with grotesque search interfaces! Which is, I need not say, exactly how our patrons feel.

Again, nobody seems to be thinking about how to build tools that take the hard-and-ugly out of searching. How to hack search, in the O’Reilly Hacks series sense, the sense in which I hack markup—I could do every angle bracket by hand, but why would I when I can get the same results much quicker with a regular expression or three?

I mean, take the tried-and-true machete-search technique we were just taught a week ago: you divide your query into concepts, brainstorm plausible synonyms for each concept, then boolean-OR the synonyms and boolean-AND the synonym groups. It’s easier to do than it is to explain, and it works right beautiful.

But, sheesh, booleans? Give me three text boxes on a search page, and ask me to comma-separate some synonyms. Then do the ANDing and ORing for me. Will it work for every search? ’Course not. Does it hit a useful 80/20 point, even for librarians who know better? I rather suspect it might. Would it be easier to train a patron to use those boxes than to use booleans? I’d guess so. It’s a hack, it’s a kludge, it’s ugly, it’s an abomination to the librarian mind—but I could build it, and I’d put money on it getting more people to better information.

But we won’t build it, because we don’t build. Pity, that.