嵌入网页的在线咨询工具

    虚拟参考咨询有电子邮件、在线表单、论坛BBS等方式,但现在似乎实时交流更受用户亲睐。
    先进的图书馆早就用上了专用实时咨询软件,像QuestionPoint这样比较牛的,使用情况如何不得而知。丫枝所在图书馆用的是TRS平台,说是“利用率极低”,所以现在改用更有人气的IM方式──在试过了Meebo及其汉化版tatame之后,最终选择了在网页上嵌入QQ与MSN的方式
    他们刚上线时,我去试过那个QQ的Web Presence,需要登录QQ后才能使用,使用似有限制,如果没有QQ帐号,或没有登录,或所用机器上没有装QQ软件,就不能使用。
    365groups的MSN即时互动就没有帐号的限制,任何人都可用,比较方便。
    前些天关注此事,发现MSN也有官方的嵌入网页Messenger,试用下来在校园网内似乎速度较慢。
    [update 2008-2-26] 丫枝今天又介绍了Google基于Gtalk的类似工具chaback badge

    上述三种,都需要管理者有相应的IM帐号,并且处于登录状态下才能在线聊天。感觉上既是在线咨询,似不必局限于某个IM帐号。网上找到“聊天工具之在线IM服务比较”一文,看中了几个在线聊天室:
√ VQQ围围圈(http://www.vqq.com/)
√ 新浪的woocall(http://woocall.sina.com.cn/)
√ 晒网Say-on(http://say-on.com/)。
    前者博文作者较推崇,但没找到定义代码的地方;后两者很相似,形式上都可以选择嵌入页面或浮在页面上,用户无需注册登录即可发言。博文说晒网可以粘贴图片与多媒体,不过试下来只限有网址的情况,有点遗憾,不过可以保存记录,此两点都优于woocall。

   对于在线咨询来说,聊天室方式有利有弊。利是当遇到咨询者无法解答的问题时,可以请相关人员在自己机器上看聊天记录,直接与用户交流并回复问题。弊是当多个用户同时咨询各自问题时,群聊形式差不多可以说是乱成一锅粥了,场面之火爆倒真是“有目共睹”,大家都看得到!

    上述这些嵌入网页的在线咨询工具的一个共同特点就是制作方便──按提供服务网站说明的步骤,几步就可以得到代码,粘到自己网页的相应位置就OK了,简单得可以在十分钟内搞定。晒网定制代码时更是简单到只需给一个网址,无需注册,也无需提供任何个人信息。
    虽然如此,还是更期待能够有复杂点的IM机器人,这样可以减少很多咨询的人力。上交大的MSN机器人做得怎么样啦?

参见:
图林丫枝:
参考咨询平台整体更换 (13 Nov 2007)
谢谢:猪猫兔子们 (14 Nov 2007)
在线实时咨询:Google Talk新Widge [update 2008-2-26]

鼎新资讯吧:聊天工具之在线IM服务比较

OPAC使用统计

    要改进OPAC,直接对OPAC的使用情况进行统计分析,有时比做读者问卷调查更重要。
    记得上交大做过读者对OPAC的调查,结果反应还不错。我以为那是因为国内的网上书店没有Amazon那么出色,豆瓣也不似LibraryThing那般整合众多书目信息、经挖掘整理后可用于OPAC。如果有功能强大的参照物,结论应当有所不同。
    keso曾经有文题为“不要听用户的”:“Jakob Nielsen的可用性第一准则,就是不要听用户的……苹果的乔布斯相信,用户的需求不是他自己发现的,而是你替他发现的。在iPod出来之前,没人知道自己需要一个iPod。”,豆瓣的“杨勃相信数据,相信用户怎么做比他们怎么说更本质。”“一件有创造性的工作,在很大程度上不是满足用户已有的需求,而是创造尚不存在的需求。你怎么可能指望用户对自己尚未意识到的需求,提供有价值的看法呢?”
    斯塔夫里阿诺斯在《全球通史》(北京大学出版社,2006年第2版)中举过类似的例子:“不是存在于本世纪(指20世纪)初的对汽车的需求创造了今天巨大的汽车制造业,而是制造廉价的T型“福特”牌汽车的能力刺激了现代对汽车的大量需求。”(下册,p487)

    LibraryThing的Tim Spalding在NGC4Lib邮件组中征求OPAC中的推荐、标签等的点击数据。英国Huddersfield大学图书馆的David Pattern提供了一份很详细的数据,在最近12个月的总共2,055,707次关键词检索中,他所提供的OPAC新功能的点击次数及所占百分比[可以与一年前的数据对比:If you build it, will they come? (part 2)]:

62,410 (3.0%) 拼写建议("Did you mean?") [日均171:126]
33,709 (1.6%) 借阅参考("People who borrowed this, also borrowed") [日均92:70]
 4,131 (0.2%) 其他版本(xISBN/ThingISBN)(数月前停用xISBN)[日均11:16]
 2,058 (0.1%) 关键词组合建议
   381 (0.02%) 推荐("We think you might be interested in")

“关键词组合建议”是在用户只输入1-2个关键词时,根据之前所有用户关键词组合检索记录,提供多至4个其他关键词[保存检索记录,加以统计分析,进而利用]。“推荐”则是在用户登录图书馆帐户的情况下,向其提供的个性化建议。这两项功能推出不久[不知是不合用,还是用户没有注意到]。

    David还提供了各类关键词的检索数据、不同命中结果量数据(其中21.4%无命中)、检索所用关键词数量,并说明了他暂时还没有统计的数据,如浏览检索结果详细页面的情况。[是否点击结果,从某种程度上说明结果是否真正是检索者想要的]

    Emory大学图书馆的Selden Deemer提供了一份该馆2008年1月不同检索途径的检索数据,尽管不合乎Tim的要求,可谓文不对题,但对于了解一般OPAC的使用也是有价值的。统计分为检索与浏览两部分,合计:检索110,973,浏览5,263[不足5%]。不同检索途径的详细数据:
General         50,997
Title           16,994
Author          13,951
Periodical       4,798
Subject          3,999
Series             223
Other           20,011
    并说明无命中结果的情况占20%(关键词)到50%(丛编)。

    结果发布,却引来砖头无数,其中最重要的一点是认为没有对用户加以区分:哪些类型的用户使用哪些检索途径,是馆员用的还是一般用户用的。
    我原以为馆员在所有用户中所占比例极小,对统计结果的影响应该是微乎其微的,但从Texas A&M大学图书馆的Bennett Claire Ponsford提供的按馆员与公众区分的OPAC使用统计(OPAC usage stats)来看,某些检索途径馆员使用占所有使用量的比例相当大,甚至远超公众使用量(如索书号浏览、题名前方一致检索),因而足以影响统计分析。

    中国用户的OPAC使用数据又有什么样的特点呢?老拿国外数据说事儿,也是无奈之举啊。

用美味书签做学科导航如何?

    在国家级的图书馆中,澳大利亚国家图书馆(NLA)应该是最具有2.0风格的,早两年就用上了Flickr,与网民共建澳大利亚图片库。现在,他们又用美味书签作为虚拟参考咨询的辅助工具。
    AskNow(http://www.asknow.gov.au)是NLA的合作虚拟参考服务,通过联机聊天方式与用户实时互动。使用的是OCLC的QuestionPoint,在线时间周一到周五,上午9点到下午7点。
    为了在与用户对话的极短时间内即时提供可靠的免费访问网络资源,馆员们近日开始使用美味书签收藏那些网站,取名为“有用资源”(http://del.icio.us/usefulresources)。
    它充分利用了美味书签的网站描述、标签(tag)和标签分组(bundle)功能,将收藏的网页/网站组成一个自由组合的三级网络。一级是bundle,既有按学科的,如农业、商业&经济;也有按专题的,如澳大利亚;还有按特定对象的特定需求的,如作业辅导网站。二级是tag,每个收藏都可以根据其内容赋以多个标签,并不受bundle的限制。三级就是带描述的收藏网页/网站。
    利用美味书签的好处是所有参与馆员可随时共建,而非参与者也可以共享。相信如果进行澳大利亚研究,用他们收藏的专题网站肯定是最有价值的。

    自然就想到了很多图书馆都在做的学科导航。常常是一套无法与外界交流的独立系统,以美言誉之是养在深闺人未识,以恶言毁之则是面目可憎而乏人问津。国外有多个用维基做学科指南的例子,毕竟还要维护一个维基、编辑页面。如果能够直接用像美味书签这样方便组织收藏的标签或网摘系统,是不是会简单许多?

参见:National Library of Australia Gateways (no. 91, February 2008)
AskNow’s del.icio.us Useful Resources / Gwyn Wilding
http://www.nla.gov.au/pub/gateways/issues/91/story01.html

via Lorcan Dempsey’s weblog: Reference bookmarks
http://orweblog.oclc.org/archives/001551.html