Christina's LIS Rant
This is my blog on library and information science.
Profile
Christina K. Pikas is a science and engineering librarian in a special library as well as a doctoral student in information studies.
Any opinions expressed here may not even be her own and certainly do not represent those of any organization willing to be affiliated with her.
Search
Recent Posts
- Science journal publishers experimenting with different models
- Is the run away from “librarian” and “library” a conflict between 2nd and 3rd wave feminists?
- Oh crap. Guess I should have renewed on time.
- From PostSecret
- OOI Science Community Workshop, day 2
- OOI Science Community Workshop, Day 1
- Innovating in infrastructure in a research organization
- COTS software are not off the shelf or turn-key
- Free IS and CS books online
- 4S Day Three
Recent Comments
- movers in Washington on OOI Science Community Workshop, day 2
- Alison on Oh crap. Guess I should have renewed on time.
- John Dupuis on Oh crap. Guess I should have renewed on time.
- Corky on The new name for SLA: will it divide us instead of uniting us?
- R Yang on Innovating in infrastructure in a research organization
- Michael on COTS software are not off the shelf or turn-key
- Bonnie on Classic post from the archive:The reference interview in a scientific research setting
- Hosting on funny related searches
- Bob Wilkerson on Understanding urban, low socioeconomic status, African-American Girls’ attitudes towards science
- Jill Strand on The new name for SLA: will it divide us instead of uniting us?
Archives
Geography
Where am I?
License

This work is licensed under a Creative Commons Attribution 3.0.
« Comps readings: community detection | Main | Looking for ideas for the Information Science Channel »
It's, um, fine... I guess
Category: librarians
Posted on: June 2, 2009 10:23 PM, by Christina Pikas
Lemme tell you a little story. A little while ago a really important society publisher in the geosciences re-did all of their web pages and they were pretty - jewel tones (not what I would have chosen, but pretty none the less). If you had a doi or were using an open URL resolver, you would go straight to the article and be satisfied - I pulled a bunch of articles for people this way and didn't notice. Then one day, probably 6 months after the site had been re-done, I was on the desk and this very, very, very smart and savvy scientist was completely befuddled. I asked if I could help, and he asked me to show him how to find the article cited by the article in his hand. I looked, and he was already on the journal web site, you see, because he knows how to go directly from the catalog (yay!). So we looked, and we looked, and we looked and we clicked, and we clicked.... Whoa, what on earth (or whatever planet this guy studies)? So then we tried to browse by date - no... Finally, I looked the stupid thing up in a research database and linked out using Findit - our sfx instance.... and e-mailed it to him. As soon as I got off the desk, I tried a few more things. It was really crazy and nothing on the site made sense. So I sent an e-mail to a listserv, asking who is on the library advisory board for the publisher and (well, I guess this publisher knows my place of work) immediately got 2 phone calls and an e-mail from the publisher. I sent them screen shots and I railed at them... they were extremely concerned and they said: but we did user testing. I asked, did you give the user a citation like this one from a reference list and ask them to find the full text? (no answer so I'm not sure if they did or not). I explained exactly what the problems were, and they made immediate changes - that day, right then, to make the links make sense. By the next day they had fixed all of their journal pages, and checked back with me that everything was ok. But what else could they have gotten done if this stuff had come out when they asked originally instead of fixing it in an emergency?
Another case, a large multi-national corporation put up a set of engineering handbooks where you could not find individual books by the title. HELLO! Engineers know the names of their handbooks and don't search across them by subject (in my experience). Who was the librarian who was cool with the only access being search?
The final case I'll give right now is a database vendor who rushed to catch up with peers and added facets - aren't we happy? Um. No. Top facet was United States and the second was Human. Oops - they put the affiliation field and the research subject in a psychology database in with descriptors and identifiers.... But the site was a pretty light blue and green - very springy.
In each of these cases, the vendors had gone out to users and to librarians to get feedback. They pretty much heard, "oh, that's fine" or "oh, pretty!". Now come on - we are in this together. If a vendor's interface, policy or whatever is AFU, then darn it, say so. Say exactly what is wrong, where it's failing. If you have suggestions, tell them. Run the thing through its paces with actual reference questions - isn't that what you were taught to do when evaluating electronic resources for the collection? If, when you're using something, it's non-intuitive and you know how to fix it, then talk to the publisher. I'm not sure if I'm hated or loved, but I try to be pretty blunt: listen you - this policy won't work, that's not how people work, I can't get it to do what I think it should do.
Sometimes, when I contact the help desk, I get blown off - if so, I try to dig up a business card from the last conference or an e-mail. If not, I blog it or I post it to the listserv. Oh, they hate that, but what else am I to do?
Oh, and if you are a scientist or a librarian, and someone from a vendor or your acquisitions department or wherever asks you to look at something - do look at it. Please. And seriously, don't be offiended if some for-profit publisher asks for the names of some people who could give them feedback on a product. I'm not saying - hey you vendor - to go around the librarian and spam the chemistry department. I'm saying that it's ok if you can find some end users who can look at a tool and run real queries against it.
Share this: Facebook Twitter Stumbleupon Reddit Email + More
TrackBacks
TrackBack URL for this entry: http://scienceblogs.com/mt/pings/111506




Comments
Resounding agreement. Recent experience- we do a LOT of citation counts but only subscribe to one particular vendor so they have become our organization's standard. We keep finding issues and reporting them. It's culturally easy for us. For reinforcement we can verify amongst the 20 odd of us that it is an issue with the database and not us alone before reporting back to the vendor. Some of them are basic UI stuff (why oh why have your next page navigation at the top of a long page of results???). But we are often left wondering if and why we are the only ones reporting these issues when the vendor responds with same sorts of comments that you record here.
Posted by: Sue | June 2, 2009 11:40 PM
Hear hear, and thank you for mentioning this.
Most of the time, the developers and owners of a site aren't using the site themselves... so they don't always know how actual users are going to use it (or attempt to & fail...).
I've developed and run a few different sites, and personally make feedback, bug reports, and suggestions as simple as possible to submit ...and quite a large portion of new site development is based on input from users.
Who am I, to pretend I know their needs better than they do?
One additional note on submitting bug reports: details are very important. You need to include enough so that someone can recreate the problem -- and that could depend on the browser & operating system you're using, the specific record you're manipulating on the site, and your specific input.
Posted by: Rob W | June 3, 2009 1:07 PM
I'm not a librarian, but I am wearing trifocals. Why is it imperative to have pastel background and teeny fonts?
Black 14-pt on white is a lot easier to read, and keep me on that site.
fusilier
James 2:24
Posted by: fusilier | June 3, 2009 2:57 PM
I was at a publisher library advisory group meeting a few weeks ago -- a small commercial engineering publisher. And let's just say, they were quite taken aback by how vociferous and strongly worded a lot of our commentary was. We dug down and looked very closely at both details and conceptual level stuff.
I think they were mostly expecting us to rubber-stamp the work they'd already done and that might be part of the problem. They spend a lot of time doing something that they think is right and they get a kind of emotional attachment to it. At that point, it becomes hard for the vendor/developer to look at the product really objectively.
Posted by: John Dupuis | June 3, 2009 4:23 PM
Amen. Actually I think this problem applies to all sorts of fields. People seem truly reluctant to actually look into a product's weaknesses and speak out about it.
Posted by: Max | June 3, 2009 8:28 PM
Great post - and can be applied consistently across being asked to edit anything to be made public. If there is a process that will be run from a document, get as many people as possible to not only proofread the document, but to run the processes as well. Thanks for this.
Posted by: Jaki | June 4, 2009 4:07 AM