This questions wasn't at all difficult, but I thought it was interesting because it was something I thought I knew how to do, but it turns out I didn't.
A patron walks up to the desks and says,
I have some software at home I want to install on my computer. However, there are two install disks - one for computers with a 32 bit processor and one for computers with a 64 bit processor. How do I tell what processor my computer has?
The patron had an XP computer, which is also what I was on at the desk, so that made things easier.
The site itself looked a little suspect, but as we read the page together, the information seemed okay. It gave instructions for both XP and Vista - and the XP instructions guided us to somewhere I never would have even thought of:
Start > Programs > Accessories > System Tools > System Information
When that window opens, look for the Processor line:
If it says x86 then you have a 32 bit operating system. If the processor area mentioned ia64 or AMD64 then this means you have a 64 bit processor. If it said Microsoft Windows XP Professional x64 Edition Version then this means it is a 64 bit operating system. However as you can see from above, it says Microsoft Windows XP Professional and the processor starts with X86 so therefore this is a 32 bit processor with a 32 bit operating system.
This answered the patron's question, and since we both learned something, it was a good exchange. The funny part (to me) is that the patron said he was right in the middle of installing the software, and came to the library because it was the only place he could think of that would give him free computer information. He was happy I found the answer so quickly and he apologized for rushing out.
New technologies are constantly becoming more integrated into how libraries perform their core functions. As this evolves, staff (and patrons) of all experience levels need to be able to communicate, but this is often difficult and problematic.
Iterate, don't perfect. Librarians seem to love perfection. We don't want to put any technology out for the public to use until we think it is perfect. Well, we need to get over ourselves. Savvy tech companies know the path to success is to release early and iterate often. One of the major benefits of this is that your users can provide early feedback on what they like and don't like, thereby providing essential input into further development. Do not be afraid of a "beta" or "prototype" label -- people are now accustomed to such, and it can provide the necessary "cover" to being less than perfect.
But this is not new. Roy's post reminded me of two other articles I had seen last year Computers in Libraries:
Thirteen Basic Things to Put Everyone on the Same (Computer) Page, by Rachel Singer Gordon and Jessamyn West (CIL 10/08) - abstract free online; html or pdf from Expanded Academic ASAP
These two are more focused on how front-line staff can become more comfortable doing their own tech troubleshooting. But best of all, by raising their comfort level and tech competencies, conveying problems to the dedicated tech support (whether internal or external) should also improve.
Naturally, these two articles overlap a bit on the tips that are most important:
Make sure the power is on to all components (if not, turn it on and see if that fixes the problem)
Make sure all the cables are plugged in and connected firmly (feel free to unplug and plug back in the cables
Try rebooting - that works more often than you'd imagine
But also important are the areas in which they don't overlap. The Singer Gordon/West article provide excellent tips on basic tasks anyone using a computer should (but might not!) know. And the Ennis article focuses more on how to avoid more serious problems, identify them when they happen, and then communicate important information to tech support.
My favorite sentence of all three articles comes from Lisa A. Ennis's article, in which she reminds tech support staff that the entire burden doesn't rest with the front-line staff. Her personal philosophy as a systems librarian is:
I'm not here for the technology. I'm here for the people.
That is key. Example: an email system that delivers no spam but sometimes blocks legitimate messages is not a good email system.
Technology is not a one-person game. Everyone uses it, so everyone has a role to play in making sure it works correctly - and that it is serving the mission of the library.
This isn't exactly a reference question - well, Part 1 is, but Part 2 is the real reason for the post.
A patron called in asking for help using ReferenceUSA. I was talking her through how to create a custom search, and everything was going fine. But when I told her to click the "View Results" button to run the search, she said she couldn't find it.
"It's the big green button on the right," I said, while actually thinking, "are you kidding me? How can you miss it?" But no matter what I said, she couldn't find it. So now I'm thinking it's a coding bug on the ReferenceUSA website, so I run through all the "which browser are you using?" questions to narrow things down.
It turns out, we were both using Firefox 3 on Windows XP, so we more or less should have been seeing exactly the same thing. But just to be on the safe side, I opened IE to see what was happening there. I resized both browser windows so I could see them side-by-side, which required horizontal scrolling to see the entire screen. When I switched back to Firefox and scrolled to the right, my "View Results" button was gone!
I maximized the Firefox widow, and it appeared again. So I asked the patron if she had her Firefox maximized, and she said no. She maximized it and let out a little shriek when the button appeared. We both marveled at this for a minute, then I helped her through the rest of what she was doing with the database before we hung up.
Later, I was trying to figure out how to report this occurrence to ReferenceUSA tech support. To type it all out in email would be long and perhaps not completely clear (as I sure you just witnessed). Then I got the idea to create a screencast - I had just read about Screenjelly on TameTheWeb, and Mick made it sound so easy. So I tried it, and it didn't work. The Screenjelly website didn't work, I mean, and I have no idea why.
But further in the post Mick also mentioned ScreenToaster as another one-click screencasting tool. So I tried that, and I made a little video in one take (no audio, but it wasn't necessary in this case).
So instead of a long-winded and convoluted email to ReferenceUSA, I basically sent them this:
A few days later, a RefUSA tech support person called to thank me for sending the video. She said others had reported the same thing, but she was having trouble replicating the error. But now that she saw it, they were going to get to work fixing it.
So, yay for a screencast being worth a thousand words. And now that I've done one, I'm going to keep playing and try to make some instructional demos for our website, databases and catalog. I'll even try to find a microphone, so I can add some audio instructions.
Oh, and a bit about ScreenToaster: you record your screen with one click, and then the video is either stored on their website or uploaded to YouTube. They can also be embedded into your website - here's the one I made (it's clearer at full size):
And thanks to Mick and Michael for the TameTheWeb post that explained things so well - check it out for more on screencasting.
Our pay-for-print station has been acting funny lately - and by "lately," I mean the last 2+ years.
As you might expect, reference staff spends a lot of time answering "how do I print" questions. But software and hardware glitches aside, sometimes the PEBCAK errors can be entertaining. To wit, I helped these two patrons on the same day:
A teenage patron was printing out a webpage. I showed him how to print, and then walked with him to the print station. When we got there, we found someone had left a quarter and two dimes on top of the pay box. People sometimes do this to be nice to the next person, or they leave it there if they find change in the machine.
I could see the kid eyeing it, and finally he asked, "did someone leave those coins there?" I said, "yes, you can use it to print your job if you like." "Or I can take it," he replied, smiled conspiratorially, and scooped it up and put it in his pocket.
Then he proceeds to take out his wallet, remove enough coins to pay for his print job, and insert them in the pay box.
Later a very stylishly-dressed woman needed help printing. I showed her that her job would cost fifteen cents, so she digs in her coin purse for coins. First she pulls out a dime and a Canadian nickel, which she puts on a table and then slides apart. Next she fishes out a few pennies and a Euro. She reaches in again and pulls out what looked like an old Chinese coin with a hole in the middle and an American nickel.
Wile inserting the fifteen cents, she says in a tone obviously meant to impress me, "whew, all this foreign money - I suppose I should stop traveling the world so much."
But that's all fine - as long as the printer prints when it's supposed to and doesn't take peoples' money, I'm happy.
In this funny video, replace "dad" with "library patron" and it's a reference question many librarians know all too well. At least, for the first third of the video - after that, it gets kind of weird and definitely violates the appropriate library behavior policy.