On catalogers, programmers, and user tasks
While prepping her final class plan for Organization of Information, the Loon had occasion to reread quite a few computer-programmer critiques of the MARC/AACR2/ISBD(G) data ziggurat.
Something struck her for the first time as she reread: nearly all examples of this genre that the Loon is aware of start with a sensibly-articulated patron-interface need. Not that there aren’t computer-specific considerations as well (e.g. indexing speed, desire to use machine-reasoning tactics), but library programmers seem admirably well-grounded in usability and utility concerns. Consider, for example:
- Jonathan Rochkind trying to help users narrow results with facets based on classification hierarchies
- The various user tasks articulated in code4lib’s list; not a single called-out problem is without one
- Bill Dueber differentiating between bindings
Whereas when the Loon nerves herself to peruse cataloger discourse (admittedly something she does only when she has no choice; she finds much cataloger discourse stifling, backward, and hostile—and when the none-too-kindly Loon finds discourse hostile, that says something), the rhetoric reminds her of the old lawyer saw “if the law is on your side, pound on the law; if the facts are on your side, pound on the facts; if neither is on your side, pound on the table.” Though for catalogers it should probably go more like “if the standard is on your side, pound on the standard; if tradition is on your side, pound on tradition; if neither is on your side, pound on the table.”
Nothing in all this pounding about the patron. Nothing whatever. When catalogers talk about patrons, they do so in the vague, underspecified fashion that Alan Cooper invented persona-based design precisely to escape from: patron as rallying banner, not patron as person. Nor does the Loon see nearly the effort from catalogers to test assertions about patron behavior that she regularly sees from library programmers. FRBR’s four user tasks, for example: how broad, vague, and untestably useless can one set of user-task assertions be?
Bluntly, the Loon doesn’t believe most catalogers when they talk about how present practice (and even some meditated future practice) serves patrons. (A few, e.g. Karen Coyle, assuredly have their heads on straight.) The Loon does believe programmers, because they show their work. She earnestly wishes catalogers would settle their feathers and believe programmers, too. RDA and BIBFRAME discussions would go ever so much more smoothly…
- A matter of emphasis
- The Loon’s job
Have to agree. I’m a Special Librarian that is trained in taxonomy work with a UX/IA background, and I struggle with the cataloging I have to do at work because so much of it seems arcane and does not directly influence what our users need. It helps other libraries and librarians that use the MARC system, but I have a hard time justifying it outside of that realm.
I don’t know if you saw my sequence of posts on bibliographic data, MARC and its vile progeny, Dublin Core’s dirty little secret and Has anyone, anywhere, ever read the whole of the RDA specification?, but they are much to the point. The core of frustration is that all these specifications are completely incapable of representing a perfectly simple journal-article reference. How is that possible?
(And, yes, I am writing from the programmer’s perspective.)
“None of them was designed for journal articles” is part of the answer to that, but your frustration is not unwarranted.
“When the patrons are on your side, pound on the patrons”? Ouch. :-)
There’s… some truth to that. “The user is not broken” did not emerge from vacuum, after all.