组件和模式
Nathan Curtis 版权所有
2009年1月9日

译者：UCD翻译小组，Stan
校审：远骋，Angela
原文地址：http://www.uie.com/articles/components_vs_patterns

编者按:今年四月,在UIE应用高峰会议上，应我们的要求，Nathan Curtis会做一次关于实现组件和模式重用的演讲。其间，Nathan讨论了组件和模式之间的不同。

常常在你计划构建一个组件库的时候，股东会这样问你“这样阿,我们正在构建模式库么?”实际上，并不是这样。尽管这两个概念非常相关，但它们之间的不同会影响你构建一个对你而言正确、适用的库的决策。

什么是模式？
模式是一种通用的解决方案，尤其对于常见的设计问题，如此一来，你可以多次使用这种解决方案，而每次的用法都不尽相同。
举个例子，对于一个设计者来说，没有什么理由不去使用这些通用设计方式：Tab(至少要有2个Tab)、视频播放器（可以播放或暂停）、登录（一个需要用户名和密码的最简表单）。模式是交互设计的精髓，提供给设计者基本的、约定俗成的应用方式，不管这些解决方案是否会被收集在一起，作为一个库提供给某个企业或网站。

什么是组件？
另一个方面，所谓组件则是在一个页面中针对某个特定系统而设计的、可复用的块。这样的组件──也被叫做模块、块、portlets，widgets、区块……或其他的名字，这依赖于设计的背景，它们被集合到一起，便组成了一个完整的页面或视觉效果。在一个页面布局里面，每一个组件都有其特定的应用、预定义的行为方式、格式、编辑方式、视觉效果，以及各种各样的处理方式等等。

组件和模式二者之间是如何联系的？
模式和组件，在设计中互补且共存，尽管它们常常并不是同样的东西。

看一下这2个首页的不同体验，分别是fancast.com和comcast.net， 两者都是Comcast Interactive Media的网站，相关关联。这两个首页都可以分解为多个组件（桔色标明），其中很多都可以在其他页面上重用。这2个首页，每一个都使用了很多模式（红色标明）。

图A:组件（桔色）和模式（红色）在comcast.net（左）和fancast.com（右）首页面上的效果

这些组件和模式是一样的么？不完全是。这2个设计方案中，没有任何相同的组件，包括整个视觉栅格，排版、布局、颜色、导航模式都不一样。然而，这2中设计使用了至少5种相同的模式，包括搜索、登录、跑马灯、头条、和Tab。

一个模式的多种组件设计
通常，一个组件库中的多个组件使用相同的模式。举个例子，Tab模式，设计者可以用它把内容分割成不同的部分，所有Tab都可访问，但每次只有一个Tab呈现可见。在cnn.com网站上，Tab被实例化成很多个组件，通过全球区域分组财经市场（Asia, Europe, US）建议不翻译Asia, Europe, US，这样用户可以更直观的和图片联系着看   、通过形式分组文章（文字、视频、地图、图表）、通过类型分组视频（热点、排行、小编推荐等）。

图B:Tab在cnn.com上被用作唯一分类、内容类型、精化组织。

在每一个例子中，设计都遵循Tab模式的基本理念，比如要区分当前激活的Tab和其他Tab。然而，具体到每个用法、页面分区、风格，以及设计细节，在每一个组件中都迥然不同。

海纳百川：多个组件、一个模式
同样，很多组件的各种千奇百怪的设计都能够归结成一个模式，并形成一个基本准则，适于团队并共飨之。

举个例子，试想一个网站中的很多的视频播放器，各种衍生的无用的设计形式到处泛滥，嵌入到一个产品的焦点区域嵌入到产品介绍的页面   ，在不同的焦点区域使用不同的播放器，在弹出框中使用特殊的播放器，在培训组的内容帮助文档   中使用另外新的播放器，等等。所有设计的播放器UI组件，在不同的团队中多次开发，便有了很多不一样的呈现状态和用户交互方式。

各个团队，可以通过模式来解决分歧，基本的表现要有播放/暂停、scrubber、时间轴（播放时间和总时间）、音量。通过使用模式，一致性得到提高，但团队依然可以灵活的取舍各种附加控件和功能，比如，视频大小、全屏观看、百分比、添加评论、视频代码等，一个特殊的组件就可以用在他们自己的设计方案中了。

相同点
对特定的问题，模式和组件都是可重用的设计方案。重用是两者的关键售卖点，其结果都是为了取得一致性和降低成本。
另外，模式和组件能够还能做以下的事情：

• 通过使用诸如时间、基本原理、和方案原则来描述
• 通过形成一个库来管理
• 因为可重用，那么无论在html/css feameworks代码中还是在设计库线框图中都可以使用。
• 在很多方案中使用，比如信息架构，交互设计，视觉设计，设计技术（html/css/js脚本）等其他准则。
• 通过一个定义的工作流成进行开发和维护
• 以一个组织的设计需求为基础
• 以用户研究来影响和把握

不同点
尽管两者相似，但在很多重要的方面，组件和模式还是不同的。一方面，模式是一些准则，设计者可以拿来去阐述和运用；另一方面，组件是特殊的实现，有着很多的规定和硬性要求。

其他不同点包括：

你应该构建的那一种库？
既然两种库是不同的，那你该采用哪一个呢？

模式库是理想的方式，对于有过很多设计经验的团队来说，比如一个像Yahoo那样的团队，设计过很多的产品，每一个产品都有其独有的视觉系统，但这些都依附在一个大的通用的品牌上。对于其他团队来说，组件库被证明是完美的方式，诸如sun的 sun.com 网站库，合成了大量的页面，片段，团队，内容，都归并到一个通用的、简单的设计系统和体验上。

但这或许不是一个问题，因为要依赖于你的环境，你可能会从一个或两个库中受益。实际上，一个团队会构建2个库，并且像构建组件库那样构建模式库。其他团队会采用拿来主义，同时领会要义，通常的做法是把一些类似模式的指导原则结合运用到更多的模块定义中去。

如果你的团队具备以下条件，你可以考虑构建模式库：

• 有很多的视觉系统，各不相同，并且不会整合统一
• 有能力把模式文档化，相比起来要比公开一个已有的库要更有意义
• 明白阻力重重，触及到既有的习惯，但依然乐于使用统一标准

考虑建立组件库，需要具备以下几点

• 一个特定的视觉系统，包括栅格，布局，色调，排版等
• 在系统中很多可重用的组件（比如页面的块）
• 多个团队必须要一起工作,共同推动和发布
• 有兴趣并且有能力把你的设计和代码系统贯穿在团队、项目、和时间管理中
• 能够强势，可以以己为中心的影响构建、部署和维护一个库（或通过构建一个库来提升影响力）

更多
2009年4月21日，Nathan Curtis 将会在加利福尼亚Newport Beach的UIE Web应用高峰会议上做演讲，题目是“实现模式和组件的重用”。这是一个非常理想的讨论会，与会者可以充分展示其设计才能，并徜徉其中，感受各种各样的作品

分享

我一直是这样的，很想听到你对这个主题的想法。加入到我们的本周讨论中来吧，在这里“UIE Brain Sparks blog”。

打印  |  相关话题：UCD翻译小组   |  类别：信息和交互  |  源地址