图书馆移动服务的深化*——基于微信开放平台的图书预约系统实践探索
时间：2023-06-11 17:10:16 来源：雅意学习网 本文已影响 人 
黄悦深
雅虎原任用户体验总监 Luke Wroblewski 在《Mobile First》首次提出 “移动优先”的理念，其核心在于对用户的便利性和无缝对接[1]。国内移动图书馆的建设历程就是“移动优先”理念从无到有，由浅入深的发展过程。2005年国内移动图书馆进入发展阶段，早期的应用形式以短信服务、WAP网站为主[2]。2011年厦门大学图书馆推出了国内第一个移动图书馆App[3]，但当时的移动技术应用大多局限于将OPAC的主要功能迁移到移动端以及部分馆藏移动阅读的实现[4]。2013年国内图书馆开始探讨基于微信开放平台构建移动图书馆应用[5]，由于微信应用的技术方案覆盖线下场景，技术栈全面，且受众面广、轻便易用，因此较好地契合“移动优先”的理念。经过多年发展，微信应用以其“开放易用、富客户端”的技术特点，成为构建移动图书馆服务的又一重要技术路径。
从业务类型来看，图书馆微信应用主要涉及资源利用、服务组织、信息服务、馆务管理。其中，资源利用包括移动阅读平台、馆藏及借阅信息查询、图书外借（转借）、图书共享（漂流）、图书荐购等业务；
服务组织包括座位预约、空间预约、活动组织、电子证办理等业务；
信息服务包括资讯发布、信息咨询、机构库、查收查引等服务；
馆务管理包括图书馆业务和办公方面的自动化应用。从应用场景来看，2013年至2015年，图书馆微信应用集中在线上信息服务。自2016年起，线下场景化应用成为新的开发方向，融合了微信扫码、位置感知、身份识别、签到打卡等功能的线下应用纷纷登场，使图书外借、图书荐购、座位管理、室内导航[6]服务能够嵌入读者的使用情景，提供更多元化的服务体验。从开发技术来看，应用场景从线上转为线上与线下融合，促使开发技术重心也随之而变。由原来的重后端轻前端，转变为前后端并重。早期的微信应用以线上信息服务为主，如信息查询，所有关键业务处理均由后端完成，前端功能弱化。近年来，依靠微信开放平台日渐丰富的开放接口，前端能够实现扫码操作、身份识别、座位管理、室内导航等线下交互功能。技术开发重心前移、情景交互功能突出已成为当前微信应用的重要特色。
笔者认为，以微信平台为基础，构建“互联互通、情景交互、简便有效”的移动应用，是对移动图书馆服务的有效深化。它有助于解决图书馆系统的“数据孤岛”问题，有利于构建以情景交互为驱动的智慧型应用。本文以便利读者使用为原则，以情景化交互为开发导向，以图书预约系统开发实践过程为抓手，深入分析五邑大学图书馆的微信开放平台，以此探讨微信密集书库图书预约应用的功能特点，深化移动图书馆服务的作用。
2018年，五邑大学图书馆完成了密集书库的改建，随即启动首批80万册图书的上架加工工作。结合实际情况，图书馆采用图书流水号排架法[7]对图书进行加工管理。通过一段时间的努力，已完成大部分的加工任务，基本具备了馆藏流通的条件。
读者预约取书属于辅助工具型事务，必须最大限度地简化读者操作。结合微信开放平台的功能特性，经过项目组的讨论，最终确定了以下三点核心需求。
（1）读者无感登录。一般而言图书馆业务系统采用读者账号作为身份标识和操作凭据，但是这种方式必然增加了读者登录操作的负担。因此，如非必要，放弃使用读者账号主动登录的方式，另辟蹊径，在无须读者主动介入的情况下即可实现身份识别是更佳选择。
（2）主动通知读者。读者预约结果可通过两种方式获知，一种是读者事后主动查询，另一种是系统主动发送通知提醒读者前来取书。考虑到馆员取书有滞后性，为了免去读者反复查询的麻烦，采用主动通知的方式告知读者到馆取书。
（3）读者扫码取书。“扫一扫”已成为移动环境下读者高频使用的便捷操作，因此，当读者到馆取书时采用扫码方式来核验预约凭证，更符合他们的使用习惯。
除了以上核心功能外，系统还包括其他业务环节，整个流程如图1所示。
图1 图书预约系统业务流程
要满足上述系统需求与功能，走移动应用之路是必然的方向，关键在于选择哪种技术路径。项目组对当前主要的移动应用开发技术进行对比分析，如表1所示。
表1 三种移动应用开发技术路径对比
HTML5应用属于传统的Web应用范畴，开发模式成熟，开发难度和开发成本低。而且HTML5彻底颠覆了HTML4以呈现网页文本为主的功能定位，支持富媒体、互操作、数据存储、多线程，乃至提供操控移动设备硬件的API[8]。这使得HTML5十分适用于前端开发。但是，HTML5属于网页层面的轻应用，它对移动硬件的调用能力依赖于浏览器的支持，然而不同版本不同内核的浏览器对此的支持区别极大，这就造成了HTML5应用调用设备硬件能力不足、兼容性差的问题，限制了它的可用性。
移动App属于原生应用，对移动设备硬件调用能力极高，应用运行流畅，性能优越是它的优点。但是，移动App开发难度大、成本高是它的劣势，而且移动App易用性差，读者需要下载安装，并进行必要的注册和配置后才能使用。这些不足使得移动App并不适合讲求快捷高效的工具型应用场景。而微信应用融合了HTML5应用和移动App两者优势的技术路径。从技术栈划分属于web应用类型，开发难度低、成本低。同时，它通过微信App封装的接口调用移动设备硬件功能，表现稳定，可用性高，也得益于微信读者的高普及度，微信平台使用门槛极低，易用性佳。综合上述对比分析，构建微信应用能够满足系统的业务需求，技术方案可行性高。
微信公众号平台应用分为消息会话和网页应用两种形式[9]。本文所述的密集书库图书预约系统既具备网页应用功能（网页授权），又兼具消息会话功能（向读者发送微信通知）。
系统在应用配置上，首先在应用服务器上采用IIS+ASP+SQL SERVER的组合搭建开发和应用环境。其次按照微信官方规定，在应用服务器域名上加以授权且使用HTTPS协议进行数据传输，以进行OAuth2.0鉴权。为此，开发前需要完成两项配置：（1）服务器端申请HTTPS key；
（2）在应用拟接入的微信公众号管理平台的“公众号设置”中的“JS接口安全域名”和“网页授权域名”两项填上应用服务器域名，并将官方提供的授权文件放在域名根目录下，完成应用的开发授权。
密集书库图书预约系统采用前后端分离设计，系统架构主要分为用户交互层、业务逻辑层、数据层三层，如图2所示。
图2 系统架构图
上层为用户交互层，遵循HTML5设计标准，营造简洁、易用的用户操作界面。
中间层为业务逻辑层，主要业务内容包括：（1）处理用户请求并返回处理结果；
（2）对接OPAC系统，实现“一键预约”操作，其中的关键业务逻辑包括实现读者无感登录和自动生成图书预约单；
（3）调用微信开放平台接口，包括两组调用：一是调用OAuth2.0鉴权接口实现网页授权后获得读者OpenID，二是调用客服接口向读者发送取书通知；
（4）操作底层数据库。
底层为数据层，由图书预约记录数据库和书目数据库组成。
4.1 对接OPAC实现“一键预约”
为简化读者的预约操作，系统与OPAC实现了无缝对接，“一键预约”隐含了两个业务逻辑，一是自动获取读者在图书馆公众号上的OpenID实现“无感登录”，二是自动完成图书预约单。业务流程如图3所示。
图3 “一键预约”业务流程图
（1）“读者无感登录”业务。由于每个微信公众号的每位访客（不管关注与否）有且只有一个OpenID，因此，OpenID具备作为用户身份标识的条件，实质上就是微信网页授权机制的具体应用，按照Auth2.0机制授权过程包括两个步骤。
① 获取读者授权票据“Code”。读者点击OPAC页面的“预约取书”按钮，随即进入“图书预约系统”的“get_code”页面。该页面负责向微信开放平台的Authorize接口（URL见下文代码）发起HTTPS访问请求以获取读者授权票据“Code”。Authorize接口有两个关键参数。一是参数CALLBACK_URL，指定一个本地页面用于接收微信服务器回传的“code”值。二是参数scope，将其设为“snsapi_base”，可以实现读者静默授权。页面核心代码如下。
② 获取读者OpenID。执行第①步后，微信服务器将“Code”值回传至指定页面“get_openid”。该页面负责向微信开放平台的Access_token接口（URL见下文代码）发起HTTPS访问请求以获取网页授权凭证access_token以及读者OpenID。其中，传入参数Code即第①步所得的“Code”值，APP_SECRET是微信公众号的开发密钥。核心代码如下。
（2）自动完成图书预约单。成功登录后，系统将读者OpenID以及从OPAC传入的BookID传至图书预约单生成页面。核心业务包括两个：① 根据BookID从书目数据库中读取图书书名、作者、流水号信息；
② 将图书信息和读者OpenID、预约时间等信息写入图书预约记录数据库。这是常见的Web应用操作，因此不详述实现过程，读者确认提交即可完成整个预约操作。
综上所述，从访问OPAC书目页面开始至图书预约结束，读者只需两次点击按钮操作即可。这充分体现了“移动优先”的设计理念，以便利读者为指导原则，通过主动对接上下游业务，将复杂的流程隐去，使繁琐的操作简化，应省尽省。给读者呈现出“即点即有”的使用体验。
4.2 主动发送通知提醒读者取书
当馆员取出图书后，系统自动向读者发送微信取书通知。发送过程有两个步骤，一是采用POST方式，将含有发送内容的JSON数据包提交至微信客服信息发送接口，二是微信服务器将通知内容发至读者。这个过程要实现两个关键的业务逻辑。
（1）获取应用token。按微信开放平台规则，向用户发送信息前必须先获得微信公众号的应用token，这与前文所述的access_token（网页授权口令）获取过程类似，核心代码如下：
（2）发送微信取书通知。由于微信使用频率高且新通知以置项方式提示，很容易引起读者注意。因此,能达到及时有效地告知读者到馆取书的效果。系统对于“通知”发送主要包括两个步骤：
① 按规范将发送内容编辑为JSON数据。数据示例如下：body="{""touser"":"""&openid&""",""msgtype"":""text"",""text"":{""content"":""您预约的图书已取出，请尽快到图书馆服务台取书！""}}"。数据包含三项：“touser”是发送读者的OpenID；
“msgtype”是通知内容的类型；
“text”是通知的内容。
② 向微信客服接口发送JSON数据。笔者构建了PostHtml函数实现该功能，包括两个操作：一是向微信客服信息接口提交JSON数据；
二是监听处理结果，以确认微信服务器是否接收到数据。核心代码如下：
4.3 读者扫码取书
为了简化读者取书过程，系统实现了读者扫码核销取书功能。业务过程如下：
（1）读者到达服务台后使用微信“扫一扫”扫描二维码，系统跳转到取书凭证页面。
（2）取书凭证页面的业务流程如下：首先，经过微信网页授权获取读者的OpenID。其次，根据OpenID查询到读者的图书预约记录，并读取已出库图书的取书凭证号。最后，向读者返回取书凭证号供馆员核验取书。整个过程的关键点在于获取读者的OpenID，这与网页授权过程相同。
与早期的图书馆移动应用相比，当前的微信应用技术方案具有两个重要特征：一是实现了统一身份认证，二是实现了由线下到线上的交互。这两个特征分别从应用深度和应用广度上拓展了图书馆移动服务的范围。因此，密集书库图书预约系统于2021年7月上线运行，至2021年12月止，系统方便了读者取用密集书库图书，提升了馆藏使用率，据数据显示，馆员共接收并完成预约取书512本，月均85本，相较于系统应用前月均39本的图书取用量有了大幅增长。可见，当前的基于微信开放平台的移动应用方案已较为成熟。
一方面，在深度互联网化方面提供了良好的解决方案。在移动图书馆服务中，身份标识与认证机制从封闭走向开放意义重大，开放身份认证可使大量的“无证”合法读者也能够顺利地“触及”图书馆的移动服务，而且它还消除了横亘在图书馆和读者之间的“最后一公里”隔阂，使得移动图书馆服务不仅是“可得的”而且是真正“可及的”，远在“云端”的服务下沉至读者身边。如在本案例中，以微信OpenID作为读者身份标识完成图书预约流程。采用非图书证账号作为身份标识的微信应用案例还有广州图书馆、苏州图书馆、湖南图书馆等。
另一方面，情景化交互可让系统“瞻前顾后”多做事，而让用户少操心，实现了智慧化。情景不仅包括线下的实体环境要素，如位置、时间等，还包括虚拟的业务流程。在情景化交互中，系统应用要具备自动感知读者周边环境要素的能力、具备根据读者所处的业务环节主动对接上下游业务的能力，如登录操作、预约操作等。在本案例中，读者预约图书只要一键操作即可完成，其中隐含着对读者所需图书的感知和状态判断，以及读者登录、表单填写、发送取书通知等上下游业务流程的交互处理。这就是情景化交互的好处，也是对“移动优先”理念的具体实践，是做好微信应用开发的关键导向。
当前的图书馆微信应用目标是让移动图书馆服务既要真正到位，不能因“数据孤岛”问题使服务可见而不可及，又要真正易用，不能因循守旧，将旧业务流程放进微信应用的“新瓶”了事，而是真正地以情景化交互为开发导向，革新业务流程，重构服务模式。通过运行该系统可以说其应用效果达到预期，基本满足了业务需求，但在使用过程中仍发现一些待改进的问题.
（1）从读者使用的角度来看，由于预约系统只对接了手机版的OPAC，没有对接PC版的OPAC，因此存在一定使用局限。对此，后续需要实现PC版OPAC和系统的对接方案，一种实现思路是在PC版OPAC的书目页面显示二维码，读者用微信扫码后跳转至预约系统。
（2）从馆员管理的角度来看，存在着读者预约后放弃取书但馆员不知道，以及预约图书找不到但馆员不能通知读者的情况，虽然数量不多（29例），但是也暴露出馆员和读者信息沟通不畅的问题，后续需要增加双方的沟通功能。
本文在总结当前图书馆微信应用研究和实践的基础上，深入阐述了利用微信开放平台构建密集书库图书预约系统的实践方案，重点展示了微信应用在实践中如何有效地推进移动图书馆服务的深度互联网化和情景交互化。限于篇幅，本文所展示的应用场景有限，除上文提及的应用接口外，还有多种接口适用于图书馆的移动服务场景。例如，GPS及iBeacon系列接口适用于读者到馆签到；
图像接口、消息接口适用于个性化的阅读推荐等。微信应用开放平台为图书馆提供了一个强大而实惠的技术实施载体，只要以读者需求为中心，以情景化交互为导向，开放思路，大胆实践，图书馆就能构建出让读者喜闻乐见的新服务模式。
