【Web技術】522- 設計體系的響應式設計

• 2020 年 3 月 6 日
• 筆記

正文從這開始～～

導讀

在螞蟻內部有著數量繁多且複雜的中後台業務系統，Ant Design 一直以來致力於從設計策略和資產的角度解決這些產品的體驗一致性問題，隨著螞蟻產品生態的多端化進程，越來越多的跨設備和不同螢幕尺寸導致的問題也逐漸暴露，例如：

XX 能力要在手機上使用，不得不單獨為移動端開發幾個頁面甚至一個產品（反之亦然）；產品數據量很大，Ant Design 默認字體 / 間距太大了，不夠緊湊；版式不夠優化，造成空間浪費；

Ant Design 基於如何在小螢幕中解決資訊展示問題這樣的出發點也在很多組件中提供了響應式設計，但擁有更加完備的環境適應性應該是一個設計體系長期的目標之一，因此在全局性地考慮跨端、跨多螢幕尺寸、資訊密度等響應式設計方面還值得我們繼續深入研究。本篇文章橫向調研了 Fluent - Microsoft、Material Design - Google、Fiori - SAP、Lightning - Salesforce、Carbon - IBM、Alta - Oracle、Atlassian Design - Atlassian 等 10 余家企業級產品設計體系的響應式設計部分，從設計策略、設計模式、實施模式、設計方案四個層面大致歸納了一些資訊，旨在對響應式設計有一個籠統的了解。

關於 Adaptive Design 與 Responsive Design

先釐清兩個概念，關於響應式設計通常會有兩個普遍認識，即 Aaron Gustafson 與 Ethan Marcotte 分別在 2011 年自己的著作中提出的 Adaptive Web Design (AWD)[1] 與 Responsive Web Design (RWD)[2] 概念，它們的核心區別在於 AWD 針對不同的設備或螢幕尺寸訂製化設計多個固定布局的尺寸，而 RWD 是同一套程式碼做彈性的適應[3][4]，本質上它們都在解決產品設計如何適應於不同設備以及不同螢幕規格的問題，本篇所指的「響應式設計」 概念包含了兩者，不做明顯區分，關於 Adaptive 與 Responsive 設計怎麼界定以及具體的規則本篇也不進行展開。

移動優先設計策略

提響應式設計不得不提「移動優先」設計策略，移動優先[5]的概念最早是 Google 在 2010 年世界移動大會上提出來的一種產品策略，基於 Google 對未來趨勢中移動設備將會逐漸擁有核心地位的判斷。後來「移動優先」更多被提及是作為一種在響應式設計中應用的設計策略，它認為在響應式設計中優先為螢幕限制更大的移動設備設計，再擴展到大螢幕的 PC 端是一種更有效的設計方法，例如 Alta、Lightning、Fiori 均在設計體系中明確採用「移動優先」的設計方法，Fiori 尤其指出「移動優先」專註核心功能，專註增強而非降級，提前考慮移動端更多的獨特特性以及異常情況，能提供更好的體驗。Material Design 可能算是移動優先的最佳實踐，它本身就誕生於 Android 平台，而後再通過大量響應式規則擴展到桌面及 Web 端，使得 Material 在多端都擁有一致貫穿的良好體驗。[6]

Material Design 的響應式設計

「移動優先」本質上是基於一種「增強」的設計思想，一個產品如果要同時適應於不同的設備，一直以來有兩種策略：優雅降級 vs. 漸進增強[7]，後者認為先從最小和最受限制的低級設備（移動設備）入手，再為更高級的設備（桌面設備）增強資訊和交互，這意味著在更多限制下，迫使設計考慮如何減少、匯總，分組資訊，有利於聚焦核心資訊以及為更多限制考慮。

然而移動設備已不再是「低級設備」，Fiori 儘管強調「專註增強而非降級」，但它同時提出的「提前考慮移動端更多的獨特特性」卻與漸進增強的設計思想相悖，讓「移動優先」淪為了某種形式化而難以執行，例如下面這個報告介面的場景里，移動端僅展示匯總的報告圖表資訊，但匯總圖表並沒有「擴展」到 Tablet 里而是用明細數據替換圖表，而在桌面端同時包含了明細數據與圖表兩部分資訊，這看上去並不像是一個「增強」的設計思路，更像是在全量需求下基於設備限制所採用的「降級」策略。

Fiori 報告介面的 Adaptive Design

因此「移動優先」並不一定是形式上優先設計移動端，它被廣泛接受和應用的是背後的漸進增強的核心思想。我認為在移動設備高度發展的當下，「移動優先」不再適合作為單獨概念提出來，而漸進增強的設計思想應該體現在更細分的場景中，例如在布局、資訊排版以及交互回饋中，我們應該優先考慮限制更大的移動端；在一些交互方式上，優先考慮限制更大的滑鼠操作。甚至在複雜業務場景里，優先滿足核心業務流程順暢也屬於漸進增強的策略範疇。

設計模式

這裡講的設計模式是指設計師在具體業務中針對不同的情況可以採用的通用性設計方案，這些設計模式除了單獨應用外，有時候也可以多種模式結合應用。Fluent 歸納了 6 種對應不同情況的響應式設計模式，非常全面地涵蓋了其它設計體系中的絕大部分方案，分別是：調整大小、重新定位、重新排列、顯示/隱藏、替換、重新構建[8]。

Resize - 調整大小

調整大小是最基礎的設計模式，是一個容器默認的響應式模式，通常有等比縮放、固定高度、或是在不同尺寸下按不同比例規格縮放三種形式，即便在無響應式設計的體系里，容器跟隨螢幕尺寸而變化也是一個常見的應用方式。

Reposition - 重新定位

改變 UI 元素的相對位置，以充分利用不同尺寸的空間。重新定位在響應式應用里多見在框架上，或是在組件里對一些特定元素的處理，例如 Material 的全局浮動按鈕與浮動的下拉菜單以 Reposition 的形式分別在桌面端與移動端處於不同的位置。

Reposition

Reflow - 重新排列

改變 UI 元素的排列方式，這在內容彈性布局裡較常見，通常是基於某種排列規則自動向下折行，並結合調整大小與柵格系統應用在響應式布局方面，例如 Carbon 的 Fluid Grid。

Reflow

Show / Hide - 顯示 / 隱藏

基於螢幕空間、設備不同特性、特定情況等顯示或隱藏 UI 元素，例如大多數設計體系的框架設計應用在小螢幕上會隱藏側邊菜單。Material 在組件響應式行為里提到的 Expand 也屬於 Show / Hide 的延伸。

Show / Hide

Replace - 替換

針對不同尺寸的螢幕採用不同形態的組件，通常應用在對具體的組件做針對性響應式設計中，但需要注意用戶面對變化時的認知成本。

Re-architect - 重新構建

摺疊或拆分資訊架構，這種模式在 Web 端較難實現，通常出現在一些 Native App 的場景。

Density - 內容密度

除了上述 6 種模式以外，我把內容密度也歸納為一種設計模式，Fiori、Material Design、 以及 Atlassian 都提出了內容密度的概念。Fiori 基於移動優先在移動端採用默認密度，而針對大螢幕的 Web 端則提供緊湊密度的方案，他們認為移動端手指交互所需的空間要求更高；Material 則是針對很多表格表單類的組件都訂製了 Default、Comfortable、Compact 三種密度的視覺表現。通過被動響應式或主動控制內容密度很好的解決了不同尺吋螢幕的資訊獲取效率問題。

Material Design 的內容密度示例

值得一提的是 Atlassian 通過柵格系統的間距來控制密度而非對內容密度本身進行設計，越緊湊的布局柵格間距越小，這看上去很合理，卻很容易造成內容密度增加的同時整體資訊獲取效率反而降低的問題。Material 也有關於柵格空間的定義，但在內容密度的處理上和 Atlassian 恰恰相反，它認為高密度內容適用更寬鬆的柵格空間，相對是一個更合理的設計。在資訊密度的問題上，我們的核心目的其實是提升資訊效率而非單純提高視覺密度，因此解法上需要更完善的考慮。

Atlassian 與 Material 的柵格密度對比

實施模式

實施模式是指設計體系為實現具體設計方案而定義的一系列基礎規則、解決方案或技術手段，經過整理總結為相對尺寸單位、螢幕斷點、彈性布局、柵格系統 4 個方面。

Rem - 相對尺寸單位

幾乎所有應用於 Web 的設計體系的技術方案中都採用 rem 相對單位，Material、Fiori、Carbon 和 Lightning 均沿用了瀏覽器默認的 root 尺寸，即 1rem = 16px，Alta 默認採用是 14px 的規格，並允許基於不同應用選擇 12px 或 16px 的規格，默認情況 Alta 採用更小規格的單位會在小螢幕電腦上有更好的表現，這也許和他們的產品特性相關。

相對尺寸單位是非常具有實施價值的，它使產品能在保持資訊節奏的情況下根據不同的情況等比例縮放內容，這使得設計能更方便地調整內容密度，或許還可以配合 Media Queries 解決部分跨端的尺寸適配問題，且幾乎沒有前端成本。

中國的前端業界包括我們自己的前端同學更多將 Rem 運用在移動端，主要為了兩個目的：方便計算尺寸、在不同寬度的設備上等比縮放內容，這樣的用法是出於前端工程師解決螢幕兼容性的一種技術手段，在使用上本身也存在一定爭議[9]，而在響應式設計領域我們還沒有發揮出 Rem 應該發揮的作用，甚至很多設計師還並不了解相對尺寸單位的使用方法，廣泛應用 Rem 能為我們帶來哪些實際價值是接下來需要繼續研究的。

Breakpoints - 螢幕斷點

螢幕斷點是響應式設計的基礎依據，它決定了我們要適配到什麼樣的設備或螢幕規格，並通過 Media Queries 這樣的技術實現不同 Breakpoint 條件下的不同 UI 表現。一般情況 Breakpoints 都是基於 Phone、Tablet、Desktop 的維度來設計的，包括考慮了移動設備的橫評豎屏情況，關於詳細的規格設置其實並沒有太大參考價值，設計體系都是根據自身定位以及設備覆蓋的情況來制訂的，例如 Material 的斷點在低解析度範圍分得非常細，是因為 Material 主要服務的 Android 平台有著數量繁多的設備解析度。在滿足自己需求的前提下，螢幕端點不需要太多，無論怎樣基於數據驅動的螢幕斷點設置將會是一個更科學的方法。

螢幕斷點分布

Fiori 的斷點設計比較有意思，在設計文檔中僅有基本的布局規則，沒有明確的 Breakpoints 規則，Fiori 對於不同的組件會設計不同的 Breakpoints，例如在 Table 這個組件中定義了 0 < 220 < 270 < 350 < 460 < 570 < ∞ 的規格，而在 Form 的組件中，Breakpoints 變成了 0 < 600 < 1024 < 1440 < ∞，從這點上看出 Fiori 認為不同的組件有不同的表達模式，因此應該針對性對組件進行優化。

Fiori 的 Table 組件適配情況

Fiori 的 Form 組件適配情況

Flex Layout - 彈性布局

Flex 布局是 CSS3 提供的強大布局能力，從更自然更具語義化的角度實現介面元素的自適應。應用於 Web 的設計體系基本上都在組件程式碼里廣泛採用了 Flex 布局，Lightning 還將柵格與 Flex 布局結合定義了自己更完善的布局方法。在響應式設計中，Flex 布局通常結合 Breakpoints 使用，在兩個 Breakpoints 之間讓介面做更平滑的過度。除此之外其它平台也都有類似的彈性布局能力，例如 Fluent 在 windows 採用 XAML 構建布局系統。

無論是 Flex 還是最近興起的 Grid 布局都是 CSS3 的基本布局能力，響應式設計要解決布局的問題將會深度依賴這些基礎技術手段，本篇不進一步展開。

Grid System - 柵格系統

柵格系統是所有設計體系必備的，我們通常將頁面橫向分為 N 列，定義每一列的尺寸與間距，這為介面布局提供了一致性和成本便利。傳統的柵格系統在響應式方面的應用主要是結合 Breakpoints 與一些 Responsive Token 來實現的，通過給 UI 元素指定不同的柵格數來決定他們分別在不同螢幕下佔多少列，同時一些設計體系還提供了可見性相關的 token，來控制介面元素在不同螢幕的顯示與隱藏。

Fluent、Fiori、Lightning、Material 以及大多數設計體系都採用了 12 柵格系統，因為 12 的因數夠多，能滿足足夠多的布局細分同時又不至於太複雜，Carbon 的做法更加 geek 一些，他們的「2x grid」採用了 16 柵格系統，布局粒度更細但放棄了 3，6 這樣的因數。Ant Design 為了滿足複雜的業務情況，採用了 24 柵格系統，24 柵格提供了更高的靈活性的同時，也大大增加了複雜度，面臨柵格系統的響應式設計 24 柵格是否適用還有待商榷。

另外 Material、Carbon 還明確提出了「Fluid Grid - 流體柵格」的概念，核心思想是在較小的螢幕上降低柵格數量，將多餘的柵格自動折行彈性布局。

Carbon 的柵格定義

在螢幕尺寸變化時，柵格主要有兩種響應模式：Fluid、Fixed

Fluid

Fixed

這種將柵格系統與彈性布局相結合的方式基於一些簡單的規則設置，在不需要特定響應式的場景中不再需要指定繁瑣的 token，且能滿足大部分高頻且通用的情況，在一定程度上降低了成本。

組件應用

除了通用的響應式規則以外，設計體系在具體組件中的響應式方案還有許多值得挖掘，能為我們的組件設計提供參考價值，本篇不再一一展開，僅提兩個典型的應用情況：

框架

Carbon 的框架設計

框架算是一個特殊的組件，在不同的設備中介面框架的適用有非常大的差異，幾乎提到響應式的所有設計體系都給出了框架響應式方案，例如 Alta 將介面框架分為四塊，以 Off-Canvas 和 Reposition 兩種方式在不同尺寸的螢幕中顯示或隱藏以及通過特定的方式展開或呼出。

通常情況下設計體系的框架組成按形式可以分為：

• Header - 通常情況下常駐
• Sidenav - 分為左側右側兩種情況，一般用於放置導航，在不同設備會有展開，收縮，隱藏三種狀態
• Content - 內容區，通常由 Grid 控制布局
• Footer - 如有，固定在頁面底部
• Float - 浮動框架，用於臨時狀態，通知或彈窗等

設計體系通過對框架的定義，以及控制不同部分基於什麼樣的模式響應螢幕尺寸來實施對框架的響應式設計。

Material 的響應式框架

組件

Fluent 或 Material 在設計文檔中更多基於基礎的網格，布局，設計模式來闡述通用性的響應式規則，因此他們的響應式設計有非常好的延續性，組件的響應式方案基本上都遵循這些規則。

而 Fiori 以及 Lightning 在通用性響應式設計模式上的定義上沒有那麼全面，他們側重於在組件層面對所有組件都考慮了針對性的 Responsive 或 Adaptive 的方案。例如 Fiori 在響應式表格的組件里，在桌面端與移動端分別是 table 和 list 的模式，這個方案並不是通過全局抽象規則得出來的，而是基於對組件的針對性設計，正如他們為不同的組件設計了不同的 Breakpoints，這種針對性也適用於特定的 UI 解決方案。

Fiori 針對 Table 的響應式設計

在一定程度上抽象規則的同時，如果我們能夠為每一個組件都考慮到不同場景的響應式，當然就會提供更精細化的體驗。在一個完備的設計體系里，在設計每一個組件資產時都以漸進增強的設計策略，考慮到不同的設備及螢幕適配是非常有必要的。

響應式設計的世界煙波浩渺，書不盡言，言不盡意。Ant Design 目前計劃從布局基礎規則以及內容密度的解決方案切入，逐步完善響應式設計的體系，這是一個重要且漫長的過程，至於文中挖下的坑還需要深入研究逐一補充，本篇初探先到這裡，歡迎大家留言指出問題也很希望大家能留下想法共同探討。[10]

關於本文作者：@TC原文：https://zhuanlan.zhihu.com/p/109781992