上期的週刊咱們介紹了 Design System 中最爲重要的一個概念 - Principles,做爲整個 Design System 的核心,它將指引着咱們整個產品設計、開發的過程和決策,同時它也體如今咱們整個 System 的基礎建設中。ajax
今天第三期的週刊將給你們介紹 System 中的 Components 和 Patterns,做爲咱們整個產品建設中的「磚、瓦、泥」,System 的「魂」也須要直接體如今它們的設計中。設計模式
在 Design System 的討論中,Components(組件)和 Patterns(模式)是一組很是容易混淆的概念。有些 System 中只有 Components,另外一些卻只有 Patterns,還有一些兩個都有。瀏覽器
因爲咱們不在其業務背景之中,理解他們的理念、初衷並非那麼容易,因此今天的這一期咱們將 Components 和 Patterns 放在一塊兒來討論,看看他們之間究竟有哪些差別?咱們應該如何去建立、使用它們。 框架
在這個系列的第一期,對 Components 有過一個基礎定義。它是整個產品設計的基礎,是組成一個界面的最基礎元素,爲完成一個基礎操做提供支持。post
早在 Web 時代咱們就有了 Components 的概念,輸入框、按鈕、文字、連接、下拉菜單… 從網頁開始出現,這些元素就已經被你們所認知、牢記。不管頁面的設計如何變化,它們基本上都是由這些組件所組成的。fetch
固然,網頁時代的早期咱們可用的組件並很少,偶爾出現一些新的形式也都是基於現有的組件組合或變形而來的。網站
因此對於用戶來講記住並理解它們的用途並不太難,這也就爲往後的設計的不斷髮展提供了一個可被認定、認知的基礎。設計
移動互聯網時代的到來,用戶的互聯網環境已經逐步遷移到了手機。因而對於設計師和用戶你們開始接觸到了 iOS、Android、Microsoft 等新的平臺,開始與這些新的組件打交道。code
事實上這些元素並無發生太大的變化,它們不少只是基於屏幕大小和可觸控的新特性發生了進化。而咱們所看到的那些組件在不一樣平臺上的差別性更可能是源於系統平臺自己以及它們的設計理念差別。cdn
這個現狀給設計師帶來了更多的麻煩,咱們在設計產品的同時還須要更多的關注不一樣操做平臺的組件差別性,以順應不一樣用戶的使用習慣。
固然,隨着行業的不斷髮展咱們所面臨的麻煩會更多,咱們如今所能看到的 VR 設備、線下實體以及咱們還未看到的新的形式都會讓 Components 不斷的進化,也變得更復雜。
相對於 Components,Patterns 要處理的事情會更復雜一些。它的目標是爲完成一個任務提供基礎操做,是解決一系列問題的全局解決方案。
舉一個直接的案例,在 Material Design 中有一個叫作 Confirmation & Acknowledgement (確認與知會)的 Pattern(見上圖)。
簡單來講當用戶在 App 中執行了一個操做,咱們須要給予反饋,告知用戶,而這個 Pattern 要解決的問題就是爲這一系列場景提供一套設計解決方案。
其實不管是 Components 仍是 Pattern,它們都是目標都是爲具體的問題提供實際、可複用的解決方案,爲整個產品開發過程提供一致性保障、提供決策依據以及提高效率下降開發成本。
基於上面的描述,你們應該對 Components 和 Patterns 有了一個基礎認知,但它倆之間的具體差別仍是比較模糊,因此接下來咱們從功能角度來接着聊聊它倆的差別。
事實上大多數的 Design System 並無特別清晰的去定義它倆,有些只給出了 Components,有些只給出 Patterns,好比下圖中的 Salesforce、Carbon、MailChimp。這背後其實與對應的業務領域及這些 System的理念有很大的關係,咱們在後面會再說起。
相較而言 Material Design 對於 Components 和 Patterns 有明顯的定義和區分。從這些關鍵詞的定義上咱們基本能夠看出Components 關注的是產品中的某個點,相對簡單;而 Pattern 關注得更可能是一件事兒,也相對更爲複雜。
仍是回到前面 Confirmation & Acknowledgement (確認與知會)的案例,Pattern 抽象了業務的可能性並提供了一個通用性的解決方案。
操做觸發、給予反饋,這裏麪包含的情景和複雜度顯然是高於利用菜單展現一列信息的。Material Design 將它大體分紅了兩種主要情景:
Material Design 分別使用了 Dialogs(重)和 Snackbar(輕)兩種設計形式來回應着兩種情景,爲其提供更爲合適的解決方案。
從業務場景抽離出來看,這個 Pattern 不只能夠用於信息列表的處理,還能夠用於處理購物車、wishlist、聯繫人… 這些業務場景各不相同,但均可以使用同一種設計模式。而這些 Design Pattern 也正是由咱們前面所提到的 Components 組合而來的。
再回到細節部分,Components 做爲「磚、瓦、泥」是有明確的使用指導的,每一個組件的尺寸規範使用方法都有明確的文檔給予細節的支持。
而 Patterns 做爲一種通用解決方案則更加靈活、鬆散,面向的不是一個具體界面而是一個產品(用戶)的需求而服務的。
咱們能夠再來看一個更爲直觀的例子 - 播放器。下圖是 YouTube 的在線播放器,從 System 的角度來講它會被應用在平臺的不少情景中。
咱們能夠將它定義爲一個視頻播放的通用 Pattern,若是咱們將它(下圖左)做爲該業務下播放器最複雜、最全的解決方案,那麼它也將應該依據場景訴求逐步降級(下圖右),爲播放器提供一個總體性的設計解決方案。
下圖是 YouTube 播放器的功能操做區,這裏面隱藏了 YouTube 的不少強大功能,從字幕、外鏈到畫質設置,均可以融入到這一小塊區域中。
若是咱們嘗試對這些功能作一些分解,能夠大體還原出這個 Pattern 的整個框架。爲了讓這個 Pattern 具有設計和工程兩個層面的一致性和複用度,設計師須要將關注點從某個具體業務抽離回來,站在更高的視角去看如何打造一個適用於更多情景的播放器框架,對於框架的構想和定義也可以方便全部相關人員用一樣的思惟方式去思考、判斷問題。
固然,Pattern 並不只僅以這一總形式存在,它的目的就是解決一類問題。它能夠是一組界面,也能夠是一個任務流(好比購買流程),甚至也能夠是一套手勢操做。
在前面咱們提到過,Pattern 與 Components 還有一個很大不一樣 - 領域的差別性。對於 Material Design 這種系統底層的 System 來講它能夠服務於任何領域、業務類型,因此他們的 Pattern 很「中立」,但對於咱們絕大多數設計師來講,咱們主要關注的是某一個領域的產品,因此咱們也更應該關注到 Pattern 的領域差別性。
Firefox 在幾個月前也發佈了他們本身的 Design System - Photon。做爲一款瀏覽器,Firefox 的關注點顯然與咱們大多數人是不同的。
瀏覽器(殼)中的內容是由網站所提供的,Photon 更關注的本身所服務的部分。它們會對 Warnings(警示)這類瀏覽器服務作清晰的定義,制定了普通警告和重要警示兩種不一樣等級,並提供了相應的設計展現。
而對於 MailChimp 它們甚至就不提供 Components ,只給出了一組 Pattern(好比下圖的 Feedback)。由於 MailChimp 本身的自身特性,它們的封裝已經足夠完整並且業務特性也很是的鮮明(且不會過於複雜),直接提供 Patterns 反而更利於總體的一致性和效率。
固然,MailChimp 沒有提供 Components 並不表明它們沒有,只不過將它們收起自行維護,使用者不用關心罷了。
聊了這麼多咱們不妨再來想一想 Components 與 Patterns 之間的差別,我嘗試將它概括成如下幾點:
講完了這兩個概念之間的差別,在餘下的全文中(付費部分)我想將重點回到 Patterns 上,和你們聊聊咱們爲何須要 Pattern 以及應該思考如何去完成對 Patterns 的總結、建立。
Design System 是 PinDesign 週刊的一個新系列,基於「Design Systems」這本書結構框架的讀書筆記和經驗總結。但願將本身的感覺和經驗分享給你們,輔助你們的閱讀。
加入 PinDesign 會員,獲取本期主題「什麼是 Design Principle」的全文內容及前兩期週刊的贈送。
Design System 往期回顧: