Several people have written me quoting Sarah Houghton's discussion of Rikhei Harris' synopsis of Christina M. Desai and Stephanie J. Graves' presentation at the Virtual Reference Desk conference this year regarding a study at Southern Illinois University Carbondale (SIUC) that included a factoid that co-browsing only works 39% of the time. So therefore, people are saying, co-browsing is worthless.
This data was interpreted by Rikhei, not Christina and Stephanie, and I don't mean to say that mean's Rikhei's math is in any way off, only to give credit in the proper place.
The first thing I thought was, hey, we did a similar study, and, hey, our results were very different. The second thing I thought was, hey, I went to that session at VRD, and I had a different conclusion about co-browsing altogether, that in fact, it is not worthless and is more valuable for instruction purposes than I had previously assumed.
I think this topic require some background, so if you understand all about co-browsing and how it works and how it's been implemented and what the specific issue often is, or if you don't care and just want to get to the results of our survey, skip the parts labeled as digressions and scroll down to "survey results".
On the other hand, if you know it all and I've gotten it all wrong, give a shout.
First digression: what is co-browsing?
Let's define co-browsing as two or more separate web browsers sharing a connection to browse the world wide web. When one browser authenticates to a licensed database, the others are authenticated also. When one browser submits a form, everyone gets the results. Each visited web server logs one hit, total, no matter how many browsers are co-browsing the site.
Most often in virtual reference, co-browsing means that there is a patron, somewhere, and a librarian, somewhere else, sharing a connection to the web. The two can share any website as if either one of them were looking at it alone.
As Sarah says, this is "the cat's pajamas". The early and obvious promise was that co-browsing was the perfect tool for remote bibliographic instruction, because it lets librarians walk patrons through licensed resources without being in the same physical location.
Similar, but not the same as co-browsing, is "page-pushing". With page-pushing, one person can send a URL to others, but they do not share the connection. The web server logs a separate hit for each person, and each authenticates to licensed databases separately.
Second digression: how does co-browsing work?
There are two basic ways to co-browse, by application sharing and with proxy servers.
In application sharing, one of the browsers gives explicit permission (i.e. a special software download) to the other browser to take control of their local web browser, or even the entire computer. This method is often criticized as invasive to privacy, bandwidth-intensive or just plain scary. In practice, patrons are often reluctant to accept the download.
The "enhanced QuestionPoint chat" that OCLC used to offer is an example of this, but as far as I know, no virtual reference software vendors offer application-sharing-based co-browsing any longer.
A proxy server is a third party, a server somewhere, which does the actual communication with the websites being co-browsed. The server then relays the information back to everyone co-browsing. Each person co-browsing is connected to the proxy server, and the proxy server is connected to the resource, giving the illusion that the people are connected to each other.
People often use proxy servers to hide their identities or to circumvent firewalls. In libraries, this usually means allowing off-site patrons access to licensed resources. The proxy server makes it appear that the patron is coming from your library's IP address range. Outside of libraries, proxy servers are usually used for things you don't want other people to know you are doing, like hacking into the your neighbor's weather station or looking at pornography - the proxy server masks your identity to the sites you visit and, to get around filters and firewalls, masks your er, destination, to your local network.
When you use a proxy server for co-browsing, less bandwidth is used because the connection only needs to be updated whenever anyone takes an action - for example, when one of the browsers clicks a link, the message gets sent to the co-browsing server, which sends it to the resources, and the co-browsing server gets a reply and sends that to all the browsers. If you've every heard that virtual reference takes a long time, this is part of the reason.
The downside is that in order for this to happen, the proxy server has to pretend to be a web browser. This could be easy if everything we looked at was straight HTML with nothing fancy. As it happens, there are even specifications for how data is communicated between computers and how it is displayed in browsers. Unhappily, the most popular web browser doesn't meet those specifications. As a result, data being sent by the proxy server back to the co-browsers is not always faithfully rendered, which may cause formatting or display problems, authentication failure, or could simply crash the browser.
Currently, both OCLCQuestionpoint247 and Tutor.com's Virtual Reference Toolkit use a proxy server to offer co-browsing. I do not know how SyrsiDynixDocutek's VRLPlus, the third major web-based chat software product, handles co-browsing, but I have heard that it is similar in that it relies on the Microsoft Java Virtual Machine.
Third digression: Microsoft Java Virtual Machine
OCLCQuestionpoint247 and Tutor.com's products are similar because they are based on a product by eGain called Live, and according to my help screen, it is copyrighted 1997-2002, though that could just apply to the help file. eGain Live is built on Microsoft's Java Virtual Machine, which only runs on Windows, using Internet Explorer, and isn't even installed on brand new, out-of-the-box Windows machines anymore.
It is not quite the same as Sun Microsystems' Java Virtual Machine, and after a long back and forth of subpoenas and cases and settlements and extensions, Microsoft finally decided to stop supporting their version December 31, 2007.
Sun developed, invented, created, and owns Java. Microsoft's version is slightly different, and the problem with that, besides it's being a blatant trademark or copyright or patent violation, or all three, is that Microsoft's version was an intentional aberration of the original Java.
What made Java an interesting idea when it was released in 1995 was that it was a portable programming environment, Sun calls it the Java Runtime Environment. You can create a program in Java, put it on a web server, and when someone visits your page, you send your Java "applet" to their browser. It's an efficient way to make your website do cool things, like display a photo slideshow, or play a game of checkers, because the user doesn't have to click something to say yes, ok, fine, install this software on my computer. You don't need administrative permission to install the applet, it just runs because you have Java installed on your computer, and Java will make the applet run without you having to do anything else.
You roll your eyes, but do you remember the internet in 1995? I do, because I spent that whole summer asking Yahoo! to serve me up random web pages, and they were almost all ugly.
Now, for most purposes, Java applets will run in either the Microsoft or Sun Java environments, but certain applications will only run with Microsoft's version, often because the developers took advantage of performance efficiencies in Microsoft's version that make the program run and load faster. These performance efficiencies often led to security problems, which is the usual critique of Microsoft Java Virtual Machine.
Security issues never stopped Microsoft, not yet anyway. The advantage of the whole setup to Microsoft was that by creating a version of Java that was attractive for developers like eGain to create tools with, they could elbow out competition in the operating system and web browser markets. This happened over 10 years ago, dating back to events that led up to the 1998 United States vs. Microsoft antitrust case.
Microsoft's idea was that if everyone wanted to use cool things on the web, and if they can make it so the cool things only work on Windows machines running Internet Explorer, everyone will use Windows machines and run Internet Explorer.
So, co-browsing doesn't work on your Mac, or your Palm Pilot, or your electronic thermometer whisk, because Microsoft thought they could make more money that way. This fact isn't really disputed - of course they made more money that way - what was disputed was whether or not it was legal.
In 2001, the case was settled, and Microsoft said they would play fair, and the Department of Justice agreed the damage had been done and a panel would ensure compliance for 5 years (time is almost up, get ready for trouble). For more information, see the Department of Justice's page on the case and Wikipedia's entry.
In the end, as long as Netscape and Sun Microsystems were holding on to Connecticut Avenue and Marvin Gardens (respectively), Microsoft could have everything they wanted, while we libraries down on Baltic Avenue, are stuck with co-browsing only working 39% of the time.
Can we co-browse without Microsoft? I don't know, how can we not want to?
Survey results
We conducted a survey, of librarians staffing our service, for one week, in February 2005, to determine how we were using our software. Among other things, we found technical problems occurred in 23% of all sessions.
Now, 23% technical problems is still too high, but it's not as high as the SIUC data suggests. I was actually relieved when I found it was close to Jessamyn's 80/20 rule, that things are broke 20% of the time. Again, still too high, but at the very least, you should be convinced, if you didn't assume it already, that the SIUC study is cannot be universally applied.
Actually, you can't compare the our study with Rikhei's interpretation of the SIUC study, because Rikhei is writing,
61% of the times the librarians tried to use the co-browsing feature, they had problems with it.
And I just wrote,
...we found technical problems occured in 23% of all sessions.
So I looked at our raw data and tried to see, of all the times we used co-browsing, how many times were there technical problems?
In our study, and with our Tutor.com software, the sessions where co-browsing was possible are called Interact sessions, and these numbered 39. Of those 39, the librarian sent a page 30 times, i.e., using co-browsing. Of those 30 sessions, 5 had technical problems, or 17% of the co-browsing sessions had technical problems.
So admittedly, our sample size is shrinking, but what can we conclude?
Possibly, if we are an in an Interact session, things are pretty well technologically matched to start, so of course co-browsing is going to work more often.
Possibly, our statewide service is getting used by people more likely to have a computing environment cohesive to co-browsing than the people using SIUC's service.
To illustrate, I once had the fortune, not that long ago, of finding out how great co-browsing works with Netscape 4.7 on Windows95. If your service is based on old technology, and your patrons have old technology, you are all set.
More commonly, the students coming to our service have teachers or librarians who have checked to make sure our service works on their school computers. That's been part of our marketing strategy, though it might not be easy to apply to a standalone academic library VR service.
Is there a certain demographic, beyond "Windows users running Internet Explorer" that co-browsing is best for? We long assumed that college students were that demographic, because they are a big demographic for bibliographic instruction. Now I'm thinking that there's more to it, and the good demographics for co-browsing might be the middle school students, high school students and adult learners. It certainly warrants research.
Something else could be going on that we should think about is the differences in the virtual reference co-browsing products available to us. I don't actually know what all of the actual differences might be, but I have talked to colleagues and I understand what different strategies each uses for dealing with potential technical problems.
The first vendor makes every sessions start out in the page-pushing mode and gives the librarian the option to initiate co-browsing only if they want to. Other vendors sometimes offer multiple interfaces to the librarian side of the software, one of which has this option built-in.
The second vendor handles co-browsing problems by pre-scripting a number of messages to help the patron and librarian troubleshoot. Most often, it helps if the patron clears their browser cache.
The third vendor applies stringent criteria to check to see if co-browsing was possible, and forces more patrons into page-push-only sessions if things weren't perfect. If there is still a problem with co-browsing, the librarian can end the co-browsing session and continue with page-pushing only.
One of those vendors is Tutor.com, who, in a few weeks time, will broadly implement Ask a Librarian (tm), a new web-based chat product we learned about at VRD with no co-browsing. Instead, if a Windows-using patron will download a special application, the librarian can send streaming video of what is going on in their own browser, in effect showing the patron what they are doing. I dub thee "show-browsing".
I suspect that this is a cost and sanity-saving measure on Tutor.com's part. Given how much of a pain it is to try to run a service with, Microsoft-Java-based co-browsing must be a bear to support. The reason Tutor.com actually cited for the elimination of co-browsing was that it violates electronic resource license agreements because the technology circumvents the resource's security. This isn't true for our Oregon statewide database licenses, by design. Rather than adapt your software to comply with a license, adapt your licenses so you can use it with your software. Make sure your licensed resources are explicitly allowed to be used for virtual reference, co-browsing and all.
Anyway, our study proved that we don't need co-browsing to be successful, which was part of what we wanted to find out when we conducted it. Two of the most successful virtual reference services, New Jersey's QandANJ and Ohio's KnowItNow, don't even have co-browsing enabled. After spending two years demanding librarians attend full-day trainings to accommodate learning both the co-browsing and a page-pushing environment, I'm jealous.
Interpersonal problems with co-browsing
Our experiences with technical issues aside, a problem with co-browsing is that it can give the librarian false confidence, which takes a lot of practice and patience to overcome.
As a librarian, I've run into the problem where I take it for granted that if co-browsing works for me it, it works for the patron. Consider this fictitious example:
Patron: Cheese!
Librarian: [sends a search for cheese in licensed database]
Librarian: See anything you like?
Patron: [disconnects]
Because I had assumed that co-browsing works, I forgot to be a person. I just sent it and zip zoom, the screen changed and the search was obvious, right? But in the example, I don't actually know if the patron got what she needed, I assumed she did because it worked for me. There's a good chance I assumed wrong, based on anyone's numbers.
A better strategy, the necessary one when you are page-pushing only (or instant messaging), especially with licensed databases, is to talk to the patron to warn them that a page is coming and to make sure the result was received and that both people are looking at the same information.
Consider this equally fictitious example:
Patron: Cheese!
Librarian: Let's search for cheese.
Librarian: [sends a search for cheese in a licensed database]
Librarian: Do any of these articles look like they will be helpful?
Patron: yes, swell, thank you, this service is so awesome !!!!!!!!! :)
or, if co-browsing isn't working,
Patron: wait i'm lost :(
The software we are using can inform our interpersonal communication techniques, and when that information is false, we deliver poor service. It doesn't have to be that way, but it's an easy trap to fall into.
Ubiquity
If any objection to co-browsing holds water, it's that it only works with web browsers.
As our patrons are using more and more communications technology - computers, telephones, PDAs, games, homing devices on their pets - they are going to want to connect to the library with more and more of them. Our communications strategies, our reference services, shouldn't be based on a single tool, not the reference desk, not the telephone, not e-mail, or web-based chat, nor community outreach, but all of them.
The more we can do to integrate these tools, the less work it will be for libraries to learn and use them all.
Blah blah blah
Co-browsing has been poorly implemented from the beginning. From library software vendors and their contractors, to libraries delivering it as a service. It is a sickly child. The lack of a really good co-browsing option is a good reason, as Sarah suggests, to skip it altogether.
But it's not dead. Co-browsing still adds value to our virtual reference sessions, and I think that's what the SIUC study really proved. Librarians use co-browsing. It empowers us, it gives us a competitive edge, and it's possible that it works very well with a certain demographic, we just have to figure out who, exactly.
By some fluke, you can even co-browse on our service using a Mac running Firefox, I don't know about firewalls, but that's hardly the point; what we do best in virtual reference, what the core is, is human interaction, and we don't need co-browsing to do that.
This is cats. In pajamas. So long as patrons are trying to reach us on the web, I want to be co-browsing with them, I want them to benefit from it, I want them to love the library.
