第二章 可重用铁三角

在本章中，我们将深入探究可重用策略中的三个组成部分，以便在后续的内容中你能更好地理解设计模式、组件和交互设计框架体系三者之间是如何相互关联、相互协作的。

可重用铁三角的诞生并非轻而易举，产生的顺序也绝非符合逻辑。模式的概念最初始于Christopher Alexander 于1977 年写的书， 其后又被Luke Wroblewski 、Bill Scott 、Martijn van Welie 、Theresa Neil 、Christian Crumlish 、Jenifer Tidwell  等模式倡导者和众多业界专家所普及和发扬光大。

正是在他们的努力下，模式这一概念目前已被推广到了Web 设计实践的前沿。而组件——表示模式自然演变的完整的、生产就绪的页面元素——则出现得颇晚，至少在软件设计领域是如此（与开发相比）。

事实上，尽管有关组件的想法雏形已经酝酿了数年的时间，但它才刚开始作为一种概念被标准化。这要特别感谢来自EightShapes 的两位设计师Nathan Curtis（著有《模块化网页设计：为用户体验设计和存档而创建可重用的组件》
一书，New Riders 出版社）和Dan Brown（著有《设计沟通十器》一书，New Riders 出版社）所付出的努力。而框架体系则是拼图的最后一块，在你手中这本书里首次以正规文档的形式记录下来。然而，在实际工作中，我们应该首先考虑框架体系，模式其次，最后是组件。如图2-1 所示，这也是它们在网页设计过程中最为有效的使用和思考顺序。

设计模式实际上就是隶属于大型框架体系的生产模式。而组件则是针对具体某个系统对模式进行实现后的产物。它将模式具象化为网站或应用界面中的一个部件，使之能够通过网络被直接交互。

接下来我们会按照构思这些元素的顺序逐一进行深入讨论。无论你对模式和组件是否熟悉，预先了解这些框架体系的基本组成部分，都将有助于我们建立起正确的大局观。

2.1　设计模式

设计模式其实是一种针对某个常见问题的常用解决方案。比如分页模式就为我们呈现了一种标准的交互接口，它将搜索结果以多个页面显示，同时在每个结果页的底部加上指向不同页面的链接。这种设计通常会包含Previous（上一页）和Next（下一页）按钮、通往其他各个结果页的数字序号链接以及一个指示当前页面的视觉标志，如图2-2 所示。

似乎很眼熟？本应如此。在每一个雅虎搜索结果页面的底部，你都能见到它。

也许雅虎并不是第一个使用这种设计的网站，但是雅虎的版本被使用的频率如此之高，其他几乎所有的搜索系统都或多或少沿用了它。这使它变成了一种模式——取得了巨大成功的模式。实际上，它已经被不计其数的模式资源库（无论是公共库还是私有库）所收录和引用。

设计模式所带来的首要好处就是，用户能够将自己在某一个网站上的体验转化为通用的操作经验，运用到其他所有使用相同模式的网站中去。在雅虎上进行了数次搜索之后，用户就能很轻松地理解其他任何使用了相似设计的分页界面，不管是在哪个网站。

而另一方面，设计师们从中也获益匪浅。因为模式能够为大量典型的设计问题提供“罐装”的解决方案。不必为每一个新网站都思考和创造新的搜索导航系统，我们只需要拿出分页模式，做一些小小的调整就可以了。

数年来，许多成熟的设计模式已经成为互联网中的模块，这无疑是明智之举。而框架体系的构建前提就是成功的模式。

2.1.1　设计模式六要素

要想更好地理解模式，我们不妨看看在一份标准的设计模式描述文档中都包含些什么，如图2-3 所示。Jared 的公司UIE 列出了以下六要素。

1．模式名称

如果我们正在讨论一个元素，它使用户能进入到网站受密码保护的区域，那么我们也许会称呼它为“用户名和密码控件”、“两行式登录元素”或者“登录元素”。

模式名称的选择务必要小心谨慎。在此之前，设计中出现了太多的无名元素，以至于在讨论中经常会有类似“那些我们常常放在左边的小方块”这样的说法。而之所以有模式名称，其目的就是为了促进清晰的交流和沟通，这样在会议、设计文档或者其他地方我们就能明确地称呼某个具体元素。

我们发现，为模式命名需要技巧、创造力以及一点点运气。开发团队往往在一开始为某个模式起了名字，过了一阵子发现大家经常使用的却是另一个名字。

比如， 某个开发团队将他们的应用程序的对象属性编辑器正式定名为“Infobox”（信息框），之后却发现团队里根本没人这么说。所有人都叫它“Properties”（属性）。

图2-3 来自Welie.com公 用模式资源库的一份模式文档

有些开发团队在模式的描述中为其添加了一系列的昵称、同义词以及代称（also-known-as，简称aka）。这能帮助团队成员确定他们讨论的对象。我们对事物的称呼常常会随着时间而改变，因此如果模式名称能和当前用词随时保持对应和更新，会带来很大的好处。

2．描述

描述对于一个好的模式来说至关重要。通过描述，那些对该元素不太熟悉的团队成员就能准确地理解大家正在讨论的内容。

由于一图胜千言，界面截图也非常有价值。如果某个模式在同一个网站中有多种表现形式，那么各来一张截图会有极大帮助。

比如，一个登录元素可能会有如下描述（伴随着合适的界面截图）：

一个两行的表单元素，用于采集用户的ID 和密码，从而使他们能够进入网站内受密码保护的区域。

描述无需像文学作品那样精雕细琢，但它应当包含足够的信息来解释该元素存在的理由，并说明如何将它和网站上的其他元素进行区分。

3．上下文情境

与一般的设计指南或样式参考文档相比，设计模式的主要优点之一在于它强调了每一种模式所使用的模式库中的上下文情境。在构思新设计的时候，设计师们可以利用上下文描述来确定该模式是否运用得当。

例如我们的登录元素，有关它的上下文情境可能会是如下描述：

无论何时，只要网站中的某位用户希望从公有区域转向访问私密信息，我们将使用登录元素。在面向公众的页面中，只要有足够155 像素×210 像素的空间，就可以显示该模式。

当然，在这里还需要包括在不使用登录元素时的描述：

如果在某些面向公众的页面中，垂直方向无法提供足够的空间，我们将在页首的banner 横幅处使用单行的登录元素。或者在网站受密码保护的区域中，不使用登录元素。

上下文情境是不断变化的。当开发团队加入了更多元素，开发新的应用程序，发现新的用户需求时，都需要对“上下文情境”一项进行频繁的更新。理想的情况是，在某个模式生命周期的任何一个阶段，设计师都能通过阅读此项而迅速了解该元素是否适用于手头的工作。

4．曾于何处使用

“曾于何处使用”是模式文档中另一个不断变化的部分，它列出了那些使用过这一模式的实例。模式每一次将其转化为生产系统时，都应当对此项进行更新。开发团队成员可以查看已经实现出来的成品，了解某个模式的运转情况。

5．工作方式

开发团队在这里将描述该元素技术层面的内容：

用户在标记有User Name 的输入框中键入他们的用户ID， 在标记有Password 的输入框中键入密码（密码内容会被遮盖）。如果他们愿意，可以点击Remember Me 复选框，以便在重复访问时系统能预先为其填写User Name 输入框。当就绪后，用户点击标记有Log in 的按钮。如果用户名和密码有效，则显示该用户的个人页面。如果无效，则显示错误页面（参见“登录错误”模式）。

需要的细节数量取决于控件的复杂级别，以及团队成员对它的熟悉程度（如果是他们自己经常使用的元素，就不需要像不常见元素那样进行详尽的描述）。曾有一个可用性团队向我们展示了利用视频捕捉来创建演示短片，他们通过这种方式来描述元素的运作机能。

与该元素产生交互的其他模式也会提及，此举能帮助设计师更为全面地考虑问题，便于在最后对设计进行整合。

6．其他必备模式

很少有能完全独立存在的模式。一个模式的出现，通常都意味着设计师还需要考虑其他模式来支持它。

比如说，如果一个设计需要“登录元素”模式，那么它很可能还需要下面这些：

• 创建新用户ID 的模式；
• 修改密码的模式；
• 重新获得密码的模式；
• 从网站的受密码保护区域退出的模式；
• 当输入的用户名或密码不正确时，显示错误信息的模式。

所有这些模式都会列在“必备模式”项中，并附有它们为什么“必备”的相关解释（如果不是很明显的话）。

设计模式的文档中还可以包括竞争性举措、模式历史、可用性测试结果、用户反馈和讨论记录，等等。

2.1.2　模式资源库

如图2-4 所示，模式资源库就是模式文档经过整理、分类后的集合，通常在网上或者企业内部进行公开。

以下是一些公用的模式资源库。

• 雅虎设计模式库：http://developer.yahoo.com/ypatterns
• Designing Interfaces（是同名图书的资源网站，Jennifer Tidwell 著，O’Reilly 出版社）：http://designinginterfaces.com
• Welie.com：http://www.welie.com

在准备使用模式时，许多开发团队都会偏向这些现成的、公用的模式资源库。然而，尽管这些资源库的资料通常都很齐全，而且免费，但它们却无法说明项目中特定的技术限制和业务需求。因此对于具体的项目来说，公用模式库的用处可能并不大。最有用的模式库应该重点关注项目特定的规范和需求。

公用的模式资源库倾向于提供通用的模式，而不会针对某个具体的应用。它们为那些公认的标准Web 交互提供了低级别的基础性建议，而企业往往会根据自己的应用或网站对这些模式进行“定制”，把过于通用的公用模式转化为真正适用于专属设计团队的模式。

尽管如此，这些通用的模式仍然能为我们带来极大的好处。除了能提供基础性建议，为“定制”模式提供一个高起点之外，这种模式库对于“单干”的设计师来说无疑是一种绝佳的资源，不管在企业内工作还是在外面做顾问都是如此。顾问常常会因为客户不同而接触到各式各样的项目，而公用模式资源库能够为其提供适用于大多数网站的无尽资源。

内部模式资源库中的模式则与此不同。它们具有更强的针对性，只对应企业内部的网站，是设计团队手中威力强大的工具。团队可以在内联网中利用wiki或者微型网站来组建资源库，使其贴近自身的设计风格，这样企业中的其他团队在实现新设计的时候就能直接从中取用。

wiki 一词来源于夏威夷语wee kee wee kee，意思是“快”。它其实是一种在网络上开放、可供多人协同创作的超文本系统，由wiki 之父Ward Cunningham 于1995 年所创。基本上，wiki 包含一套能简易制作、修改HTML 网页的系统，再加上一套记录和编排所有改变的系统，并且提供还原改变的功能。wiki 网站允许任何造访者轻松地添加、删除、编辑所有的内容，而且通常都不用登录，因此特别适合团队合作的写作方式。

构建一个模式资源库的主要困难在于协调运作。首先，个人或团队需要从自己的所有案例中翻找、标识出已经在使用的模式，其次他们还需要建立稳固的公布和共享机制，为每一种模式存档备案、为资源库制订长期的维护计划，最后还得为其进行宣传和推广。这可不是什么微不足道的小任务，而且很可能还会经常遭遇到其他更为紧迫、优先级更高、更直接面对客户的项目的排挤。

不过，模式库构建成功以后，它带来的回报将远远超过构建时所付出的努力。如果对某个交互的外观或功能有疑问，开发团队可以立刻派开发人员来回答问题。而且模式是可重用策略的核心板块，随着它的就位，设计师们就能避免在已经非常普遍的方案上浪费时间，而把更多的精力用来迎接项目中那些更为独特的挑战。

2.2　组件

要想介绍组件，也许最简单的办法就是直接引用其倡导者、EightShapes 公司网站上的解释（ 参见http://unify.eightshapes.com/users-guide/what-you-get/wireframe-components/）：

组件是页面设计的一部分。

组件由通用的最基层元素（例如文本、链接、按钮、复选框和图片）相组合而成，它们是在页面的界面设计中可以使用（或重复使用）的有意义的组成单元。其他描述这种页面内集合的常用术语包括模块、元件、控件，甚至是分子。

而在Nathan Curtis 的一次演讲“Creating a Component Library”（创造组件资源库）中，其释义也大致类似：

鉴于我们通常都以一个完整页面或页面状态为单位来观察，同时把页面上无法继续划分的部件（例如一个logo、页首图片或者按钮）称为“元素”——我们可以说，组件是由元素相互组合而成的具有明确目的、可重用的独立结构。标签式导航条、搜索结果、文章内容都是组件。

模式一般都能在各网站间通用，而组件则只对应特定的某一个网站，非常具体。模式适合于交互设计师和其他运用草图、线框图或其他基础手段进行构思的人，而组件则专用于那些负责构建这些设计的人。它们的代码完整，能够重复使用，而且一个模式可以派生出多个组件。开发人员只需要把某个组件直接插入到页面中，定制其中的内容，就可以得到一个完整的页面区域。

2.2.1　组件六要素

组件资源库目前还不是十分流行，因此对现有资源的调查和最佳案例的推测尚不足以得出完善的结论。我们暂时以Sun 公司网站中提供的公用组件资源库为例，列出以下需要包括的六要素（更多内容参见2.2.2 节）。

1．组件名称

在Sun 的资源库中，组件名称都是以页面标题的形式来展现的。不过在模式资源库里，也可以包含一个更为精确的“组件名称”项，提供一系列可供替换的名称。

2．组件版本号

组件的版本号与组件名称和示例（参见后文描述）的标题密切相关。和软件更新时的发布版本说明一样，版本号可以翔实地记载从一个版本到下一个版本中发生的变化。如果需要对之前实现的内容进行更新，版本号能引起开发人员的注意，而且确保开发团队能维持系统的一致性和连贯性。

3．定义

类似于模式里面的“描述”项，组件的“定义”会描述组件的目的和用途。在图2-5 中，组件B01 Features 的定义如下：

首页专题是 sun.com 网站首页中一个较为复杂而又重要的部分。它可以看作是首页推介元素的容器，循环显示首页推介的3 个专题内容。

4．使用方法

“使用方法”项描述了组件应于何处使用，并包含相关信息。在Sun 的“D05 Primary Index Nav”（基本索引导航）页面中，其使用方法如下：

在任何索引页上使用。如果没有额外内容，可以选择是否加入See All（查看所有）链接。

该组件被限制只能在索引页上使用，同时可以从两种方式中选择一种来实现：带See All 链接或者不带。使用方法项注明了这两点内容。

5．示例

示例为我们提供了一个鲜活、生动的组件实例。组件是经过实现后的页面元素，因此在基于网页的文档中，你完全可以添加那些带有完整功能的版本。通过实际的示例，团队内部的所有人都能直观地了解该组件的工作方式（它还能协助质保小组审核已实现版本的正确性）、外观，以及要实现它应使用何种代码。

6．代码

除了一个能运行的示例之外，组件文档中还应该包含一个“代码”项，链接到该组件的已实现版本（包括使用不同编程语言的版本）。如果某个开发团队用 Ruby on Rails 开发了一个应用程序，用苹果的 Cocoa 开发了另一个，而两者都可以使用这个组件，那么它的代码项就应当包括用这两种语言创建的版本。

2.2.2　组件资源库

组件资源库可以用和模式库同样的方式来构建和发布——建立wiki，标识已完成的组件实例，然后为其存档备案。如图2-6 所示，Sun 公司的网站提供了一个公用的组件资源库，可以作为组件如何存档的参考。你能在www.sun.com/webdesign 上找到这个资源库。

而最有帮助的是，Sun 还提供了一个有关如何使用组件的页面（参见http://www.sun.com/webdesign/structuring-pages.html），以一个标准的Sun 内容页面模板为例，对其中的各个区域进行了直观的描述。同时它还提供了一个用这些组件构建的页面示例（参见http://www.sun.com/software/products/mysql/index.jsp）。

此外 Nathan Curtis 也在 SlideShare.net 上发布了他的“Creating a ComponentLibrary”演讲稿。网址是http://www.slideshare.net/nathanacurtis/creating-acomponent-library-298610。

2.3　交互设计框架体系

在互联网上可能存在着数百万个设计模式，它们每天都在被人使用，其中一些很流行。就此而言，它们似乎就是所谓的界面模块的理想“后备”，但其实模式仍然存在着一些无法摆脱的局限。

设计模式能够解决那些范围较小的具体问题（这也正是我们期待的结果），但是我们无法从中得知这些问题之间是否有联系、是否会顾此失彼。尽管在一般的模式描述文档中有一个上下文情境项，但它也只是讨论了模式能在何处适用，其中既没有提到该模式会如何影响整个应用程序，也没有提到它和系统其余部分的联系。而在必备条件项中，也只是列出了与该模式密切相关的其他模式，并没有揭示其表面下的深层原因。

我们希望创造出成功的设计，然而设计模式缺乏足够的上下文信息，为我们留下了许多悬而未决的问题。每个页面应该显示多少条搜索结果？应该如何处理错误（例如用户输入错误或者零结果搜索）？用户怎样才能开始新搜索？每条结果应该提供多少信息？哪些信息更为重要？单凭模式是无法回答这些问题的。

比如，分页界面能让用户从一个页面前往另一个页面，然后还能再回来。这的确解决了一个问题，为一个操作提供了支持。然而要想追求可用的设计，还有很多其他问题需要考虑。

要想回答这些问题，我们不能只着眼于分页界面，而必须考虑整个搜索系统。换言之，我们不能只依赖于设计模式，而必须了解模式是如何构成系统，而系统又是如何构成整个应用的。

那么组件呢？从本质上来说，它们也只是某个公司（或组织）定义的模式的代码完成版本而已，因此也同样爱莫能助。

要想回答这些问题，我们需要审视可重用铁三角中凌驾于设计模式之上的更高层次：交互设计的框架体系。

2.3.1　交互设计框架体系包含的元素

框架体系的结构与设计模式类似。实际上，我们把框架体系视为设计模式在逻辑上的进化结果，它是我们构建一系列成熟解决方案的下一个必经步骤。本书所呈现的框架体系就是我们推荐大家使用的框架体系，包括名称、描述、在何处使用它们以及如何使用，等等。简而言之，每一个框架体系都会包含本节所述的部分或者全部内容，如图2-7 所示。

除此之外，我们还将讨论这些框架体系所能满足的用户需求，以及相关的人类行为，同时还会探索解决这些设计问题的各种途径。此举是为了让你能深刻地理解在你自己的项目中应用框架体系时应当考虑什么，以及如何充分利用从中归纳出的设计标准。

当然，你也没有必要为自己的每一个框架体系都总结出一篇见解深刻的论文。实际上，框架体系文档的复杂程度和模式文档相当即可。

只要遵循以下各项就可以了。

1．描述

描述项不仅描述了框架本身（这是其首要目的），同时也描述了框架应满足的需求。例如在下一章将介绍的目录框架，它描述了人们在选择目标时必经的三个步骤，而这一事实也正是目录框架存在的原因，因为它对该行为提供了直接的支持。

在本书每个框架的描述项中，我们都尽力囊括这类信息。但在你构建自己的框架资源库时，仅仅照本宣科是不够的，必须加以变化。关键是要了解你希望框架做什么。目录框架支持的是人们选择对象的过程，搜索框架支持的是导航未能提供帮助时寻找内容的过程，注册框架则鼓励用户从访问者转变为客户。

2．上下文情境

该项描述了在使用给定框架时用户可能遇到的问题，或者他们希望满足的需求。例如，当某个用户面对一个必须登录才能使用的Web 应用（就好像一个四周都是围墙的花园）时，可能会考虑是否值得去注册。而注册框架将会处理此时用户心中产生的各种疑问。它会介绍该应用的功能和优点，注册时须付出的努力或成本，以及如何开始注册，等等。

除此之外，该项还会描述框架在网站信息架构中所处的位置。例如注册框架经常会在顶级的市场营销页面中出现。

3．任务流程

许多框架通常都由一系列按顺序排列的交互构成。其中一些还会提供必要的信息，用户只要参考这些信息就能自己解决产生的疑问。在这种情况下，用户必须遵守特定的任务流程。任务流程部分所描述的正是这些内容。

当然也有例外，例如那些针对特定主题的网站（比如电影网站，参见第7章），或者其他根据惯例相结合，提供完备解决方案的模式集合。一个典型的电影网站包括一个预告片视频、演职员信息、剧情梗概以及其他内容。这种网站本身通常不会包含任务（至少用户访问这类网站不是为了完成工作任务），因此任务流程部分对于电影网站的框架来说并不重要，因此也不会被包括进来。但是框架是仍然存在的，因为这些元素相互协作，共同实现了电影网站的目标，也就是劝说访问者来看这部电影，所以它们构成了框架。

4．其他必备框架

其他必备框架一项列出了与当前描述的框架配合使用时不可或缺的其他框架。例如，一个电子商务框架可能由网站中特定于产品销售与服务的元素构成（出于本书的目的，我们将它与目录框架进行了整合）。然而，为了更好地支持该过程中的任务，电子商务框架还需要其他框架的配合：搜索框架，提供寻找商品的第二渠道；购物车框架，用于处理购买信息；付款框架，用于付款结算。

这些都是电子商务框架的其他必备框架。

5．相关框架

相关框架指的是那些与当前描述的框架有着相似的目的或者支持相似的用户或业务目标的框架。除了搜索框架和购物车框架之外，一个电子商务网站通常还会包括一个订单管理系统和顾客账户系统。这些系统可以作为框架进行存档和备案，然后在相关框架项中进行相互链接。

6．构成元素

构成元素项是一个框架中最重要的两个部分之一（另一个是设计标准项，参见下文），因为它列出了所有从属于该框架的设计模式。在后面五章中你将会发现，构成元素是框架体系的主要组成部分，该项中列出的所有模式都会指向各自的详细文档。正是通过这种方式，框架资源库包裹在模式资源库之外，与模式资源库紧密地结合在一起（我们将在2.3.3 节中进行深入讨论）。虽然我们说是框架体系（而不是模式）构筑了整个上下文情境，为最终的解决方案指明
了方向，但它们依然主要由模式构成。

没有模式的框架是不存在的。二者相辅相成、紧密协作。

7．设计标准

框架体系文档中的另一个重要元素是设计标准项，它列出了框架中一系列设计的导向性方针。这听上去也许简单，但它可能是整个框架中最难以准确界定的部分。

设计标准准确地标识出为了网站用户而必须实现的目标，形成一系列如规章制度般的指示，表达了设计背后的动机。

例如，注册框架（参见第5 章）包含以下设计标准：

• 表达了明确的价值声明
• 建立起用户的预期
• 证明本应用程序运转良好
• 鼓励行动并确保获得进展
• 让用户与其操作相联系

每一条标准都是针对设计的指令。

之所以要列出设计标准，有两个很重要的原因。

首先，框架体系能让我们逆向设计人类的行为，而这种理解正好能通过种种设计标准表达出来。定义设计标准能帮助我们更加深刻地理解框架的价值，也只有这样，你在自己的项目中应用框架时才能做到有的放矢。在设计中，哪怕是最细微、看上去最无关紧要的细节，也可能会导致产品在可用性、客户转化率、操作愉悦性甚至产品价值等方面产生重大的差异。标准能让我们知道在一个设计中哪些地方是最重要的，这能确保我们对设计进行正确的修改和调整。

其次，框架体系能将人类行为映射成一系列具体的目标，其中的每一个目标都有可能激发我们的灵感，创造出新颖的解决方案以达到同样的效果。而以此为基础的创新又能实现整个框架真正的目标，解决真正的问题。简而言之，框架体系的设计标准能告诉你需要实现哪些目标，至于实现的方式则完全可以自由选择。

本书共涉及了5 份框架文档，我们将以每份文档的设计标准项为例，演示上述内容的实现过程——如何运用与众不同、独一无二的方式来满足某个标准框架的既定目标。我们希望这不仅能帮助你理解如何构思和应用设计标准，还能启发你设计出充满新意的解决方案。

既然设计标准这么重要，那么另一个问题也随之出现：这些标准的产生和推断过程似乎非常复杂，令人费解。但我们并不这么认为。

在为设计制订标准的过程中，唯一的窍门就是自问这个框架能为你或者网站的其他用户带来什么。

比如，要想知道注册框架为我们带来了什么，先浏览一下该框架中包含的元素。其中一个元素就是价值声明（value proposition）——几乎每一个要求用户注册的网站上都会出现。如图2-8 所示，有关估价和结算的Web 应用Ballpark （www.getballpark.com）就在网站中使用了“让您能更方便地发送预算单和结算单”这样一条语句。那么这段陈述为我们带来了什么呢？很明显，它的目的是为了表现该Web 应用的价值，告诉用户这个应用有什么用，以及它为什么很重要。在这个例子中，框架中的某个元素和某条设计标准包含了同一个词。该元素被称为价值声明，而设计标准则能明确地表达价值声明。换句话说，有时候元素仅仅只是为了满足某条设计标准而存在的。

而另一个注册元素（将在第5 章进行讨论），就是注册表单本身。注册表单能让用户创建账户，这非常明显。但是，从这一事实中我们能推断出什么样的设计标准呢？要想解决这个问题，请先自问用户为什么必须注册。用户必须注册，只有这样才将让他们在网站上执行的操作和他们自身“绑”在一起，使他们在下次登录时能够找到之前的数据、进行个性化的定制，等等。那么该框架的又一条设计标准出现了，那就是“让用户和他们的操作相联系”。

而搜索框架（参见第4 章）则可能是一个较为复杂的例子，因为框架中的元素并没有明显地表现出它们各自的用途。如果要为一个有效的搜索系统设计设立标准，你首先必须了解人们搜索的原因。有时候，网站的导航无法呈现给用户想看的内容，而为了弥补这一点，搜索提供了找到内容的第二种途径。但是，如果用户自认能带来帮助的关键字并不在寻找的内容之中，那么这第二种途径很容易失败。因此，设计标准变成了：将内容和用户的用词进行关联。如果你没有理解人们为什么搜索、以及是什么让搜索能够成功，那么将很难得到上述的结论。但话又说回来，如果相关的问题已经过很好的研究，那么只要经过一些细致的调查，你自己也能得到答案。所以，首先自问有哪些因素有助于成功搜索，你就能找到线索，然后将其加入到设计标准中去。

的确，有些标准会比其他标准更难发现。但通过以上的解释，我们希望你能明白在这个过程中除了提出问题，然后将答案转化为相关标准之外，并没有其他复杂之处。

在接下来五章的设计标准部分都会阐明当存档自定义框架时如何做到这一点。

与此同时，让我们转而看看框架更为概念化的一面——让框架行之有效的哲学基础。

2.3.2　框架体系的特质

著名的信息架构师Liz Danzico （Happy Cog Studios ，Bobulate.com）曾经做过一次题为“The Framework Age”（框架时代）的演讲。演讲的主题是Web 设计师们已经抛弃了严格支持剧本化的用户行为的设计，转而开始为之设计一种弹性的平台。Liz 的演讲重点关注于一种不断变化的网页范型，这和本书并无联系；但在演讲的过程中，她提到了用户定义框架的3 个特质。

为了说明这些特质，Liz 谈到了古典音乐和莫达尔爵士乐之间的区别。

她解释到，在古典音乐中，每一个音符都是既定的。作曲家煞费苦心地为每一件乐器谱写乐曲的每一个小节中的每一个音符。要想成为大师级的乐手，技巧、风度和个人特色当然都很重要，但从根本上来说，任何乐手都得有能力和自制力来演奏出那些音符。每一次都必须完美、准确。在古典音乐中，只要有一个音符出现错误，那就是失败。

然而爵士乐则完全不同。而莫达尔爵士乐更是极端中的极端。

在录制那张首开先河的唱片Kind of Blue 之前，传奇小号手Miles Davis 走进录音棚，拿出了6 张纸。在这些纸上只提供了少量的信息——歌曲的调式、速度以及使音乐不偏离方向的一些限制。除此之外什么也没有。

Miles Davis 并没有要求这些音乐家按照乐谱逐个音符、循规蹈矩地演奏，而是让他们跟随着律动进行谱曲。在演奏中进行创作。

他希望他们尽情表演，即兴发挥，让他们自己沉浸到音乐中。

尽管录音棚里没有任何人用这种方式演奏过，但是他们作为音乐家的进化，事实上也是爵士音乐的进化，就摆在面前的这6 张纸上。

而通过Miles Davis 简单却具革命性的要求，莫达尔爵士乐，一种本质上诞生于框架的音乐被推向了世界。

每首乐曲的骨架（轮廓、结构）是确定的，但其他的一切都是开放的。音乐家可以完全自由地在框架中演奏，试验，大展拳脚。

通过这个例子，Liz 阐述了她为框架定义的三个特质。

1．存在

首先，框架是存在的。用Liz 的话说，它们“可检测，却又不固定”。这句话的意思是说它们存在，而且可以标识，但是它们的表现却绝不是一成不变的。

就像每一种音乐类型中都能找到框架的影子一样，几乎在每一个纵向市场中都能发现网站设计的足迹。这使得它们很容易被发现，存档和备案，但却仍然能根据不同的表现而保持其独立性。50 亿个搜索系统可能都提供了（本质上）完全相同的分页界面，但出于某些原因，任何一个搜索系统都会和其他搜索系统存在着或多或少的差别。可检测，却又不固定。

2．可累加

其次，框架是可累加的。设计师能以它们为基础，针对具体的解决方案以有效的方式对设计的规模进行缩放，同时将一系列框架串联起来，构成整个网站。

3．增强表现力

最后，框架是表现力的推动者。它们使设计师能够为作品赋予自己的风格。自定义设计，表演。

框架不会把用户限制在那些生搬硬套的规则中，它们允许即兴发挥。尽管框架所包含的元素始终不会有太大的变化，但就像设计模式一样，框架的每一次实现都必须适用于相应的特定环境。比如最常见的搜索结果页面，它已经成为每一个搜索系统中不可缺少的标准部分，但要想使用它，则必须考虑整个应用的上下文情境。设计师们的美学素养在这里派上了用场。正是在这里，设计师开始注入个人风格，调整细微之处，运用娴熟的技巧。正是在这里，设计师开始表演。

4．鼓励创新

因此，框架体系完全可以作为我们设计的起点，同时一定要认识到，以框架为标准并不代表着创新精神的消逝。除了提供一整套彼此关联的界面解决方案之外，框架还能让我们领悟如何提高水准，登上新的台阶。

看看当今主流的在线零售网站。你也许已经注意到，它们都在使用一种极为相似的信息架构。例如，当访问Target.com的主页时，你会四处寻找有关你想要的产品的链接（比如运动装备），寻找可能会包含该产品的商品种类，扫描搜索结果，找到一件希望深入了解的商品，然后点击进入详情页面仔细查看。

互联网上的任何一家零售网站都支持这一核心的任务流程。（当然，炉火纯青的Google 搜索让我们几乎能够完全摈弃在线购物的这一流程，但那是另一码事。）

为什么会这样？

因为在线的购物体验符合我们购物的一贯心理模式——实际上，它和我们在日常生活中的购物方式完全相同。这里面没有任何特别之处。Target.com、Barnesandnoble.com、Amazon.com 和其他许多在线零售商都支持常见的用户行为。

而这么做的理由是，一些人注意到了用户们惯常的行为，决定要对其进行在线的支持，于是便设计出一些东西把这些实际的行为照搬到网上。这些零售商们决定要全盘模拟现实世界中的购物行为，但其实并无这个必要。事实上，只要他们真正理解了现实世界中的人类行为，就可以创造出完全不同的解决方案，用更有趣的方式来解决问题。

而你的机会正在于此。

正是心理因素导致了现有的各种标准化的解决方案，但它同样也能衍生出其他更为引人注目的设计。在决策过程中保持以这种心理影响为中心，你就有能力构思出不可思议却又对用户同样有效的设计。

简而言之，框架从不限制创新，它们鼓励创新。

2.3.3　第一个框架体系资源库

在本书的创作期间，框架体系仍然处于初期发展阶段。事实上，你手中的这本书正是第一部从用户体验而非代码的角度来讨论框架的作品。因此，我们也没有听说过任何公开的框架体系资源库（之前曾筹备过的一些资源库都属私有）。

于是我们创建了一个，如图2-9 所示。地址是http://webanatomy.rhjr.net。

“Web 解剖学”框架体系资源库包含了本书中所有框架实例的文档记录。我们希望以你的反馈、想法和贡献为基础，让它持续成长、不断壮大。

正如你在该网站中所看到的，框架资源库基本上就是模式资源库的一个外包装。如果你已经为自己的公司（或组织）创建了模式资源库，那么一切将非常简单。即使你还没有创建，也完全可以让二者齐头并进：先利用wiki 或者其他方式来创建框架文档，然后将文档中构成元素项里列出的元素链接到对其进行描述的相应模式文档上。

在“Web 解剖学”资源库中，尽可能将框架所包含的元素链接到各个公共模式库。如果某个列出的元素无法对应任何公共资源库，我们才会尝试对其进行描述。希望其他的模式资源库在日后能够对这些元素进行归档，以方便我们进行链接。

作为第一个公共框架资源库，它对应了本书中的每一个实例。如果你把它和本书结合起来使用，不仅能了解如何为框架存档，还能了解如何与其他人共享框架。而就其本身而言，我们也相信使用者能够获得在本章和前一章中所提到的一切好处。

我们当然希望它不会是最后一个公共框架资源库。我们还希望其他个人、公司或组织也能够开放他们的资源库，供大家自由使用。

你自己的资源库

像你所看到的那样，我们的资源库由静态的网页构成，而不是通过可供大家任意编辑的wiki 页面来表示。事实上，Web 解剖学资源库构建在WordPress 之上，这是一种流行的内容管理系统（content-management system）和博客工具，而且它具有自定义的WordPress 主题。

你可以使用任何喜爱的工具来创建自己的资源库。不过重要的是，同公司内的所有人都应当有访问的权限，而且应使用一种能支持快速更新的方法来记录资源库（相信我们，此举的理由非常明显，你绝不会希望用纸来记录框架资源库）。

2.4　自然环境下的框架

Robert 曾在Jared 的UIE Web App Summit 上举办过一次有关框架体系的讲座，有人提出了一个有趣的问题：框架体系是否会让交互设计产生同一化，最后让交互设计师们丢掉饭碗？

答案当然是不会。

恰恰相反，建立框架体系的目标之一就是为了让设计师们能避免把时间都花在单调、重复的界面和架构设计上，从而能有更充裕的时间来做设计师们应该做的事情：致力于为企业和客户提升用户体验。

讲座的另一位听众问到，这些框架累加到最后，是否会出现整个界面变成臃肿的科学怪人①那样的局面，并询问如何避免。我们的回答是：

和人体系统一样，框架体系相互间的结合可以说是完好无缺。它们彼此之间有很多重合的部分，而且联系非常紧密，因此相互之间的界限几乎根本看不到，能够实现完全无缝的交互。在很多情况下，一个模式很快就能变身为多个框架的构成部分，而且为用户扮演多种角色。其中一个例子就是名为Register Now（马上注册）的按钮，它可以用于鼓动用户为某次会议登记，也可以作为后台账户管理系统的入口，方便会议组织者在会议之前与登记者取得联系。

一个单独的框架体系本身并没有太多价值。即使是Google 的搜索框架也不例外，它是该公司核心任务流程的主导框架，但仍然需要与其他元素协同合作，例如为访问其网站的用户提供导向，鼓励他们使用更多的Google 服务，以及登录并获得之前储存的信息。只有把各个框架体系编织在一起，才能构成一个完整的网站或应用——形成一次完整的体验。

框架面对面

接下来的四章将为大家极为详细地介绍了几个重要的框架：目录、搜索、注册以及关于我们。在这几章中，我们将讨论是哪些人类行为导致这些框架成为了标准，以及与之相关的调查和可用性研究的结果，还有当你在自己的项目中使用它们时需要考虑的问题。

在第7 章，我们将展示的框架体系面向的是一个专门的市场——电影工业。这么做并不是因为我们相信所有的读者都和电影工业有关（当然或许你正是其中之一），而是希望借此阐明对于这种不太常见的框架，我们应该如何标识出它所包含的元素。

事实上，几乎每一种领域都有它自身的一套标准化方案，例如高等教育网站都会有申请表，摄影图库网站都会有为摄影师提供的管理工具，金融网站都会有投资组合管理系统，等等。而我们将利用这一章来说明应该如何了解这些特定行业的具体情况，以及如何让它们与其他框架共同构建出一个完整的网站。

再次强调，当你完成了这些的时候，请访问http://webanatomy.rhjr.net，这里有一个活生生的框架资源库，它能帮你记录你自己的框架，并筹备你自己的资源库。

让我们去近距离地看看框架吧！