When we first started using"chat"
at the reference desk, it was weird—really weird. It was scary. The computer
bonged at us whenever someone hit the chat Web page, and I had a tendency
to jump immediately to the screen that told me what IP address this visitor
was coming from and what browser he was using, not that any of that mattered.
Then I'd just sit there, staring in anticipation at the screen, hoping
he had a real reference question, yet fearing how to deal with it online.
|"It only makes sense
that since we spend hundreds of thousands of dollars making resources accessible
remotely, we now need to serve the people who use them."
On chat, you can only type
things and you just know someone is on the other side, also sitting there
and staring and waiting for an answer, which not only should be completely
correct, it should be there right now! You can only type so fast,
and in many instances, you also actually have to find an answer. Unlike
the telephone, you can't say, "I'm doing this and looking there" while
you are actually doing it. Also, unlike when the person is standing there
in front of you, they can't observe you diligently trying various keywords
in the catalog. Maybe more importantly, you can't see them. You
can't tell if they're angry and impatient. You can't tell if they're desperate.
Like D. Scott Brandt said in his column [November/December 2000 CIL,
p. 66], these types of communications "are more demanding than e-mail.
They tend to put pressure on you to respond right now...." That
is the whole point of integrating real-time communication into a Web site:
Users can conveniently communicate with you at their time of need.
That is precisely why some
form of an easy-to-use, online, real-time communication method will inevitably
be integrated fully into reference services. It is why we decided to give
it a try at the main reference desk here at the Jerome Library at Bowling
Green State University (BGSU) in Ohio. BGSU is a residential university
offering bachelor's, master's, and doctoral degrees, with about 16,000
full-time students. Last spring, we began experimenting with using online
chat for remote reference. We certainly have found it exciting, and we
think it offers huge potential for serving our users. It also brought up
some surprising and interesting issues for us to struggle with as librarians
Save the Remote Users!
It only makes sense that
since we spend hundreds of thousands of dollars making resources accessible
remotely, we now need to serve the people who use them. Providing users
with access to remotely available electronic resources without providing
assistance and instruction on how to use them is like telling them which
airport they are scheduled to depart from, but not giving them a flight
number, airline, or gate number. They might be able to figure it out eventually,
if they know their destination and approximate departure time, but only
after considerable effort and frustration. Our patrons are increasingly
using our remote resources. Statistics for searches and downloads continue
to grow as our in-person reference contacts decline.
As reference librarians,
one of our struggles has been trying to make the difficult and complex
process of conducting research as easy as possible. Sure, interfaces have
improved over the past few years. At BGSU, we even have the advantage of
being in OhioLINK, a consortium that provides a single interface
for nearly 40 of our most popular databases, all with easy one-click access
from the bibliographic citations to local paper holdings information and
electronic full text! But the truth is that research is complex.
There's no getting around it. It's hard. It can be frustrating, even for
us. Imagine what it must be like for people who don't do it for a living.
On top of all that, not only are we offering users greater access, but
we're also offering them more variety, too. Here at BGSU, we now have over
120 different databases from which to choose. Throw in the information
available on the Internet and the subtleties of using Web search engines
proficiently, and there is no doubt about the need to assist users remotely.
Finally, consider this:
If we don't do it now, someone else will. Now is the time to take advantage
of this opportunity to prove our worth. There are plenty of non-library-oriented
"ask-a" services out there on the Internet, and not all of them do things
nearly as well as we could. New products such as Questia and XanEdu, which
market research content and assistance directly to students and faculty
members, are also something to keep your eye on. They claim to be assisting
classroom faculty and students by adding preselected, relevant, scholarly
content to online courses or offering easy, one-stop access to research
materials for a fee. They give the false impression that research can be
made easy. Additionally, most, if not all, of the content has already been
purchased by the libraries that serve the very same students and faculty!
Certainly, for OhioLINK institutions, the content is not only already available;
it is much better packaged and serviced, albeit in a more complex
package. But it's a truthful package. So we need to be doing what we can
to make that complex package work for users. Answering their questions
online, in real time, only seems logical.
How Can We Help?
Here at the Jerome Library,
we started out just wanting to see if our suspicions were right—that users,
especially students, needed and would use a service that would enable them
to interact with a librarian in real time over the Internet. For that reason,
we needed to choose something with a minimum of expense, both in purchasing
dollars and labor. One of our systems staff members volunteered to help
us with software and technical issues, and all the librarians were willing
to try, a few even enthusiastically. No one had much time to spend on it.
First, we considered instant
messenger applications, but they presented one large obstacle. In our reference
area, we have a bank of iMac computers that allow downloads onto the hard
disk that remain there until the computer is re-booted. During high-traffic
times, you can find at least three different instant messenger applications
on these computers: AOL, Netscape, and MSN seem to be the most popular.
If we chose just one of these applications and the user didn't use that
one or any one at all, he or she would have to download it before asking
a question. That barrier seemed to defeat the whole purpose.
We found free software on
the Web from a company called HumanClick. It had lots of other advantages,
in addition to its price. It required nothing but a Java-enabled browser
for the user. It required very little on our end, too. We loaded a small
piece of software on all of the workstations we wanted use to answer queries,
and we put a short Java script into our Web page. It ran off the company's
servers and only when we turned it on at our end. If we had it "off-line,"
it allowed the users to send us an e-mail instead.
In May 2000, we loaded the
HumanClick application and tested it with a couple of librarians and staff.
Then we had a very short training session on its use. It took less than
20 minutes. We then asked librarians and staff in other departments and
branches to give it a try. About a week later, we added a link to the library's
home page and a link from our e-mail reference page. We decided to try
it while we were at the reference desk over the summer and see what happened.
We kept statistics using hash marks on a clipboard, and eventually we started
to cut and paste the entire transactions and print them out, noting a few
items like the length of the interaction, and the time and day.
A Few Points on 'Chat'
|"Despite the strangeness
of communicating via chat, it didn't take long to get accustomed to it."
Observing my teenager chat
online, I finally began to understand a few things about communicating
this way. She was multitasking. She was listening to music, chatting in
two or three different conversations, and surfing the Web. The time lag
didn't bother her at all. She was doing other things in between thoughts
in one particular conversation, and if she had another thought before she
received her friend's reply, she just went ahead and sent it. Our colleague,
Carol Singer, called this "curiously disembodied." There's no better way
to explain the feeling. It certainly is not natural to us, but many of
the students don't seem to even notice.
Despite the strangeness
of communicating via chat, it didn't take long to get accustomed to it.
We discovered that users tended to send many short messages rather than
one long paragraph. The transcripts don't make complete linear sense, but
while you're in the conversation, it's understandable. It certainly eases
the anxiety of empty waiting time. The users didn't seemed to be as bothered
by the length of time it took (to send, have the other person read, and
then reply and send back) as we were. Eventually, we got used to doing
something else too (like directing someone to the pencil sharpener, looking
up items in the catalog, etc.).
However, we encountered
a major technological problem in that we could not make the system reliably
work for our users on Macintosh computers. One of the main disadvantages
of using free software is that you have no technological support. We of
course made the company aware of the problem and received assurances from
them that they were working on a solution. About 50 percent of our campus
desktops are Macs, so this became a rather large concern for us. Unfortunately,
as we investigated other free products that provided chat, we couldn't
reliably make them work for our Mac users either.
Late in the summer, HumanClick
added two features that really changed how we communicated and how we felt
about the potential of this communication method in reference services.
First, we could now "can," or store, messages. After a short discussion,
we added about a dozen preset messages that we hoped would help ease the
time lag and save us from carpal tunnel syndrome. These were accessible
to the librarian from a simple pull-down menu.
The second and more important
feature that HumanClick added was the ability to "push" Web pages. By simply
selecting a pull-down menu option and pasting in a URL, we could send any
Web page we wanted. This is an enormous advantage. It is extremely difficult
to teach someone by using only the written word. Nothing to point to. No
facial expression to discern. No way to observe if they really could do
it on their own. In academic libraries, we already struggle with this in
using e-mail for reference. For example, someone e-mails us about how to
find articles for a paper about antioxidants in wine and heart disease.
It's really not all that great to send an e-mail back saying, "Try the
keyword search '(antioxidants or wine) and (heart or cardiovascular) disease'
in the research databases Biological Abstracts,CINAHL, or Periodical Abstracts,"
with a statement about how to get more assistance. You never really know
if that's enough. But now at least we could send them Web pages.
Of course, this technological
advance begged a new question: Which page do you send? With this cut-and-paste-the-URL
method, it certainly isn't practical to send the users every page that
they would see if we were helping them in person—the library home page,
the research database's home page (and why), the subject or alphabetical
list of research databases, the main menu of the selected database (and
why we chose it) ... We haven't even gotten to the search yet, and that's
already four Web pages and a lot of explanation. It doesn't take too long
to say, hear, and see, but it sure takes a lot of time to send and read.
The other option is to do the searches ourselves and send them the results
list with a short explanation of where to check holdings and look for full
text. In an academic library, our mission is to teach, to make it so that
they can do at least some of it on their own next time. This sure doesn't
help much at all with our goals in helping our users become more information
literate and self-sufficient.
Time to Try a Better
When HumanClick added the
canned messages and pushing features, the company also announced that these
features would not always be available for free. By this time we knew that
we had a valuable service, so we began looking for funding opportunities.
We also decided to stick with the best we could offer at the moment, hoping
that we wouldn't have to go back to a service with fewer features if we
failed. We also decided to go for the gold—to try to find the best possible
product for our situation, knowing we may have to settle for less.
Our statistics showed that
we were already receiving more reference questions on chat than we were
on our e-mail reference account, and we didn't think it would be too difficult
to argue that an improved product would greater enhance the service and
improve our teaching capabilities. Additionally, our university was coming
close to completing a multimillion-dollar project that included an entire
new network. To that end, dollars, in the form of competitive grants, were
being awarded for projects that had the potential to take advantage of
the new network. Three of us co-authored a grant proposal asking for $10,000
to partially fund the purchase of a commercial product that would allow
us to offer an improved online reference service. This improved service
would not only include the features we had become accustomed to with HumanClick,
but many more, as well as promise the potential for future enhancements.
We looked at a variety of
fee-based customer service products. The product we chose is called Virtual
Reference Desk (VRD), and it is available from Library Systems & Services,
LLC. The VRD product stood out, despite its rather large price tag ($8,000
for setup and training, $500 per month for maintenance). First and foremost,
it is a product aimed at libraries, not commercial enterprises. A few other
libraries were in the process of making it available to their patrons and
reported that the company worked diligently to make it work with their
proprietary databases. The company's product developer is Steve Coffman
[see his feature article on p. 20], who is a librarian. Finally, we would
be able to make it available almost immediately, without major hardware
upgrades and with very little work needed by our already overloaded systems
The VRD product is powered
by eGain, a Web-based customer call center application. It offers many
features over and above simple chat. Some of these are transcripts that
include URLs sent to both the user and the librarian via e-mail after each
interaction, statistical reports for the library, queuing and customization
features, and 2 full days of in-person training by company representatives.
It also offers co-browsing and other collaboration features that will allow
us to escort users around the Web and improve our ability to teach online.
Additionally, as the university switches over to the new network and we
and our users upgrade our desktops, VRD also offers voice and video features
that we hope to integrate into our online reference services.
Our interim dean of the
libraries agreed to make up the $4,000 cost difference if we were to receive
the $10,000 grant from the university. We received notice in early December
2000 that we would be getting our request, and we began the process of
purchasing the VRD product.
Since then, our training
process has gone well, and our experience with HumanClick really paid off
because as we're writing, it's February and we're ready to go live with
our new product at the end of this month. We're busy preparing canned messages,
slide shows, and completing our customization. Also, two of us are beginning
to work with a committee in our consortium, OhioLINK, to determine how
OhioLINK can help its member libraries begin delivering remote reference
services. It promises to be an exciting and challenging end to our academic
We Can Make It Work
One of our major concerns
is the impact this is going to have on our workload. Luckily, we are learning
this new product during a semester where we are not only fully staffed,
but we also have a returning faculty member on supplemental retirement
and 16 hours a week from a graduate assistant. We'll be more concerned
with staffing the service as it grows in popularity. Funding for continuing
and expanding the service will also continue to take effort and concentration.
Many libraries have been
trying to effectively accomplish real-time online communication for quite
a few years in a variety of ways using multi-user domains, Net-conferencing,
instant messengers, and other applications. For a variety of reasons,I
don't think users or librarians really found any of these communications
methods to be ideal. With the dawn of Web-based customer call center software,
there may be a solution at hand.
For more information about
all types of virtual reference services offered by libraries around the
world, visit the ELITE Project Web site from the University of Leicester
Bernie Sloan has compiled
a comprehensive bibliography on this and related topics and has made it
available at http://www.lis.uiuc.edu/~b-sloan/digiref.html.
The summer 2000 issue of
Reference & User Services Quarterly (vol. 39, no. 4) is a special
issue on "Digital Reference Services."
To join the discussions
of hundreds of librarians and others in all phases of implementing and
providing similar services, try the DIGREF listserv (more information at
and/or the livereference e-group at http://groups.yahoo.com/group/livereference.
Broughton is reference coordinator at the Jerome Library at Bowling Green
State University in Bowling Green, Ohio. She holds an M.A. in library and
information science from Rosary College in River Forest, Illinois. Her
e-mail address is firstname.lastname@example.org.