Our Reference Wiki and Online Tutorials

About a month ago, I promised to put up some screenshots of a wiki that I started for my library. I created the wiki using PBWiki, which is so named because it is supposed to take as much time to create a wiki using their software as it takes to make a peanut butter sandwich. My goal in setting up the wiki was to replace the handouts that we distributed to librarians being trained to work at our reference desk. I wanted something that would serve not only as a policy manual and list of services but also as a knowledgebase that my colleagues could add to or revise as needed. The need for some sort of shared documentation that could be annotated by anybody (at least, anybody who has the password to the wiki) was apparent to me when I noticed that the staff who were being trained for the reference desk were making notes on the sheaf of paper handouts they'd been given.

My colleagues have been to referring to the wiki while they're at the desk and have also begun to add new pages and flesh out currently existing ones. If you'd like to get a sense of what the wiki looks like, I have a demo here of how the wiki can be searched, browsed, and edited, which I thought might be more interesting than mere screenshots.

I should add a few words about the software that I used for the demo. I downloaded a month-long free trial of Macromedia Captivate, which is one of several highly regarded products for screencasting (see this page on the Library Success wiki for details on some of the different tools that can be used for creating online tutorials). I still need to work on my skills in creating, editing, and polishing demos using Captivate, but, alas, my trial ends in two days. I hope to convince the library to consider purchasing it for the staff to use so we can populate our website with more tutorials. Some of my colleagues have been involved in other efforts to create tutorials using other approaches; one of my favorites is this one, the "Beginner's Guide to Business Research," that the head of reference, Louise Klusek, did in conjunction with an outside design firm.

I enjoyed working with Captivate and found it easy to use, although the small amount of experience I already had with editing digital video on my computer helped me grasp the concept of editing the storyboard of screenshots that make up this demo. I was pleased with the way that as soon as the software was done doing the initial screen capture (i.e., recording my navigating around in the wiki, clicking on things, and typing things), it added in all sorts of animation (the blue captions explaining what I clicked on) and sound effects. During the editing process, I tinkered with the timing and pacing of the sounds and the appearance and disappearance of the captions. I also reworded the captions to give it more of a narrative. I hope I get the chance to do more of this, as it is really a blast and a powerful way for the individual librarian to quickly design and publish online tutorials. If you've ever animated a PowerPoint presentation, then you can easily handle Captivate. Do check out the sample tutorials that are linked to on the Library Success wiki page, as they offer ideas about ways to use screencasting software to reach out to our users and give them help where they are: online.

Cell phones and library services

Aaron Schmidt offers a valuable update about SELU Library's SMS Reference Program that allows students to use cell phones to text their reference questions to the library. Wish I could go to Virtual Reference Desk Conference this year to hear the presentation by J.B. Hill about the service at SELU. As I've mentioned in previous posts here about SMS reference, I think it can open an yet another communication point with our users.

Here at Baruch College, we haven't yet explored SMS reference, but we do have an interesting program called AirBaruch that is now campus-wide pilot (it was limited to a small number of students last school year, as I mentioned in an earlier post about AirBaruch) that allows students to use their cell phones to check availablity of group study rooms and laptop computers; the service plucks the data out of our OPAC and then feeds it in real-time to the students' cell phones. The service also offers other sources of campus information and can connect with Blackboard (although I'm not sure how at the moment).

My wish list for new QuestionPoint software

In my role as a member of the 24/7 Reference Advisory Board, I was asked to submit a wishlist for the redevelopment of the chat reference software that QuestionPoint uses. I got a very cordial thank you for that e-mail, the text of which I'd like to share here.

Much of my inspiration for how our software should look (especially on the user's end) comes from IM, which in the minds of our users frames their expectations for our "chat" services. We need to make our software run as smoothly and quickly as IM software but make sure it's got the advanced functionality that it needs for a cooperative environment (reporting, tranfsers/conferences, etc.) and for an environment where users can be instructed in the use of library resources (co-browsing to demo databases, web searches, catalog searches, etc.).

HIGH PRIORITY
(1) Co-browsing is unaffected by firewalls and pop-up blockers. This is my number one request. Everthing else would be gravy. If I can't co-browse with all my patrons, I might as well save my library 10 grand a year and go with instant messaging. There is no reason to expect any patron to have to tinker with their firewall settings just to allow us to co-browse; most users don't know what we're talking about when we ask them to, let alone have any clue about how to do it. Expecting a patron to configure their firewall to be able to chat with us is an unreasonable obstacle.

(2) Co-browsing works on Macs.

(3) Co-browsing works in all browsers (it can't just be IE but also has to be Safari, Firefox, AOL, etc .)

(4) Scroll of chat messages has the newest at the bottom, not at the top.

(5) There's no "End Call" button placed right where anyone will accidentally click it.

(6) Delete the "Scripts" window and allow for them to appear in one simple drop down. Access to scripts should be more immediate.

(7) Make it easier to toggle between multiple chat sessions (the grey highlight feature is hard to see). If you have more than one chat going, you see a line listing details of each one (IP address, user name, etc.). The one you are chatting with is highlighted in green, the ones you have on hold are yellow. Any that disconnect but that haven't had a resolution code assigned yet are red. If you click on one that is yellow, the highlighting turns green and the one you just were in turns yellow.

(8) Speed, speed, speed. Chat messages should ping back and forth; pushed pages should open more quickly. Users have been raised these days on IM; the pace of it is what they expect when they come to chat with us.

(9) Indicator on my screen and on the user's screen that one person is typing. This is a standard feature in IM. How many times have you wondered if you're patron was still there, typed out a "are you still there message" only to discover that the patron was typing a long message to you. And since our messages tend to be much longer than those of the patrons, it would be good to give them an indication that we really are still there and are ardently pounding away on our keyboards with another message for the patron.

MEDIUM PRIORITY
(1) Frame with chat messages could be undocked on user's screen and re-docked if necessary.

(2) Process of transferring or conferencing chats between librarians is easier.

(3) All libraries share one standardized system of resolution codes.

(4) Allow member libraries to customize the default initial message. Instead of this automatically being sent to the user at the start of every chat session:

"A librarian will be with you in about a minute.

[Librarian Screen Name - A librarian has joined the session]"

I'd like to be able to customize for my library.

LOW PRIORITY
(1) Would accept chat sessions from IM clients. That way, we could also run an IM reference system and one from QP. If a chat came in from IM, it could be transferred over to QP, which would offer greater functionality.

Since eGain may be going by the wayside, I should mention the things in it that I definitely, absolutely don't want to lose:

- ability to see the all the info we have about the user while chatting with them (IP address, link to previous chat sessions, e-mail address, browser, etc.)
- audio signals that a session needs to be picked up
- automatic e-mailing of transcripts provided by the user
- no downloads are required by the user to chat

New chat software coming from QuestionPoint

Word is slowly trickling out about what the new version of QuestionPoint may look like. My library just received an e-mail a few days ago with some details, all of which seem to repeated on this new page on the QuestionPoint web site. The library where I work has been a 24/7 Reference customer since January 2003 (although I had been playing around with trials of it as far back as 2000). When QuestionPoint first came out with its own chat product, I didn't even consider it as a software our library should consider: no co-browsing, slower than molasses, and no way to set up a cooperative chat service since there was no way to transfer calls).

I haven't heard anything about whether the "best of breed chat software" that QuestionPoint is working on has solved any of the problems that firewalls cause with co-browsing. QuestionPoint is on, what seems to me, a rushed schedule (there's a demo planned for VRD in San Francisco in mid-November) and a launch in January. I don't know how they plan to do all the training as well as work out the kinks.

Consider me worried for now...not a lot, but also not a little. The two cooperative chat reference services (one for public libraries, another for academic libraries) that 24/7 Reference brought to the table at the time of the merger in the summer of 2004 were two of its most valuable assets (the third would have to be the modified version of eGain software that powered the service). This is THE critical moment for OCLC to prove to 24/7 Reference customers (who had to swallow a big jump in subscription costs after the merger) that it can serve them well.

New article on collaborative digital reference service

There's an insightful article in the latest issue of College and Research Libraries (Vol. 66, No. 5) detailing the experiences of the libraries at the University of Illinois at Chicago with their digital reference services. Titled "Quantifying Cooperation: Collaborative Digital Reference Service in the Large Academic Library," the article has lots of choice nuggets, such as:

E-mail was used most frequently for submitting questions. The breakdown within user groups shows that faculty used e-mail 77.1 percent of the time, visitors 71.7 percent of the time, and graduate students 62.2 percent of the time. Perhaps not surprisingly, undergraduates showed a clear preference for chat, submitting 66.5 percent of their questions via this methods. (p. 449)

We haven't tried to do a study like that here at Baruch College, but we do know that here too graduate students tend to be heavier users of e-mail reference and undergrads fans of chat.

The article is available online at the ACRL web site to ACRL members and in full text in Wilson's Education Full Text (it's not there yet, though, and I'm not sure how quickly Wilson loads current issues).