Web作为一个不断发展的开放平台,使桌面客户端具有更丰富的用户界面。这促使产生了用户驱动来管理客户服务交互系统的方式,并借助丰富的交互控件与Web 2.0工具使SOA包含了对Web内容与服务的访问。然而这种基于Web 2.0技术的客户服务交互系统的可用性却经常被忽视,以至现有网络系统的可用性测试技术已不能保证基于RIA技术客户服务系统的可用性。
Web 1.0时期的焦点是内容传送与通讯,Web 1.5是内容的个性化与多级通讯的展示,Web 2.0则强调“创作与协作(authoring and collaboration)”,这成为创建丰富SOA客户服务交互系统的关键,并将提高SOA在互通性、可重用性及标准化等方面的性能。Web 2.0使用CSS、JavaScript等技术标准实现有吸引力、可交互、集成的内容和服务,并让用户将注意力集中到业务与顾客上,而不是界面。
图1 Web发展轨迹
基于RIA(Rich Internet Applications)技术的SOA客户服务与静态HTML网页和门户相比能提供更好的用户体验。这是因为:
·交互能力强大且具有吸引力的界面。由于桌面系统拥有丰富的界面资源和极快的响应速度,用户通过控件可以很容易地得到需要的内容。
·由于实时输入验证技术和数据响应速度,可以直接在客户端对数据进行处理,实现流畅的单页面浏览而无需逐页浏览。
·可以即时取消、刷新与下载,而无需等待。
·没有顺序上的操作限制,并可随时查看历史页面。
·更丰富的网页内容,比如网格、弹窗、对话框、表格、上下文菜单栏和右键菜单栏,并可进行拖放和调整等操作。
·RIA程序安装升级简单,并有很好的操作系统兼容性。
·有评论和反馈机制的分散化社交网络,可以达到充分协作的目的。
与HTML相比,RIA程序在实现复杂的交互功能时更强大,更有吸引力。然而,它们也会有如表1中所列出的用户体验方面的问题。
表1 降低的用户体验
RIA | 可用性上的后果 |
受业务影响的设计方案 | 业务模型存在缺陷 |
集成能产生收入的特征 | 忽略基本功能与目标 |
为减少部署成本从桌面程序到浏览器程序的转变 | 传统的桌面系统运行速度变慢;浏览器程序不足并受到限制 |
定制的设计方法 | 界面复杂,用户难以适应 |
实现RIA可用性面临的挑战
实现RIA可用性面临的挑战包括:
·复杂、繁琐的内容呈现方式:目前还没有统一的标准。
·无法预料的RIA控件行为:用户使用RIA控件时必须小心谨慎,显示与消失的速度太快,可能给用户带来各种不愉快的体验。
·并行操作时的导航与命名规则混乱。
·关闭JavaScript功能时无法调用服务器端程序,没有数据传送的页面也无法访问。
·AJAX更新速度过快,弱视与盲人(使用点字或语音系统的)用户很容易错过相关信息。用选择按钮或跳窗添加适当的警告信息可以提高信息的可读性,改善盲人用户体验。
·过多的最优化选项会降低许多人的用户体验,这些人习惯于使用交互功能较少但容易学习的方式。并且,这时用户必须能辨别所有交互页面元素或控件的用处。Don Norman在《日常事务设计》(The Design of Everyday Things)一书中称这些元素与控件为可体验的功能。为这些控件制定统一的标准可以使用户利用以往的经验快速掌握使用方法。问题在于如何开发人性化的交互应用,并为鼠标驱动的事件提供可选的键盘操作。
·RIA程序有页内刷新的功能,当使用后退键时有可能回到同样的页面,会让用户感到困扰。静态网页刷新和页内刷新需要不同的导航系统。
基于RIA技术的网络和客户服务交互系统需要通过可用性来改善用户体验,并吸引用户再次访问。这些系统必须在保证流畅的任务流基础上提供更好的可访问性、视觉一致性、准确性和吸引力。设计这种系统时需要考虑以下基本问题:
·访问这些系统的用户的目的是什么,他们退出的原因又是什么?
·页面排版与表格样式是否足够直观?交互性能是否足够强大?能否留住用户?
·网站导航和命名系统是否一致,以满足灵活的任务流的需求?是否有网站地图?
·内容是否方便所有类型的用户在线阅读?
·网站在服务与用户体验方面有与同类站点的竞争能力吗?
·页内刷新后能准确显示对话框吗?新浏览窗口中的功能是否易于初级用户使用?
·实现的控件有合适的反馈机制吗?可体验的功能是否有充分的机动性?
·信息搜索是否需要用户投入太多注意力和使用太多点击、拖曳和滚动等鼠标操作?页面是否过于混乱?
·我们能提供像静态页面那样的多种内容搜索方式吗?
·客户是否了解信息产品与服务的呈现机制?
·主页上的宣传、描述文字与图表是否表达了正确的信息?
·是否有能方便有效地从用户收集信息的机制?
·最后,用户行为是否必须遵从网站的设计方式?要知道我们开发的功能必须可以让用户自由使用。可用性测试可以指导开发人员设计这种无需用户改变习惯行为的系统。
RIA应用程序的可用性测试
可用性测试可以评估RIA应用程序的易用性与易学性。可用性需要在业务需求、技术潜力和用户期望之间选择一个最优化平衡点。一般来说,可用性指产品可以在特定使用环境下让特定用户有效、快速并且满意地取得特定目标的性能。我们为RIA应用重新定义可用性为:用户利用丰富的控件资源交互、独立、一致地完成既定目标,并在更短的任务时间内获得更好的用户体验。这样人机交互(HCI)则可定义为:涉及RIA应用的设计、评估和实现,并研究传统的用户期望与诸多新技术之间最优平衡的机制。
RIA程序的可用性测试包括根据可用性描述对用户界面进行分析、利用工具或第一手资料对用户使用Web 2.0控件的任务用时及满意度进行评估,以及对程序缺陷提出修复建议。一种常用的方法是,在实现具有特定业务功能的富widget程序并使用传统的易用工具时建立一组最优的限制条件。毕竟传统控件还将存在很长时间,并且富交互widget程序和RIA技术要获得广泛应用也需要时日。下表是RIA应用可用性测试的几个方面。
表2 可用性测试的优势
对象 | 可用性测试的优势 |
用户 | 易学,减少任务时间与错误,提升满意度,易用 |
开发人员 | 提高用户接受率,为用户减少技术支持与培训,减少软件开发与修正花费的时间和精力 |
设计人员 | 可以确定有效设计,避免无效设计 |
公司 | 减少再设计、开发与技术支持成本,提高规模,提高交易量,提高用户生产力和功能使用率 |
整体 | 经济,可应用于从原型到成熟产品的任何阶段,定位及时,无需任何特殊的测试设备 |
可用性的计划与优先分级
设计这样一个系统需要对可用性有全面的了解,并确定网站的用途与目标。开发过程中我们应该将精力放在开发样式上,并了解其在终端用户的运行方式。系统应该按照实现流畅的任务流的理念进行设计。实现RIA程序的可用性需要判定在新页面上应该执行的功能和部分页面的刷新内容。将评论与用户生成的内容相结合可以提高RIA程序的可用性。设计方案应该考虑到视觉体验与用户行为。RIA环境下需要计划的任务与使用的技术主要有:
表3 可用性技术
可用性检查 | 迅速、高成本效益的方式检查RIA设计方案的可用性缺陷,确定需要丰富或无需改动的功能。 |
样例实验 | 观察用户与RIA控件的交互,确定设计方案的有效性。 |
Web标准的设计 | 根据W3C标准进行评估,根据业务需求和技术条件进行分析,减少页面装载时间,提高带宽利用率、可维护性、可访问性、兼容性和对新设备的支持。 |
卡片分类 | 反复研究用户如何使用架构和搜索信息,有效利用信息内容。 |
导航系统 | 提供一致、快速、易用的导航系统,使用户获得灵活流畅的任务流。 |
击键次数模型分析 | 分析减缓用户速度的特殊原因,确定可以保留的控件而不是全部推翻重新设计。 |
教学设计 | 有效利用设计方案展示RIA控件独特的一面,告诉用户为什么和如何使用RIA控件,并为用户提供必须的说明,加快用户学习使用新界面的速度。 |
竞争力分析 | 对产品的可用性进行评估,包括公司产品及其它有竞争力的产品。 |
可访问性检查 | 采用最低限度的功能与方案实现低、中、高层次的可访问性,并在文本浏览器和语音系统中验证。 |
易察性 | 结构内容应该容易被发现,确定终端用户能够明白并使用产品或功能。 |
用户测试 | 通过对目标用户使用Web 2.0新功能完成任务的观察确定主要的可用性问题。设计团队可以在修正bug后进行启发式设计方案的评估,取得程序丰富度与效率的平衡点。 |
测试工具 | 检查记录器、远程查看器和再现功能,记录、观察、分析并共享任何可以发现可用性缺陷的位置。这让可用性测试变得简单、迅速并且准确,还能进行远程观察,记录鼠标、击键和网站点击操作。 |
视线跟踪 | 利用图像采集系统观察用户查看网页时视线移动方式,利用热图确定吸引用户注意力的主要区域,分析什么能吸引用户,什么被用户忽略。 |
生理检测 | FMRI(功能性核磁共振技术,检测脑细胞的活动)、GSR(皮肤电反应,检测情感变化)、皮肤传感器可以检测流汗、体温和心率的变化。这些可以有效地帮助分析用户对界面的反应 |
色盲检查 | 假定一些色盲的情况,研究用户对网站特征的反应,并制定相应纠正方案。 |
RIA控件可用性的整体视图
图2 整体视图
可以认为,任何可用的RIA控件都有四个特征:
能力:开发人员利用迅猛发展的网络技术提供富交互控件的能力。
功能性:指从整体上改善用户与业务的任务时间、输入和实时解决方案的特征。
负载:指能改善用户体验并提高业务收入、实现可定制的交互性RIA控件基础设施的性能。
易学性:指widget程序要在保持易用性的同时,还要便于用户从以往的经验中学习。
图3 各特征涉及的方面
满足可用性的这四个特征,便是成功的应用,可以留住客户、提高易学性和用户体验并满足用户的要求。这有利于清晰地表达重要的设计决策,比如在满足现有设施要求并减少用户任务时间的同时添加丰富度,需要明白现有功能将获得怎样的提升。
RIA程序可用性的最佳实践
坚持以下基本理念:实现新RIA技术之前,让一位有经验的可用性测试人员寻找可用性上的缺陷。设计人员应该根据可用性的各个方面重新进行设计。并且,重点也应该放在保密与安全性协议,以及如何提供错误处理备选方案上。RIA程序的可访问性要靠浏览器的JavaScript功能实现。浏览器应该可以检测JavaScript功能是否开启,并为用户打开正确的表单。
·使用AJAX技术改善用户体验:可以加入易学易用并能提高效率的RIA控件,并避免提供无用的功能。
·为用户着想:RIA技术可能会让用户感到无从下手,开发前应该确定目标用户群与预期功能,让用户获得满意的效果。
·可用性检查:请一位可用性方面的专家来根据可用性标准判断RIA程序的有效性,及早检测可能存在的问题。
·可用性测试:参与人员应该进行有效的测试,对设计方案的有效性进行评估,并公布测试交互方案的结果。
·报告:在保留现有功能的同时,分别报告近期、远期和必须实行的建议与修正内容。
结论
客户是实现SOA服务的关键。Portal程序与Web 2.0是SOA客户服务交互系统的关键组成部分。Web 2.0初期将RIA控件的多样化作为开发重点,而不是终端用户。为吸引用户注意力,需要用正确的方法实现可用性,以避免RIA技术设计上的缺陷。这需要正确地使用可用性工具与技术。本文主要讨论基于Web 2.0 RIA技术系统可用性的各个方面,并介绍可帮助RIA开发人员与终端用户减少任务时间、用户错误、中断次数、培训时间、维护精力和再设计成本的技术。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
翻译
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
docker当作web环境好吗?