《原子設計》第三章：常用工具

作者：Brad Frost 翻譯：主物質界面 reg 校對：主物質界面

其它章節

我們翻譯的這本書，可能是下一個設計趨勢

《原子設計》前言+關於作者

《原子設計》第一章：設計中的系統

《原子設計》第二章：原子設計方法論

在前面的章節中，我介紹了用原子設計語言來構建用戶界面的方法論。希望你能認同原子設計對於如何構建UI設計系統的理念，不過現在是時候走下象牙塔，在現實世界中將原子設計理念落地了。n

模式化的設計與開發，基石是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"> n <a href="{{ url }}"> n {{> atoms-thumb }} n <h3>{{ headline }}</h3> n <p>{{ excerpt }}</p> n</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">n {{> atoms-logo }}n {{> molecules-primary-nav }}n {{> molecules-search }}</header>

發生了什麼？我們看到基本的 < header> 元素，裡邊含有 logo 圖片原子，主導航欄分子以及搜索欄分子。

現在我們就可以隨時在需要的地方引用相關 pattern 了。

{{> organisms-header }}

我希望你領會到了俄羅斯套娃的精髓所在。最小的單位原子包含在分子中，分子包含在有機物里。現在我們來把這些組件放到布局中去。以主頁模板為例：

Time Inc. 的主頁模板包含少量可重複 patterns：一個全局標頭，一個主題圖片，少量區塊 (包含圖片，標題，摘要和 call to action 按鈕)，一塊含有4個欄目的區域，一個模擬地圖以及一個全局頁腳。

快速瀏覽一下主頁模板，你會看到一些非常典型的 patterns：頂部標頭，底部頁腳，一個全屏寬度的主題圖。在模板中還可以看到少量其他重複 patterns。

那這些在代碼中是什麼樣呢？跟你想的差不多，它引入了更多包含邏輯：

{{> organisms-header }}<main role="main">n {{# hero }}n {{> molecules-hero }}n {{/ hero }} <section>n {{# experience-block }}n {{> molecules-block-main }}n {{/ experience-block }}n {{# experience-feature }}n {{> organisms-story-feature }}n {{/ experience-feature }} </section> <section>n {{# factoid-advertising }}n {{> organisms-factoid }}n {{/ factoid-advertising }} </section> <section>n {{# advertising }}n {{> molecules-block-main }}n {{/ advertising }} </section>n … n</main>{{> organisms-footer }}

到這個階段，很多小一些的 pattern 早已建好，所以模板所要做的，就是把它們拉取到網頁布局中去，並給出命名。

仔細看一眼代碼，你會發現特定 pattern 像 {{> organisms-header }} 和 {{> organisms-footer }} 組織方式和前邊的示例是一樣的。但也有少量 patterns 包含一些附加信息作為補充，比如：

{{# factoid-advertising }}n{{> organisms-factoid }}n{{/ 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" : { n "headline": "Lorem Ipsum", n "img": { n "src": "/images/sample/fpo_herno.png", n "alt": "Hero Image" n}}

對於開發者來講，這種格式可能看起來很眼熟。當然如果你不懂開發也沒關係。看到大括弧和引號旁邊，我們定義了叫 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" : { n "headline": "Moving People", n "img": { n "src": "/images/hero_beyonce.jpg", n "alt": "Beyonce" n }}

通過重寫默認數據，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" : [ n { n "img": "/images/sample/avatar1.jpg", n "name" : "Steve Boomshakalaka", n "title" : "CIA" n }, n { n "img": "/images/sample/avatar2.jpg", n "name" : "Gingersnap Jujubees-Daniels", n "title" : "President of the Longest Company Name in the World Corporation, Global Division" n }, n { n "img": "/images/sample/avatar3.jpg", n "name" : "Sarunus Marciulionis", n "title" : "Golden State Warriors" n }, n { n "img": "/images/sample/avatar4.jpg", n "name" : "Sara Smith", n "title" : "Short Title" n }]

默認情況下，我們預設用戶為普通用戶，不是管理員，但如果在 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"> n <img src="{{ img }}" alt="{{ name }}" /> n <h3>{{ name }}</h3> n <h4>{{ title }}</h4>n {{# isAdmin }}n {{> molecules-block-actions }}n {{/ 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) ，這些描述會在列表視圖中展示。n

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-2/

如有翻譯錯誤歡迎留言指出。