APP设计模式六要素

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

要想更好地理解模式，我们不妨看看在一份标准的设计模式描述文档中都包含些什么。我们列出了以下六要素。

1．模式名称

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

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

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

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

2．描述

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

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

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

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

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

3．上下文情境

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

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

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

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

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

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

4．曾于何处使用

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

5．工作方式

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

用户在标记有 User Name 的输入框中键入他们的用户 ID，在标记有

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

（参见“登录错误”模式）。

需要的细节数量取决于控件的复杂级别，以及团队成员对它的熟悉程度

（如果是他们自己经常使用的元素，就不需要像不常见元素那样进行详尽的描述）。曾有一个可用性团队向我们展示了利用视频捕捉来创建演示短片，他们通过这种方式来描述元素的运作机能。

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

6．其他必备模式

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

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

创建新用户 ID 的模式；

修改密码的模式；

重新获得密码的模式；

从网站的受密码保护区域退出的模式；

当输入的用户名或密码不正确时，显示错误信息的模式。

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

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