级别： 初级 Mike Padilla (mikepadilla@hotmail.com), 用户体验设计主管, Radian Guaranty
2006 年 10 月 17 日 企业应用程序集成（EAI）是所有大型企业的 IT 部门都感到十分头痛的事情。将各种不同的应用程序集成在一起的价值就在于集成后这些应用程序可以共享已经建立好的业务数据和业务过程。从信息架构到品牌建立，如果应用程序能集成各种用户体验来共享统一的用户体验（UUE），那么这样的应用程序更易于了解并可提高资源使用效率。定义 UUE 的标准、范式和模式还有助于使用可重用组件，从而加速设计和开发过程。集成用户体验（UX） 肯定要承受一定的挑战和困难。如果处理得当，当用户与企业的应用程序进行互动操作时，它可以提供一种统一、熟悉、高效的舒适感，同时还能缩短开发周期。
一般地，家里都至少有三个遥控器：一个电视遥控器、一个 DVD 播放器遥控器、一个 VCR 遥控器。当然，可以购买一个万能遥控器来控制所有家用电器，但我们都不愿意也不会花钱或花三个月的时间来专门学习如何操作这种遥控器。那么，如果这三个遥控器能让我们享受统一的用户体验该有多好？如果它们对应操作的按钮能在类似的位置、外观相同而且感觉也一样，那么，操作这些遥控器该有多简单？如果这些遥控器都能用同一型号的电池就更好了，就可以轻松地确保这些遥控器能正常使用了。这样，最终拥有您垂涎已久的 TiVo 的日子就不远了。如果 TiVo 的遥控器能提供与其他三个遥控器相同的用户体验，生活就更美好了。
使用共享 UUE 的应用程序，您在办公室里的日子也可以同样美好。如果使用 Microsoft® Word®，再使用 Excel®，然后再使用 PowerPoint®，就能体验到 Microsoft Office® 的 UUE。每个应用程序都有独特的功能，但都用同一方法执行常见的操作和行为。例如在所有 Office 应用程序中，都可以通过文件 | 编辑 | 视图 | 插入 | 格式 | 工具 | 窗口 | 帮助等顶层菜单来访问各种功能。当学会一个应用程序后，就可以将学到的操作方法应用到其他应用程序。随着访问每个新应用程序次数的增多，花费在了解如何与其进行互动操作上的时间将越来越短，这样就可以将更多的时间用在了解新应用程序的独特功能上。
一个欢乐的大家族
任何应用程序都属于一个由其所共享的物理用户体验定义的全球的大家族。普通的 UX 由一组通用特性定义，这些特性允许用户与使用同一组基本概念的不同应用程序进行互动操作。用户可以通过一台计算机来访问应用程序，用鼠标和键盘作为输入设备，用显示器作为接收反馈信息的设备。当用户学会这些基本的互动操作后，就可以更轻松地与其他应用程序进行互动操作了。
这个全球家族中包含了多个越来越通用的系列应用程序集，并且这些应用程序集的数目还在不断增加，关系也更加紧密。尤其是 Web 应用程序，可以统一这些 Web 应用程序的一个或多个方面的 UX，包括站点结构、页面结构、元素结构和外观 （参见 图 1）。
- 站点结构：应用程序的信息架构，用于定义页面流程
- 页面结构：应用程序的页面布局，用于定义页面的各个部分以及各部分对应的信息和功能
- 元素结构：选项卡、表头和表等用户界面元素，用于定义站点的互动操作、设计和结构
- 外观：应用程序的特色，包括标志、字体系列和色彩搭配
图 1. 通过通用 UX 特性统一 Web 应用程序
IBM Web 站点是横跨了海量信息的 UUE 的优秀例子。该站点采用了全球信息架构，其顶部的横幅有效地担当起了标识的角色。无论您深入到站点的哪个部分中，顶部横幅始终都在。在整个站点内，所有页面共享一个通用的结构：全球标记、特定于节的左侧浏览，特定于节的内容区域和页脚。链接、标题、输入元素、选项卡和侧栏等元素都按照同一式样设计和运转。这样一来，所有页面的一致性将非常好。无论在 IBM 站点中的哪个位置，都会知道自己在 IBM 站点中 —— 这样一句看似平凡的话，实际上却对市场部的品牌专员极为重要。
那么，IBM Web 站点中的 UUE 为究竟为用户提供了什么呢？用户能够更便捷地使用整个站点，因为一旦用户熟悉了一个页面后，也就熟悉了所有 10000 个页面。用户能够知道怎样浏览，哪儿最适于查找特定的信息，哪类信息可能可用。由于站点的外观一致，用户就可以推断在一个部分学会的互动操作会适用于整个站点。
更重要的是使用 Web 站点的认知负担降低了，因而用户可以将精力放在要应用到手头任务上的其他认知资源上。例如， Web 站点的 UUE 会让您无需将精力花费在 1）如何使用 IBM Web 站点和 2）了解关于 Rational® Methodology 这两项任务上，而只需关注于后者就可以了。
纯可用性的数字关系
评估 UUE 的优势时，一个应用程序相对于另一个应用程序的可用性与每个应用程序单独的绝对可用性同等重要，甚至更重要一些。必须在彼此的上下文中使用的两个应用程序可能都很优秀，可分别提供独特的用户体验，但两者结合在一起后的可用性可能因缺乏 UUE 而降低。
跨多个系统的整体纯可用性跟各个系统各自的可用性比较的结果可能会让人吃惊。表 1 显示了可能出现的情况，标准为 1 到 10 个等级 （10 级为最佳）。
表 1. 纯可用性
| 两个应用程序有自己独特的用户体验 | 两个应用程序共享一种通用的用户体验 |
|---|
| 应用程序 1：独立可用性为：10 | 应用程序 1：独立可用性为：10 | | 应用程序 2：独立可用性为：10 | 应用程序 2：独立可用性为：6 | | 两个应用程序结合后的纯可用性为：7 | 两个应用程序结合后的纯可用性为：9 |
例如，一家保险公司要求理赔代表必须访问 Web 应用程序 1 获取客户信息，然后必须访问 Web 应用程序 2 获取理赔信息。要处理一个理赔事件，她必须先使用 Web 应用程序 1 找到客户并生成一个理赔编号，然后必须使用 Web 应用程序 2 来访问生成的理赔编号，输入理赔信息，然后提交该理赔事件。如果两个应用程序拥有一个 UUE，理赔代表就能够在两个应用程序之间来回切换，这要比不能来回切换要方便得多。当她使用两个不同的应用程序时，感觉上好像是一个。
慎用 UUE
并不是所有应用程序都有必要集成到一个 UUE 中。UUE 是由一套标准定义的。跟任何标准一样，必须合理应用它们。盲目强制将所有应用程序都集成到 UUE 中不会带来任何好处。这些标准对于大多数情况都适用，但也总会有例外。这就需要确定统一多个应用程序的用户体验的程度。在某些情况下，只单单应用一致的企业品牌要素就足够了。
在某些情况下，让应用程序的用户体验之间存在差异也是合适的。例如，一个公司拥有企业内部网、外联网和公开的 Web 站点，它们为不同的访问者提供有有针对性的信息。如果一个员工可以访问全部三个站点，那么该员工必须要能轻松地辨别出自己所处的站点，以便他能轻松地推断出正在阅读的信息是否需要保密。如果这三个站点被模糊地集成到一个 UUE 下，该员工就有可能会意外地泄漏他在企业内部网上读到的信息，因为他以为此信息是公开信息。
通过在多个应用程序之间采用通用标准，有效地建立了单一的依赖性。当然，只要那些标准建立得足够好，问题不大。但如果某一个标准定义得不恰当会发生什么情况呢？就必须快速高效地更改应用了该标准的每个应用程序。开发应用程序有很多高效的方法，如包括层叠样式表 （CSS） 和模块化代码片段，使用它们可以轻松地执行一些批量更改，但您却没办法通过按一次按钮就能完成诸如重新设计信息架构这类更改。因此定义出规定严格的 UUE 标准至关重要，因为要将这些标准嵌入到很多应用程序中。
对新应用程序应并入已有 UUE 中的程度的评估相对简单。评估已有应用程序应并入已有 UUE 中的程度相对复杂一些。拥有了一批用户的应用程序具有干扰性。因为用户熟悉这个系统，尽管该系统在实际使用时非常复杂。随着时间的推移，用户有了使用此系统的经验，已经适应了该应用程序。人在适应环境后，很容易抵触要发生的变化。
新的 UX 必须要能提供足够多的长远益处以不枉用户为适应新的应用程序所做的调整和努力。但是不管新的 UX 有多么好，转变都会带来痛苦。改进的 UX 应当从根本上提高使用效率，并能缩短新用户的学习时间，使用户能够很快上手。
统一但模块化
跨多个应用程序使用 UUE 可能就像把所有鸡蛋放到一个篮子里一样。怎样能轻松地交接篮子而不打坏一个鸡蛋？答案就是采用模块化设计。可以将内容 （鸡蛋） 与表示方法 （篮子） 高效地分割开，并通过将链接的模板、代码片段、CSS 和 JavaScript 文件组合在一起单独控制表示方法。使用模块化设计，可以通过更改几个链接的文件就可改变整个外观、结构，甚至互动操作行为。
通过提取 Web 应用程序中的通用模式，可以发现应用程序中可模块化的那些部分。大多数 Web 应用程序的通用模式集涉及到创建、读取、更新、删除 （CRUD） 功能。例如，您的 Web 应用程序可能提供了对客户、账单、产品和评论等多个实体的访问功能。对于每个实体，一个通用模式会出现 —— 用户执行一次搜索，选择一个实体，查看详细信息页面，然后 CRUD 该实体。
这些页面的流程定义了站点结构。虽然不能轻松地将站点结构模块化并重用该站点结构，但可以将一个页面模板应用到与 CRUD 操作相关的所有通用屏幕中的任意一类实体上。可以定义搜索页面、结果页面、实体详细信息页面、创建实体页面和编辑实体页面的模板。可以将每个模板应用到多个实例中，从而获得单点的维护性和一致性。
页面模板用于定义页面的框架结构。可能会在页面内看到按照通用模式显示的信息。例如，很多页面可能都有标题、页面引导、搜索框和水平分割符。只要将此元素结构保存一次，就可以在整个站点内重复使用该元素结构。
需要在哪些内容应当转换为模板而哪些内容不应当转换为模板之间找到一个平衡点。其原则是某个组件的重用频率及其复杂程度的产物。字母 a 可能在整个应用程序中经常重用，但这不意味着应当为这个字母制作一个模板。一种独特的数据布局可能会在两个位置用到，但可能也不必为此制作模板。使用模板引入了一定程度的复杂度，但如果能恰当地规定模板，它们就能简化操作。
 |
模板引擎
模板引擎可帮助开发团队创建数据与表示方式分离的 Web 应用程序。一些常用模板引擎包括：
TeaServlet：
TeaServlet 是顶级的 Servlet API 框架，使用 Tea 模板语言。使用该模板引擎必须要有 Servlet 容器才能运行。
WebMacro：
WebMacro 是用高效的、轻量级脚本语言 Java 编写的模板系统。对于数据与表示方式的分离，WebMacro 人经常说：“您不关心的就可以不显示”。
FreeMarker：
FreeMarker 不是 Web 应用程序框架，但适于作为 Web 应用程序框架中的组件。它基于模板简单地生成文本 （HTML 或任何其他文本输出）。
Velocity：
Velocity 允许引用 Java 代码中定义的对象。它是 Apache Jakarta Project 的一部分。
|
|
Java™ 编程语言的作用是许多开放源码的模板引擎，包括 TeaServlet、WebMacro、FreeMarker 和 Velocity （请参阅 参考资料）。通过这些工具使用模板方法的另一个好处是您可以通过内容与表示方法的分离在 üBER 和较少的技术类员工之间实现劳动力的合理分工。
我们来近距离接触一下 Velocity，例如，查看如何模块化设计及将内容与结构化表示方法分离。使用 Velocity Template Language （VTL），可以在上下文中为访问对象创建 引用。通过这些引用可以访问数据。可以在多个模板中使用同一组引用。使用用于控制和操作的 指令，可以使用一个模板，并且可以有条件地放弃某些引用。
例如，使用用户配置文件屏幕，可以使用单个模板查看个人的配置文件、其他成员的配置文件或产品配置文件。指令将根据会话上下文的引用算出通过引用显示哪些数据。同时页面结构保持不变，只有内容发生改变。
如果能有条件地呈现整个页面部分而不是一点点数据，就可以用 Velocity 来实现更高级的模块化设计。而这些页面部分又可以有条件地拉出数据。通过使用连接两个页面的布局模板文件、独立的页面组件文件和配置文件，就可以将各种模块放到一起构成一个合成页面。可以在多个模板之间使用页面组件文件，还可以更改模板来修改布局而不会影响数据。
Velocity 配有 Velocimacro，使用它可以指定一大块 VTL 代码并将参数传递给 Velocimacro。可以将这些 Velocimacro 看作小模板。例如，您可以定义一个表结构 Velocimacro，并将 CSS 类、ID 和数据源传递给 Velocimacro：
#macro( dataTable1 $cssClass $id $memberlist )
<table class=$cssClass id=$id >
#foreach( $member in $memberlist)
<tr><td>
$member
</td></tr>
#end
</table>
#end
|
当设计人员需要在 Velocity 模板页面中包含一张表时，该设计人员只需输入以下语法及相应的参数：
#dataTable1 ( "gridLayout" "fanbaseInfo" $fanclub )
|
假定从现在开始一个月，所有这些表必须都变为空行。您只需要更改 Velocimacro 定义，更改就会被传播到所有实例中：
#macro( dataTable1 $cssClass $id $memberlist)
<table class=$cssClass id=$id >
#foreach( $member in $memberlist)
<tr><td>
$choice
</td></tr>
#end
<tr><td> </td></tr>
</table>
#end
|
模板用于处理较高级别的页面结构模式，而 CSS 可以解决模块化样式中的细微表达方法问题。从页面中的字体到表的边框，都可以为其定义样式。通过在一个链接的文件中定义 CSS 类并将该 HTML 格式的类应用到元素上，可以进一步削弱表示方法与内容之间的关系。例如在一个完全由 CSS 驱动的布局中，只需替换样式表并将适用于传统 PC 的表示方法更改为适用于移动电话的表示方法。同样，可以更改 Web 应用程序的整个风格。参考 CSS Zen Garden 来查看如何更改（请参阅 参考资料）。
值得注意的是不但可以将信息的表示方法模块化，还可以将互动操作模块化。从包括 Yahoo!、Google、Dojo、Rico 和 script.aculo.us 在内的很多资源中获取的幻灯片、日历、自动完成和拖放等互动元素和操作都可使用 （请参阅 参考资料）。随着 Asynchronous JavaScript with XML （Ajax） 的功能逐步增强，可以让更多实用程序与数据单独进行互动操作，而无需刷新整个页面。
要想看到模块化操作在开发 UUE 中的真正实力，就看看我们所熟悉的浏览多条记录功能。大多数应用程序都通过在每个页面显示固定条数的记录以及链接到各个页面的页码的列表共同来实现此功能。当然，也可以使用结果页面模板和分页机制代码片段来实现此功能。但如果在不同的应用程序中，问题可能就会，一个页面应当显示多少条结果？是否需要配备页码和后退/前进链接？是否需要配备文本字段以便用户可以跳转到某个页码？如果需要，是要配备 Go 按钮，还是仅假定用户会单击 Enter？
Ajax 小工具可以解决所有这些问题。通过在固定区域中显示所有结果，用户仅需上下滚动即可浏览所有记录。Ajax 的功能是仅拖动视图中的记录，这样就不必把所有记录下载到本地。可以在许多应用程序中使用这个小工具。由于应用程序可以都通过一个指向 JavaScript 源文件的链接使用相同的源代码，因此就可以轻松地管理对该源文件行为的任何调整。可以在 Rico 中看到如何调整 （请参阅 参考资料）。
结束语
我们生活在一个受标准控制的世界里：红灯停，绿灯行；地址要有门牌号、街道、城市、省或自治区以及邮政编码。各种标准提供了一个上下文框架，使您可以更轻松地处理信息。同样，在各种 Web 应用程序中也可以应用标准。但由于标准作为核心资源被分布到多个实例中，因此当需要更新一个标准时，您可能会面临一些困难。幸运的是，使用 Web 应用程序时，如果能够正确规划和实现模板、CSS、JavaScript 和 Ajax 行为，您就可以很从容地应对此类全局更改。
参考资料 学习
获得产品和技术
讨论
关于作者 | 
| | Mike Padilla 是 Radian Guaranty （RDN） 的 Web 应用程序用户体验设计主管，负责定义从信息架构到品牌集成，甚至富客户机 UI 结构等工作。Mike 曾帮助 Fleet Credit Cards、Mellon Private Asset Management、The Bank of New York 及 Bessemer Trust 等公司取得了最前沿的开发成果。Macromedia 就采用了他的可用性设计。他毕业于康奈尔大学，获得机械工程学士学位，主修人机工程学。您可以通过 mikepadilla@hotmail.com 联系 Mike。 |
对本文的评价
| 
