作者：Brad Frost 翻译：主物质界面 reg 校对：主物质界面
其它章节
在前面的章节中，我介绍了用原子设计语言来构建用户界面的方法论。希望你能认同原子设计对于如何构建UI设计系统的理念，不过现在是时候走下象牙塔，在现实世界中将原子设计理念落地了。
模式化的设计与开发，基石是pattern library，它在构成用户界面的所有组件中扮演着核心枢纽的角色。正如我们在第一章所讨论的，pattern libraries的好处有很多：
-
它们 提升了整体体验的一致性和凝聚力。
-
它们 加快了团队的工作流程 ，节省了时间和金钱。
-
它们在项目涉及的规范中 搭建起一个更具协作性的工作流程。
-
它们为企业当中的所有人，包括外部供应商 搭建起一个共享库。
-
它们提供 有助于教育利益相关者，同事甚至第三发人员如何使用的文档。
-
它们使 跨浏览器/设备，性能和可访问性测试变得更加简单。
-
它们为开发团队提供了一个未来技术兼容性良好的基础，以便于后期的修改，拓展和改进。
听起来很棒对吧？我都能听到你们说，「嘿，我需要这个叫做pattern library的玩意」。但是，我们如何实现pattern libraries呢？总算问到点子上了，因为这本书的剩余部分就是为了阐明具体怎么去做。本章会介绍创建pattern libraries用到的工具，下个章节我们会讨论如何使pattern成为你设计和开发工作流中的基石，而第5章，将会阐述怎样使你的设计系统经得起时间的考验。
本章将透过一款叫做 Pattern Lab 的工具来观察高效的pattern libraries应具备的特质，这款工具是由web开发者Dave Olsen，Brian Muenzenmeyer 共同维护的开源项目，我在其中担任原子设计系统的执行。尽管我非常迫切想和大家探讨Pattern Lab和它丰富的特色功能，我还是要强调本章的重点在于阐述构建良好的pattern libraries应具备的特点，而非出售任何工具。再说了，Pattern Lab就是个免费的开源项目啊😳……没有任何一款工具可以完美契合任何部署环境和使用场景，但在决定使用某款工具来创建pattern libraries的时候，请务必牢记以下原则。
# Pattern Lab到底是什么鬼？
在深入了解Pattern Lab的工作原理前，我们有必要花时间解释一下这个工具是什么和不是什么。
Pattern Lab是...
-
静态网站生成器，可用来建立原子设计系统。
-
pattern文档和注释工具。
-
pattern入门套件。
Pattern Lab不是...
-
类似Bootstrap或Foundation那样的UI框架。
-
基于语言，基于库或者基于样式。
-
一个内容管理系统的替代方案。
让我们一个个来看，从静态网页生成器开始。常用的静态网页生成工具获取源码和切片，编译它们，再从另一个端输出纯粹的 HTML，CSS 和 JavaScript。 而Pattern Lab呢？它获取源码（也就是pattern）然后在pattern library shell里，把这些pattern编译成可用的前端UI。
那么Pattern Lab到底看起来是什么样子呢？此处应有掌声！
默认的Pattern Lab dashboard。为了功能性的补偿，牺牲了华丽外观。
呃，看起来不是个振奋人心的设计，对吧？信不信由你，这种极简的 (好吧，你也可以解读为极其简陋的) 设计是经过深思熟虑的结果。为避免出现像Bootstrap这种UI框架里的分类错误，权衡再三，我们简化了设计，所以不会有人真的把 Pattern Lab 的 demo UI 当成推荐样式。Pattern Lab 不会回答像「如何设计」，或者「如何构建前端代码」这类问题–你得自己动手来做这些。UI的外观，命名规则，语法，结构，库和脚本将完全取决于你和你的团队。甚至，你可以 在Pattern Lab中使用像 Bootstrap 这样的UI框架。它的存在是为了帮你将所有资源整合到一起。
从技术层面来说，Pattern Lab使用PHP或Node.js作为引擎，把pattern整合并生成pattern library。不过，你并不需要成为一个 PHP 大佬或者 Node 大神就可以自如使用 Pattern Lab，就好比不了解如何制造内燃机不会影响你成为一名老司机。再者，你最终上线的网站也不必使用 PHP 或 Node，Pattern Lab 的输出物是独立于后端的 HTML，CSS 和 JavaScript。和其他技术选型一样，挑选构建Pattern library的工具，也需要适合你公司的设备与环境，同你所在团队工作方式保持步调一致。
我是不是扯得有点远？别担心。本章重中之重在介绍 Pattern Lab 的特性功能，以及构建一个高效 pattern library 的原则，不会带大家过度深入到技术坑里去。如果你们对技术问题感兴趣，可用直接到 Pattern Lab’s documentation 查看文档。
#通过Pattern Lab来构建原子设计系统
要理解Pattern Lab的核心理念，最好的办法就是看看俄罗斯套娃。
俄罗斯套娃。图片来源：Tromal on Flickr
玛特罗什卡娃娃—也就是我们常说的俄罗斯套娃，它们由雕刻精美的空心木娃娃，自小而大层层嵌套而成。Pattern Lab 中的 pattern 也是这样的原理构成的：最小的 pattern 称为「原子」，它被更大一些的「分子」 pattern 所包含；「分子」呢，又涵盖在更大的「有机物」pattern 中，而后者又存在于「模板」pattern 里。
以这种方式组织的UI系统遵循 DRY 原则—这也是长期存在于计算机科学领域的原则—「don’t repeat yourself」不要重复自己。具体到 Pattern Lab 里，就是你对一个 pattern 做出变更，会同时反映到所有用到这个 pattern 的地方。这种嵌套方式可以显著提升你的工作效率，免去了做一个微小的变更就得在一堆 PS 文件里苦苦寻找的麻烦。
为了实现这一点，Pattern Lab 用到了 Mustache 的 include 功能，这是一种logicless的模板语言。下边就是 Mustache include 的示例：
{{> atom-thumbnail }}名字源于 ( {{}} ) 这种大括号的嵌套看起来像是卷卷的小胡子。里边的大于号 (>) 是 Mustache 告知 Pattern Lab 涵盖叫做「thumbnail」的原子pattern的方式。Pattern Lab将通过_patterns的文件夹搜索找到一个名为“thumbnail”的Atom。
这就是Pattern Lab的文件夹结构。你可以随意命名和分类这些文件夹，包括改变「atoms」,「molecules」,「organisms」,「templates」和「pages」这些标签。首要考虑因素是根据你的团队来设定命名和分类规则。
现在我们理解了 include 的包含关系，让我们来实际操作一下，看几个我参与创建的网站 pattern，源自 Time Inc。以下就是一个可复用的 pattern：
Time Inc的网站。我们创建了一个基本的分子模块，包含缩略图，标题和摘要。
这个 pattern 大家应该非常熟悉。在无数的网站上你都可以找到像这样由缩略图，标题和摘要组成的 pattern。让我们来揭开她的面纱，看看这类 pattern 到底是如何构建的。
<div class="block-post">
<a href="{{ url }}">
{{> atoms-thumb }}
<h3>{{ headline }}</h3>
<p>{{ excerpt }}</p>
</a></div>
可以看到：HTML 标记由一个名叫 block-post 的类目；一个链接；一个包含缩略图的 Mustache；一个 <h3> 的标题和一个代表摘要的 <p> 标签封装在一整个 div 里构成。你可能还留意到更多的 Mustache 代码像 url, headline 以及 excerpt，这些我们后边在稍后做实际内容的动态切换中会用到。会比这个更详细一些。
现在我们的 pattern 都已标记完毕，我们可以使用相同的方法将这个代码块嵌套到更大的 pattern 中去。
{{> molecules-block-post }}让我们再进一步，来看看复杂得多的「有机体」pattern，比如网站的header，如下图
网站header一般包含这些元素：logo 原子，主导航栏分子和一个搜索栏分子。
当我们在 Pattern Lab 里打开header时，我们看到下图：
<header role="banner">
{{> atoms-logo }}
{{> molecules-primary-nav }}
{{> molecules-search }}</header>发生了什么？我们看到基本的 < header> 元素，里边含有 logo 图片原子，主导航栏分子以及搜索栏分子。
现在我们就可以随时在需要的地方引用相关 pattern 了。
{{> organisms-header }}我希望你领会到了俄罗斯套娃的精髓所在。最小的单位原子包含在分子中，分子包含在有机物里。现在我们来把这些组件放到布局中去。以主页模板为例：
Time Inc. 的主页模板包含少量可重复 patterns：一个全局标头，一个主题图片，少量区块 (包含图片，标题，摘要和 call to action 按钮)，一块含有4个栏目的区域，一个仿真地图以及一个全局页脚。
快速浏览一下主页模板，你会看到一些非常典型的 patterns：顶部标头，底部页脚，一个全屏宽度的主题图。在模板中还可以看到少量其他重复 patterns。
那这些在代码中是什么样呢？跟你想的差不多，它引入了更多包含逻辑：
{{> organisms-header }}<main role="main">
{{# hero }}
{{> molecules-hero }}
{{/ hero }} <section>
{{# experience-block }}
{{> molecules-block-main }}
{{/ experience-block }}
{{# experience-feature }}
{{> organisms-story-feature }}
{{/ experience-feature }} </section>
<section>
{{# factoid-advertising }}
{{> organisms-factoid }}
{{/ factoid-advertising }} </section>
<section>
{{# advertising }}
{{> molecules-block-main }}
{{/ advertising }} </section>
…
</main>{{> organisms-footer }}到这个阶段，很多小一些的 pattern 早已建好，所以模板所要做的，就是把它们拉取到网页布局中去，并给出命名。
仔细看一眼代码，你会发现特定 pattern 像 {{> organisms-header }} 和 {{> organisms-footer }} 组织方式和前边的示例是一样的。但也有少量 patterns 包含一些附加信息作为补充，比如：
{{# factoid-advertising }}
{{> organisms-factoid }}
{{/ factoid-advertising }}同其他 patterns 一样我们引入了 organisms-factoid ，但我们把它命名为 factoid-advertising，并将其封装在 Mustache section 中，用包含 # 和 / 符号的 Mustache 代码标注出来。通过独立命名，我们能够快速锁定它并动态替换其中的内容。下边会有更多介绍。
俄罗斯套娃的嵌套方案用来解决构建 UI 系统的问题既简洁明了又能力强大。这种结构帮助设计师和开发者保持页面的 DRY 原则，节约了时间、精力和金钱。团队可在构建最终 UI 布局同时设计底层的具体 UI 元素。毕竟，最终的交互界面是由底层设计系统呈现的。你还可以在概念设计和具体实现之间无缝切换，在特定的 pattern 中调校 bug (比如取个名字「标头错误！」)，同时可以看到小的 pattern 变更是怎样影响到整个页面布局的。
# 使用动态数据
我们不能脱离开 pattern library 来讨论底层 UI pattern 中的内容结构。这就是为何我们看到的都是灰度显示的图片和有字数限制的文本占位符。不过这个信息对创意团队会有帮助，灰度图片和哑元文本 (常用于排版设计领域的拉丁文文本) 并非用户在网站上实际看到的。我们需要一个能用有代表性的真实内容来替换这些呆板的线框和占位符。以确保我们的 UI pattern 能贴合它要展示的内容。
为展示 Pattern Lab 是怎样把真实内容动态替换到模板中去的，我们来看一眼 Time Inc 的主页模板和线上页面的并列比较：
Time Inc 主页的模板于线上版本的并列比较。模板清晰表明这套设计系统的内容结构，而线上页面展示了实际内容放到这套设计系统里是什么样。
左侧是模板，构成网页的 pattern 内容结构明了。而右侧是页面，我们填充了真实内容来演示最终的 UI 系统并测试这套设计系统的有效性。
在 Pattern Lab 里如何操作这种替换呢？Pattern Lab 使用了 JSON (以及 YAML, Markdown, 和其他数据格式) 来定义和替换出设计好的动态内容。
默认的占位符数据被定义为叫 data.json 的文件并保存在 Pattern Lab 的 /source 文件夹里。在这个文件里我们又定义了所有的文本，图片路径和其他用来构成 UI 的动态数据。下边是一个来自 Time Inc 的 data.json 文件的样本：
"hero" : {
"headline": "Lorem Ipsum",
"img": {
"src": "/images/sample/fpo_hero.png",
"alt": "Hero Image"
}}对于开发者来讲，这种格式可能看起来很眼熟。当然如果你不懂开发也没关系。看到大括号和引号旁边，我们定义了叫 hero 的对象 (为了标头正下方的全屏宽度的 hero 区域)，它包含赋值为 “Lorem Ipsum“ 的 headline ，以及 img，包含了赋值为 “/images/sample/fpo_hero.png” 的 src。我们只是简单定义了这个对象的属性并为之赋值。
一旦定义完成，我们就可以在 Pattern Lab 的页面层级中改写它们的属性。这可以通过在 /pages 文件夹内新建一个和页面 pattern 同名的 JSON 文件来达成。以 Time Inc 的主页为例，我们命名它为 00-homepage.json。
在 pages文件夹里边，有主页 pattern 和 与之同名的 JSON 文件。在这里，我们可以将页面默认内容改写为我们需要的内容。
打开 00-homepage.json 我们就可以替换掉之前创建的占位符。下图就是打开后的样子：
"hero" : {
"headline": "Moving People",
"img": {
"src": "/images/hero_beyonce.jpg",
"alt": "Beyonce"
}}通过重写默认数据，hero 标题现在将 “Lorem Ipsum” 替换为 “Moving People”。并且原先路径指向的灰度图片 for-placement-only (FPO)，也变成了指向 /images/hero_beyonce.jpg 的碧昂丝的图片。
网站的其他部分也是这样一个流程。除了替换像 heading 这样简单的字符串，我们还可以动态设置变量为 true 或 false，在一个数组中循环，以及更多。甚至，你可以通过少量更改 JSON 文件，来让 UI 产生戏剧性的变化。我们下边就会为大家讲到。
# 用 pseudo-patterns （伪模式） 来表达 patterns 的变量
历史上，设计师曾经在使用静态工具时，倾向于只针对最佳场景做设计。你知道我指的什么：用户的名字永远都叫 Sara Smith 并且工整的放在一行；个人资料图片呢，看起来好像是杂志上剪下来的；而且她居然完整填满了表格；个人资料中的两列内容居然是等高的。
当然，这样的最佳场景在现实世界中难得一见。
为创建强有力和灵活性兼备的设计，我们得同时考虑到最好的，最坏的以及二者之间所有情况。
如果用户不上传个人资料图片怎么办？如果用户的购物车里有87件商品，而这些商品每件都提供14种选择呢？如果博文标题包含400个字符如何处理？怎样对待新老用户？如果文章没有任何评论呢？又或者有七层嵌套的评论？碰到需要在 dashboard 上显示一条紧急消息的情况怎么处理？
用静态工具表达清楚这些 UI 变化是一项枯燥而多余的工作，所以它们极少被涉及到。但假如我们想要设计系统能涵盖所有内容的变量和实际情况，就得逐一回答像上边这样的各种「如果」。
那么问题来了，我们怎样处理好各种 UI 变量，同时保证自己不会累趴下？ Pattern Lab 提供的 pseudo-pattern 功能，可以帮我们展现不同场景下的变化，并且只需要对数据稍作修改。
这么说，我们正在开发一款 app，它的 dashboard 显示一列项目合作伙伴。UI 可能看起来像这样：
我们假设的 app 中项目合作伙伴列表页。
在每个区块中建立动态内容，我们得在 dashboard.json 中定义合作伙伴列表为一个数组：
"collaborators" : [
{
"img": "/images/sample/avatar1.jpg",
"name" : "Steve Boomshakalaka",
"title" : "CIA"
},
{
"img": "/images/sample/avatar2.jpg",
"name" : "Gingersnap Jujubees-Daniels",
"title" : "President of the Longest Company Name in the World Corporation, Global Division"
},
{
"img": "/images/sample/avatar3.jpg",
"name" : "Sarunus Marciulionis",
"title" : "Golden State Warriors"
},
{
"img": "/images/sample/avatar4.jpg",
"name" : "Sara Smith",
"title" : "Short Title"
}]默认情况下，我们预设用户为普通用户，不是管理员，但如果在 dashboard 中需要赋予管理员对项目合作伙伴的管理权限呢？那 UI 可能看起来是这样：
管理员的 dashboard 界面包含额外的编辑和删除按钮。
在 Pattern Lab 中，为了展示额外的编辑和删除操作，我们就可以在 page 文件夹里新建一个 pseudo-pattern，大概这样：
dashboard~admin.json波浪线符号 (~) 表明这是一个 pseudo-pattern。 dashboard~admin.json 会继承 dashboard.json 中的所有数据，但同时我们也可以做数据附加或者变更。也就是说我们之前在 dashboard.json 定义的合作伙伴列表仍然有效，但我们能添加额外数据到 dashboard~admin.json ：
"isAdmin" : true我们正在定义一个叫做 isAdmin 的变量，并设定为 true。现在在这个 pattern 里，就可以用它来有条件地包含附加操作了。
<div class="block">
<img src="{{ img }}" alt="{{ name }}" />
<h3>{{ name }}</h3>
<h4>{{ title }}</h4>
{{# isAdmin }}
{{> molecules-block-actions }}
{{/ isAdmin }}</div>前边几行拉取了我们在 dashboard.json 中定义好的 img ， name 和 title 。但是注意，是什么被封装在 isAdmin 的 Mustache 区块中？我们讨论的是：如果 isAdmin 被设定为 true，就包含了 block-actions 分子 pattern。而 block-actions 又包含了编辑和删除按钮，它们只会在 isAdmin 设定为 true (或者除了 false 之外所有情况)的时候才会显示。在默认的 dashboard.json 中，isAdmin 未设定值，所以额外的按钮不会显示。dashboard~admin.json 中，我们设定 isAdmin 为 true ，按钮就出现了。你可以发挥想象拓展一下这个技巧，使整体 UI 产生戏剧性的变化。「比如变更主导航，在 dashboard 中显示额外的面板，添加额外的控制按钮，等等」。只需要更改一个变量，多么强大。
嘿。如果你坚持看到了这里，恭喜！你现在知道怎样在 Pattern Lab 添加和处理动态数据了。可以说它是为动态数据而生，下边是一些显而易见的优点：
-
将结构和内容彻底分离。我们都知道 pattern 的结构和内容其实相互影响很大。尽管如此，弹性设计系统力求建立可应对未知场景，灵活的结构，以便容纳各种内容。解耦 pattern 的结构和数据使得我们保持 DRY 原则 (这里也是 don‘t repeat yourself 的缩写)，对内容做出变更不会影响到 pattern 结构。同样的，我们也可以变更 pattern 本身，而不必逐个更新用到这个 pattern 的地方，因为每个实例包含不同的数据。这种分离节省了大量的时间和精力。
-
构建了一个点对点的CMS (内容管理系统)。分别创建默认的和特殊页面的数据就形成了一个点对点内容管理系统。像之前提到的，静态设计工具不足以应对动态的数据，不过为了展示界面变量而安装 WordPress, Drupal, 或者其他 CMS 又显得牛刀杀鸡。Pattern Lab 在这二者之间取得平衡，它允许团队工作中引入动态数据，又不必部署一个夸张的 MySQL 数据库。
-
为后端开发人员提供蓝图。使后端服务能够与前端界面融为一体，从而构成一个完整的内容管理体系。后端开发人员可以非常直观的看到在 Pattern Lab 中创建的界面，了解哪块是静态的，哪块是动态的，提高了效率。
-
吸引作者，内容创造者，设计师和其他非开发人员加入到构建整个系统中来。 作为一名前端，我已记不清多少次被淹没在「修改字体」，「替换图片」，「翻译文案汇总」以及其他内容编辑相关的任务中。成千上万的内容变更让开发人员痛不欲生，而且会极大的影响他们的开发效率。我们提供的 Pattern Lab 功能，通过程序结构与内容数据的分离，使得团队中的非开发人员可以方便的管理内容相关部分，也释放了程序猿以便专注于系统开发。
好消息是，我们现在已经实现了 Pattern Lab 的核心功能！接下来我们会开发一些附加的特性，当然这些和用来创建 pattern library 的工具并无关联。
#灵活的 pattern 视区工具
现在访问网络设备的多样性，迫使设计师们重新接受并拥抱媒体固有的流动性。幸亏有 响应式设计 这样的技术，我们才得以创建在所有尺寸屏幕上都能完美呈现外观和功能的布局。
不用想也知道响应式布局肯定需要构建一套自适应的 UI pattern，只是创造不写死的 patterns 还有更多优势。UI 组件越不定死，它的适用性和可复用性就越强。想象一下如果能拿一个组件—就比如相册的滑块—放到任何需要的地方。有时我们会要它成为能占满整个视区的无边距 2 元素。或者我们想要将其嵌入一篇文章的内容中。又或者嵌入侧边栏？我们梦想追求的就是创造出足够灵活的组件，可以把它们的样式和功能带入到任何所在容器当中。
确实，这就是 容器查询 的承诺。容器查询会让各种元素基于父容器适配，而非整个视区，也是我们现在通过媒体查询来操控元素的方式。作为原生浏览器正在发展的能力，容器查询允许我们这样痴迷 pattern 的设计师和程序猿可以很容易创建并部署自适应的界面系统。
经过响应式设计，容器查询和传统常识，我们理解了为什么创建自适应的界面 patterns 势在必行。但具体怎么做呢？Pattern library 工具又如何助我们以响应式的方式思考和行动呢？
很多早期响应式设计测试工具专注于在主流手机上预览设计，像是320px (iPhone4竖屏)，768px (iPad竖屏)等等。但，网页比手机视图，平板视图和桌面视图更多样化。为了帮助设计师测试响应式设计时更好的兼顾所有分辨率，我创造了一个叫 ish 的工具。
取 ish 这个名字，是由于选择小的按钮会产生一个小视区。再度选择会提供另一个。选择中等按钮会给你一个中等大小的视区。大的则会产生一个大视区。这些随机值有助于设计师和程序猿兼顾所有分辨率，不会局限于主流设备尺寸。
Ish. 被整合到了 Pattern Lab 里，也就是说我们可以在任何分辨率下查看界面和它们包含的 patterns。
Pattern Lab 以小视区显示
中等视区显示
大视区显示
在 ish 帮助设计师和开发者找出存在于视区连续性中的 bug 时，我发觉它作为客户与同事的教育工具用处更大。将一个独立于设备又可调整大小的视区工具整合到 pattern library 中，你的客户和同事都能秒懂这套设计系统的视觉和功能不受视区大小的影响。
#查看底层代码
Pattern library 的一个常用功能就是查看构成特定组件的底层代码。显示出 pattern 代码加快了开发速度 (我爱死复制粘贴了，程序猿都爱，真的)，还可帮助团队 leader 贯彻代码风格和样式规范。当茫茫多程序猿都在公司开发部门工作时，这个功能收益极高。
Pattern library 中高亮代码的类型每家公司都不同，以达到海量各异的环境，技术和约定要求。大多数野生模式库只展示出基本的 HTML，而其他 pattern library 还包括自定义的 CSS 和 JavaScript。举个栗子，Saleforce 公司的 Lightning 设计系统，模式中同时涵盖了 HTML 和 (S) CSS。
Salesforce 的 Lightning 设计系统展示了界面组件的 HTML 和 SCSS 代码。
包含前端代码使得开发者在写代码时保持一致性，但这个方案也远非完美。开发人员还是有可能不受控制的写出不一致的脏代码—这就是为什么一些企业不惜代价构建复杂而精细的设计系统的缘由。像 Lonely Planet 这样的公司已经取得了 pattern library 中的圣杯，也就是说，他们的 pattern library 和生产环境完美同步。关于以上我们会在第5章做更详细的介绍，在本章节提及是为了展示 pattern library 中的代码是怎样受到影响的。与其提供 HTML 和 CSS，Lonely Planet 选择在 Rizzo style guide 中，将界面组件包含的代码展示出来，供开发团队随时拉取。
来自 Lonely Planet 的 Rizzo 设计系统，关于模版应用的示例。
这种设定允许核心开发团队只需维护一套源代码，就可以满足所有 patterns 的前端代码需求。对于其他开发人员来说，投入开发只需要从 pattern library 中拉取指定的代码即可。
Pattern Lab 既可查看模式本身的基础 HTML，也可查看用于生成 HTML 的相应模版代码。同时，它还可以扩展到显示包含 CSS 和 JavaScript 的示例。
Pattern Lab 中的代码视图同时展示了包含 pattern 代码和经过编译的 HTML。
不论你选择哪个 pattern library，最终都应该包含某种形式的代码视图。或许更重要的是，你创建的库应该包含能够提高你的开发团队效率的代码用例。
#在线的文档和注释系统
在传统开发流程中，由于开发人员大都各自为战，撰写成片累读的原型和说明文档，再讨论，评审已经是司空见惯的事情。PDF 是这类文档最常见的格式，内容涵盖 “有价值” 的洞见，各种说明文档和系统设计文档。不幸的是，项目投入生产时，这些史诗级文物大都被扔进了回收站……
事情本不该如此。一份界面设计说明文档应涉及到每一处的规范与细节—并且最重要的是—它应该做成在线的，可视的设计系统。高效的 pattern library 应该为定义和描述界面组件腾出空间—从可访问性到性能再到审美及用户体验，各方面都需要考虑清楚。
Pattern Lab 提供了几种添加描述和注释的方法。你可以通过创建与 pattern 同名的 Markdown 文件，来给模式添加描述 (e.g. pattern-name.md) ，这些描述会在列表视图中展示。
Pattern Lab 在线示例旁边展示了重要说明文档，有助于团队沟通
Pattern Lab 也提供一些很酷的 (我吹的) 特性，你可以在任何界面元素和视图中添加注释，并且，是在线的哦。当你打开注释功能，就可以看到每个存在注释的元素，上方都有个数字标识，点击即可跳转到相关注释。看着完整的用户界面，思考设计问题，是不是很灵活？
Pattern Lab 的注释功能整合到了在线界面中，并且可交互。
#支持模式沿袭的环境
在查看各种 patterns 时，我不禁思考，「有没有一种办法，可以了解这些组件都用到了哪些地方呢？」定义和描述 pattern 的特性是一回事，能否额外提供 pattern 的上下文信息又是另外一回事了。
由于采用了前边提到的俄罗斯套娃式的嵌套方法，Pattern Lab 能够显示是哪个 pattern 构成了给定的组件，还能够显示这些 pattern 都被用在什么地方。
Pattern Lab 的沿袭功能显示组件由哪些 patterns 构成，也标明了它们被用在何处
在上图的例子中，有一个叫 media-block 的分子 pattern，包含图片，标题，文本和一组按钮。通过模式沿袭可以看到，它包含一个叫 atoms-square 的 pattern，这是一个缩略图大小的图片，就好比 molecules-button-bar 是一组按钮。我们也可得知这个模式最终被用在哪里: media-block-list 组织中。
这些上下文信息对设计师和开发人员都有惊人的帮助，我自己在工作流程中就总会用到模式沿袭。比如我想修改特定 pattern，给某张图片放大一倍，或者额外添加界面元素：我们立即知道哪个 pattern 与模版需要重新测试，并且QA部门会确保变更不会使系统崩溃。沿袭功能还可以标出冗余和未充分利用的部分，随着上线日期渐近，开发团队可以将它们移出 pattern library。
# 每个人都有自己的选择
这就是你需要的。Pattern Lab 为团队提供的特性功能，有助于创建一个通过深思熟虑，经得起推敲的设计系统。但正如我之前所言，没有一个工具可以应对所有的情况。能帮你 创建一个高效 pattern library 的工具 数不胜数，而你的选择也无疑会受到你的企业环境，技术，工作流程和文化的影响。
在选择创建工具时，你应该仔细研究，看看是否符合以下标准:
-
提供模式描述和注释功能
-
示例涵盖相关 pattern 的 HTML，模版，CSS，和/或 JavaScript 代码
-
模式视图涵盖所有分辨率
-
示例提供变量，比如激活或禁用的标签
-
能够动态添加典型的内容文件到模式结构里
-
提供上下文信息
写在最后，本章与其说是关于创建 pattern libraries 的工具，倒不如说是关于我们如何去使用它们。创建并维护一个高效的设计系统，甚至可以对你的企业文化，发展和工作流程，产生戏剧性的影响。当然，做比说要难很多。不过，担心也大可不必。本书其余章节会向你详细展示，如何创建并维护一个成功设计系统的整个流程，帮助你完成企业部署，迈向长远的胜利。
原文链接：http://atomicdesign.bradfrost.com/chapter-1/
如有翻译错误欢迎留言指出。
