QuestionPoint widget review, or, sweeping vendor dirt

Caleb Tucker-Raymond provides a review of the new widgets available with OCLC’s virtual reference software QuestionPoint at his L-net blog. Titled “QuestionPoint widgets and what to do about them”, his review is entirely fair and instead of simply pointing out the faults of the QP widgets he offers a workaround.

Read his post, but I’ll tell you in short that he likes the way the QP widgets handle patron privacy options.

That’s about it.

What he doesn’t like is that the widget continues to not facilitate the type of collaboration that Oregon’s L-net is all about. The specifics get into some QP geekery concerning the widgets being assigned to only one QP “queue.”

This isn’t a software problem so much as a policy problem. OCLC has made the assumption that our virtual reference services will be very very popular if we implement this kind of interface and the 24/7 Cooperative and the paid OCLC Backup Staff won’t be able to handle it. As a result, the widget functions in the way I described above.

Talk about fear of success! I’ve sent several complaints and suggestions for other strategies to measure and manage this potential problem, but have yet to get a response or acknowledgment from OCLC.

The main practical problem with us using the widget is that saying that chat is unavailable isn’t truthful – we’re available 24/7, it’s the widget that is not.

QP WidgetHis solution to the problem involves some javascript to hide widgets at certain hours. That is, hide the problem. L-net libraries can either lie to patrons or sweep the vendor’s dirt under the carpet, which renders the widgets less useful. This whole story is another example of the inadequacies of vendor driven solutions to library problems, and perhaps their unwillingness to enter in a dialog and/or be responsive.

Caleb references the open source library chat box project libraryh3lp but doesn’t go so far as to recommend ditching QP and going with an open source solution. Clearly L-net has a decent amount of money and training time invested in QP so I can understand why he might be reluctant.

I just wonder when libraries are going to get fed up with buying things they don’t really want.

11 thoughts on “QuestionPoint widget review, or, sweeping vendor dirt”

  1. I would argue that it’s not necessarily a matter of libraries getting fed up with buying things they don’t really want. I think organizations such as L-net very much want a service like the QP widget. I think it’s more when will we get fed up paying for things that don’t work the way we need them to?

    I understand needing time to fix a problem, but the fact that OCLC hasn’t acknowledged – let alone responded to – Caleb’s efforts to help resolve the issue is a real problem. Here’s a librarian who wants this service to succeed and is going out of his way to help a vendor create a better product for libraries, and they’re ignoring him. That should be a huge concern and it paints OCLC in a very poor light, even as it puts its customers serving the public at a real disadvantage. How long will it be before L-net puts its money into libraryh3lp development to get what it needs, rather than paying licensing fees for a product that isn’t working as it should from a company that isn’t responding to efforts to fix the problems?

    I know this is what you meant, but I wanted to differentiate between want and value. ;-)

  2. yeah, we’re totally on the same page here, but i’m still going to insist that in this case L-net bought something they didn’t really want because it doesn’t work the way they need it to. yes, they want something similar to the QP widget, but one that actually works for them.

    a simpler way to put this is: “things that don’t work the way we need them to” like you wrote, in my head = “things they don’t really want.” because why would an org want something that doesn’t work they way they need it to work?

    i think the point you’re trying to make though is the fact that, YES, libraries *do indeed* want tools like this. amirite?

    and thanks for stating the customer service aspect more explicitly!

  3. I was shocked to see that the Qwidget didn’t work for collaboratives/cooperatives. Here in California our entire state is one big collaborative, and as you can imagine, that’s a lot of libraries. We’re not going to be using the Qwidget here at San Jose Public Library because it would only show that we were “available” during the hours we were actually staffing the service which is, because we’re part of a cooperative, only a few hours a week. My guess is that few, if any, CA libraries will use the Qwidget. We’re looking at the other options like Caleb is. I can’t express my disappointment enough that this widget didn’t do what it was said to do all along – the vendor didn’t listen to their users and came up with a “new solution” that solves nothing. I’d be interested to see if cooperatives could get together and really encourage OCLC to tie in the Qwidget to the rest of the existing system, which was what we were told it was going to do from the start. Shame.

  4. Aaron is right – we did purchase something we didn’t want. In late 2005, we switched from to QuestionPoint. At the time, we decided that QuestionPoint was our best option, even though it was far from perfect. Yeah, I’m “never satisfied”, and all that.

    In 2005, QP had a lot of promise to evolve into a product that could accommodate all of our needs. It still has promise! It is just extremely disappointing to see their team so focused on developing something that turns out to have so very little to do with us.

    I expect that in time, OCLC will open their widget to the 24/7 cooperative. They’ve hinted as much. My main plea to them has been that they won’t be able to accurately measure the impact of increased traffic on the cooperative unless the widget actually connects to it. They could instead pick some beta testers, a few individual libraries and a few cooperatives and see what happens. It doesn’t have to be us; I vote for Maryland Ask Us Now!.

    The cooperative is the best part of QuestionPoint, and really, it’s worth the money. But if QP isn’t going to keep cooperative service at the core of their product, what’s the point? Any individual library wanting to offer VR has better options, and cooperatives soon will too.

  5. Thank you for providing this information. We were looking at QuestionPoint precisely for the widget abilities. It looks like it won’t work for what we want it to do.

  6. Odd that Caleb wasn’t getting any kind of reply from OCLC about the widget implementation. Ever since we learned about the widget from OCLC, we’ve been hearing from them that phase 1 would be limited roll-out (i.e., your local queue), but that they were seriously considering taking on support of the widget traffic as a phase 2 roll-out.

  7. I’m coming into this discussion VERY late, but I thought I’d add a few cents’ worth…

    1) Several months into it, I do like the qwidget because it gives us *at least* the same amount of coverage (hours-wise) that we had with an IM widget.

    2) With a properly-crafted away message, it gives one-click access to our regular QP 24/7 chat form when we can’t cover the qwidget ourselves.

    3) Given our own setup (our own queue, with multiple librarians monitoring), it actually improves our local ability to pick up what would have come in via an IM widget by spreading the load among several librarians.

    That said, just like everyone else, I really do want to see the qwidget push questions to the cooperative after the allotted time (40 sec?) or after hours, although #2 above is a pretty good bridge to an after-hours solution.

    However, I don’t think you can dismiss the possible impact of qwidget traffic on the cooperative outright. In June, we had 220 QP sessions from our patrons, up from 145 in June ’07. 131 of those came via the qwidget. The qwidget’s available in just a few places on our site (I want more!), but as any Meebo/Wimzi widget user knows, it’s just so much more inviting. I expect the qwidget’s a big part of the overall jump in stats. July’s also looking to be considerably higher traffic than July ’07. Now, we keep a lot of that traffic out of the cooperative because of our setup. In fact, between local sessions and our commitment to the cooperative, we’ve been averaging 213 QP sessions covered by our own staff for first half of ’08. What happens to the cooperative if a lot of libraries that don’t pick up the majority of their own questions suddenly have 51% jumps in sessions? I absolutely do not want OCLC to fear success, but I surely want them to plan for it. If that means measuring the impact of the qwidget and modifying staffing before opening the floodgates, I can live with that. But I still hope they open the floodgates soon!

    By the way, I think they’ve got some lower-cost options coming up with local queues that will allow more libraries within a consortium to do something like we do, letting multiple local librarians monitor the qwidget. If a lot of libraries adopt that model (especially larger publics and academics), it might take a significant load off the cooperative.

    Hope that all wasn’t too rambling…


Leave a Reply