設計體系的響應式設計
（給前端大學加星標，提升前端技能.）
作者：TC
https://zhuanlan.zhihu.com/p/109781992
導讀
在螞蟻內(nèi)部有著數(shù)量繁多且復雜的中后臺業(yè)務系統(tǒng)，Ant Design 一直以來致力于從設計策略和資產(chǎn)的角度解決這些產(chǎn)品的體驗一致性問題，隨著螞蟻產(chǎn)品生態(tài)的多端化進程，越來越多的跨設備和不同屏幕尺寸導致的問題也逐漸暴露，例如：
XX 能力要在手機上使用，不得不單獨為移動端開發(fā)幾個頁面甚至一個產(chǎn)品（反之亦然）；產(chǎn)品數(shù)據(jù)量很大，Ant Design 默認字體 / 間距太大了，不夠緊湊；版式不夠優(yōu)化，造成空間浪費；
Ant Design 基于如何在小屏幕中解決信息展示問題這樣的出發(fā)點也在很多組件中提供了響應式設計，但擁有更加完備的環(huán)境適應性應該是一個設計體系長期的目標之一，因此在全局性地考慮跨端、跨多屏幕尺寸、信息密度等響應式設計方面還值得我們繼續(xù)深入研究。本篇文章橫向調(diào)研了 Fluent - Microsoft、Material Design - Google、Fiori - SAP、Lightning - Salesforce、Carbon - IBM、Alta - Oracle、Atlassian Design - Atlassian 等 10 余家企業(yè)級產(chǎn)品設計體系的響應式設計部分，從設計策略、設計模式、實施模式、設計方案四個層面大致歸納了一些信息，旨在對響應式設計有一個籠統(tǒng)的了解。
關(guān)于 Adaptive Design 與 Responsive Design
先厘清兩個概念，關(guān)于響應式設計通常會有兩個普遍認識，即 Aaron Gustafson 與 Ethan Marcotte 分別在 2011 年自己的著作中提出的 Adaptive Web Design (AWD)[1] 與 Responsive Web Design (RWD)[2] 概念，它們的核心區(qū)別在于 AWD 針對不同的設備或屏幕尺寸定制化設計多個固定布局的尺寸，而 RWD 是同一套代碼做彈性的適應[3][4]，本質(zhì)上它們都在解決產(chǎn)品設計如何適應于不同設備以及不同屏幕規(guī)格的問題，本篇所指的「響應式設計」 概念包含了兩者，不做明顯區(qū)分，關(guān)于 Adaptive 與 Responsive 設計怎么界定以及具體的規(guī)則本篇也不進行展開。
移動優(yōu)先設計策略
提響應式設計不得不提「移動優(yōu)先」設計策略，移動優(yōu)先[5]的概念最早是 Google 在 2010 年世界移動大會上提出來的一種產(chǎn)品策略，基于 Google 對未來趨勢中移動設備將會逐漸擁有核心地位的判斷。后來「移動優(yōu)先」更多被提及是作為一種在響應式設計中應用的設計策略，它認為在響應式設計中優(yōu)先為屏幕限制更大的移動設備設計，再擴展到大屏幕的 PC 端是一種更有效的設計方法，例如 Alta、Lightning、Fiori 均在設計體系中明確采用「移動優(yōu)先」的設計方法，F(xiàn)iori 尤其指出「移動優(yōu)先」專注核心功能，專注增強而非降級，提前考慮移動端更多的獨特特性以及異常情況，能提供更好的體驗。Material Design 可能算是移動優(yōu)先的最佳實踐，它本身就誕生于 Android 平臺，而后再通過大量響應式規(guī)則擴展到桌面及 Web 端，使得 Material 在多端都擁有一致貫穿的良好體驗。[6]
「移動優(yōu)先」本質(zhì)上是基于一種「增強」的設計思想，一個產(chǎn)品如果要同時適應于不同的設備，一直以來有兩種策略：優(yōu)雅降級 vs. 漸進增強[7]，后者認為先從最小和最受限制的低級設備（移動設備）入手，再為更高級的設備（桌面設備）增強信息和交互，這意味著在更多限制下，迫使設計考慮如何減少、匯總，分組信息，有利于聚焦核心信息以及為更多限制考慮。
然而移動設備已不再是「低級設備」，F(xiàn)iori 盡管強調(diào)「專注增強而非降級」，但它同時提出的「提前考慮移動端更多的獨特特性」卻與漸進增強的設計思想相悖，讓「移動優(yōu)先」淪為了某種形式化而難以執(zhí)行，例如下面這個報告界面的場景里，移動端僅展示匯總的報告圖表信息，但匯總圖表并沒有「擴展」到 Tablet 里而是用明細數(shù)據(jù)替換圖表，而在桌面端同時包含了明細數(shù)據(jù)與圖表兩部分信息，這看上去并不像是一個「增強」的設計思路，更像是在全量需求下基于設備限制所采用的「降級」策略。
因此「移動優(yōu)先」并不一定是形式上優(yōu)先設計移動端，它被廣泛接受和應用的是背后的漸進增強的核心思想。我認為在移動設備高度發(fā)展的當下，「移動優(yōu)先」不再適合作為單獨概念提出來，而漸進增強的設計思想應該體現(xiàn)在更細分的場景中，例如在布局、信息排版以及交互反饋中，我們應該優(yōu)先考慮限制更大的移動端；在一些交互方式上，優(yōu)先考慮限制更大的鼠標操作。甚至在復雜業(yè)務場景里，優(yōu)先滿足核心業(yè)務流程順暢也屬于漸進增強的策略范疇。
設計模式
這里講的設計模式是指設計師在具體業(yè)務中針對不同的情況可以采用的通用性設計方案，這些設計模式除了單獨應用外，有時候也可以多種模式結(jié)合應用。Fluent 歸納了 6 種對應不同情況的響應式設計模式，非常全面地涵蓋了其它設計體系中的絕大部分方案，分別是：調(diào)整大小、重新定位、重新排列、顯示/隱藏、替換、重新構(gòu)建[8]。
Resize - 調(diào)整大小
調(diào)整大小是最基礎的設計模式，是一個容器默認的響應式模式，通常有等比縮放、固定高度、或是在不同尺寸下按不同比例規(guī)格縮放三種形式，即便在無響應式設計的體系里，容器跟隨屏幕尺寸而變化也是一個常見的應用方式。
Reposition - 重新定位
改變 UI 元素的相對位置，以充分利用不同尺寸的空間。重新定位在響應式應用里多見在框架上，或是在組件里對一些特定元素的處理，例如 Material 的全局浮動按鈕與浮動的下拉菜單以 Reposition 的形式分別在桌面端與移動端處于不同的位置。
Reflow - 重新排列
改變 UI 元素的排列方式，這在內(nèi)容彈性布局里較常見，通常是基于某種排列規(guī)則自動向下折行，并結(jié)合調(diào)整大小與柵格系統(tǒng)應用在響應式布局方面，例如 Carbon 的 Fluid Grid。
Show / Hide - 顯示 / 隱藏
基于屏幕空間、設備不同特性、特定情況等顯示或隱藏 UI 元素，例如大多數(shù)設計體系的框架設計應用在小屏幕上會隱藏側(cè)邊菜單。Material 在組件響應式行為里提到的 Expand 也屬于 Show / Hide 的延伸。
Replace - 替換
針對不同尺寸的屏幕采用不同形態(tài)的組件，通常應用在對具體的組件做針對性響應式設計中，但需要注意用戶面對變化時的認知成本。
Re-architect - 重新構(gòu)建
折疊或拆分信息架構(gòu)，這種模式在 Web 端較難實現(xiàn)，通常出現(xiàn)在一些 Native App 的場景。
Density - 內(nèi)容密度
除了上述 6 種模式以外，我把內(nèi)容密度也歸納為一種設計模式，F(xiàn)iori、Material Design、 以及 Atlassian 都提出了內(nèi)容密度的概念。Fiori 基于移動優(yōu)先在移動端采用默認密度，而針對大屏幕的 Web 端則提供緊湊密度的方案，他們認為移動端手指交互所需的空間要求更高；Material 則是針對很多表格表單類的組件都定制了 Default、Comfortable、Compact 三種密度的視覺表現(xiàn)。通過被動響應式或主動控制內(nèi)容密度很好的解決了不同尺寸屏幕的信息獲取效率問題。
值得一提的是 Atlassian 通過柵格系統(tǒng)的間距來控制密度而非對內(nèi)容密度本身進行設計，越緊湊的布局柵格間距越小，這看上去很合理，卻很容易造成內(nèi)容密度增加的同時整體信息獲取效率反而降低的問題。Material 也有關(guān)于柵格空間的定義，但在內(nèi)容密度的處理上和 Atlassian 恰恰相反，它認為高密度內(nèi)容適用更寬松的柵格空間，相對是一個更合理的設計。在信息密度的問題上，我們的核心目的其實是提升信息效率而非單純提高視覺密度，因此解法上需要更完善的考慮。
實施模式
實施模式是指設計體系為實現(xiàn)具體設計方案而定義的一系列基礎規(guī)則、解決方案或技術(shù)手段，經(jīng)過整理總結(jié)為相對尺寸單位、屏幕斷點、彈性布局、柵格系統(tǒng) 4 個方面。
Rem - 相對尺寸單位
幾乎所有應用于 Web 的設計體系的技術(shù)方案中都采用 rem 相對單位，Material、Fiori、Carbon 和 Lightning 均沿用了瀏覽器默認的 root 尺寸，即 1rem = 16px，Alta 默認采用是 14px 的規(guī)格，并允許基于不同應用選擇 12px 或 16px 的規(guī)格，默認情況 Alta 采用更小規(guī)格的單位會在小屏幕電腦上有更好的表現(xiàn)，這也許和他們的產(chǎn)品特性相關(guān)。
相對尺寸單位是非常具有實施價值的，它使產(chǎn)品能在保持信息節(jié)奏的情況下根據(jù)不同的情況等比例縮放內(nèi)容，這使得設計能更方便地調(diào)整內(nèi)容密度，或許還可以配合 Media Queries 解決部分跨端的尺寸適配問題，且?guī)缀鯖]有前端成本。
國內(nèi)的前端業(yè)界包括我們自己的前端同學更多將 Rem 運用在移動端，主要為了兩個目的：方便計算尺寸、在不同寬度的設備上等比縮放內(nèi)容，這樣的用法是出于前端工程師解決屏幕兼容性的一種技術(shù)手段，在使用上本身也存在一定爭議[9]，而在響應式設計領(lǐng)域我們還沒有發(fā)揮出 Rem 應該發(fā)揮的作用，甚至很多設計師還并不了解相對尺寸單位的使用方法，廣泛應用 Rem 能為我們帶來哪些實際價值是接下來需要繼續(xù)研究的。
Breakpoints - 屏幕斷點
屏幕斷點是響應式設計的基礎依據(jù)，它決定了我們要適配到什么樣的設備或屏幕規(guī)格，并通過 Media Queries 這樣的技術(shù)實現(xiàn)不同 Breakpoint 條件下的不同 UI 表現(xiàn)。一般情況 Breakpoints 都是基于 Phone、Tablet、Desktop 的維度來設計的，包括考慮了移動設備的橫評豎屏情況，關(guān)于詳細的規(guī)格設置其實并沒有太大參考價值，設計體系都是根據(jù)自身定位以及設備覆蓋的情況來制訂的，例如 Material 的斷點在低分辨率范圍分得非常細，是因為 Material 主要服務的 Android 平臺有著數(shù)量繁多的設備分辨率。在滿足自己需求的前提下，屏幕端點不需要太多，無論怎樣基于數(shù)據(jù)驅(qū)動的屏幕斷點設置將會是一個更科學的方法。
Fiori 的斷點設計比較有意思，在設計文檔中僅有基本的布局規(guī)則，沒有明確的 Breakpoints 規(guī)則，F(xiàn)iori 對于不同的組件會設計不同的 Breakpoints，例如在 Table 這個組件中定義了 0 < 220 < 270 < 350 < 460 < 570 < ∞ 的規(guī)格，而在 Form 的組件中，Breakpoints 變成了 0 < 600 < 1024 < 1440 < ∞，從這點上看出 Fiori 認為不同的組件有不同的表達模式，因此應該針對性對組件進行優(yōu)化。
Flex Layout - 彈性布局
Flex 布局是 CSS3 提供的強大布局能力，從更自然更具語義化的角度實現(xiàn)界面元素的自適應。應用于 Web 的設計體系基本上都在組件代碼里廣泛采用了 Flex 布局，Lightning 還將柵格與 Flex 布局結(jié)合定義了自己更完善的布局方法。在響應式設計中，F(xiàn)lex 布局通常結(jié)合 Breakpoints 使用，在兩個 Breakpoints 之間讓界面做更平滑的過度。除此之外其它平臺也都有類似的彈性布局能力，例如 Fluent 在 windows 采用 XAML 構(gòu)建布局系統(tǒng)。
無論是 Flex 還是最近興起的 Grid 布局都是 CSS3 的基本布局能力，響應式設計要解決布局的問題將會深度依賴這些基礎技術(shù)手段，本篇不進一步展開。
Grid System - 柵格系統(tǒng)
柵格系統(tǒng)是所有設計體系必備的，我們通常將頁面橫向分為 N 列，定義每一列的尺寸與間距，這為界面布局提供了一致性和成本便利。傳統(tǒng)的柵格系統(tǒng)在響應式方面的應用主要是結(jié)合 Breakpoints 與一些 Responsive Token 來實現(xiàn)的，通過給 UI 元素指定不同的柵格數(shù)來決定他們分別在不同屏幕下占多少列，同時一些設計體系還提供了可見性相關(guān)的 token，來控制界面元素在不同屏幕的顯示與隱藏。
Fluent、Fiori、Lightning、Material 以及大多數(shù)設計體系都采用了 12 柵格系統(tǒng)，因為 12 的因數(shù)夠多，能滿足足夠多的布局細分同時又不至于太復雜，Carbon 的做法更加 geek 一些，他們的「2x grid」采用了 16 柵格系統(tǒng)，布局粒度更細但放棄了 3，6 這樣的因數(shù)。Ant Design 為了滿足復雜的業(yè)務情況，采用了 24 柵格系統(tǒng)，24 柵格提供了更高的靈活性的同時，也大大增加了復雜度，面臨柵格系統(tǒng)的響應式設計 24 柵格是否適用還有待商榷。
另外 Material、Carbon 還明確提出了「Fluid Grid - 流體柵格」的概念，核心思想是在較小的屏幕上降低柵格數(shù)量，將多余的柵格自動折行彈性布局。
在屏幕尺寸變化時，柵格主要有兩種響應模式：Fluid、Fixed
這種將柵格系統(tǒng)與彈性布局相結(jié)合的方式基于一些簡單的規(guī)則設置，在不需要特定響應式的場景中不再需要指定繁瑣的 token，且能滿足大部分高頻且通用的情況，在一定程度上降低了成本。
組件應用
除了通用的響應式規(guī)則以外，設計體系在具體組件中的響應式方案還有許多值得挖掘，能為我們的組件設計提供參考價值，本篇不再一一展開，僅提兩個典型的應用情況：
框架
框架算是一個特殊的組件，在不同的設備中界面框架的適用有非常大的差異，幾乎提到響應式的所有設計體系都給出了框架響應式方案，例如 Alta 將界面框架分為四塊，以 Off-Canvas 和 Reposition 兩種方式在不同尺寸的屏幕中顯示或隱藏以及通過特定的方式展開或呼出。
通常情況下設計體系的框架組成按形式可以分為：
Header - 通常情況下常駐
Sidenav - 分為左側(cè)右側(cè)兩種情況，一般用于放置導航，在不同設備會有展開，收縮，隱藏三種狀態(tài)
Content - 內(nèi)容區(qū)，通常由 Grid 控制布局
Footer - 如有，固定在頁面底部
Float - 浮動框架，用于臨時狀態(tài)，通知或彈窗等
設計體系通過對框架的定義，以及控制不同部分基于什么樣的模式響應屏幕尺寸來實施對框架的響應式設計。
組件
Fluent 或 Material 在設計文檔中更多基于基礎的網(wǎng)格，布局，設計模式來闡述通用性的響應式規(guī)則，因此他們的響應式設計有非常好的延續(xù)性，組件的響應式方案基本上都遵循這些規(guī)則。
而 Fiori 以及 Lightning 在通用性響應式設計模式上的定義上沒有那么全面，他們側(cè)重于在組件層面對所有組件都考慮了針對性的 Responsive 或 Adaptive 的方案。例如 Fiori 在響應式表格的組件里，在桌面端與移動端分別是 table 和 list 的模式，這個方案并不是通過全局抽象規(guī)則得出來的，而是基于對組件的針對性設計，正如他們?yōu)椴煌慕M件設計了不同的 Breakpoints，這種針對性也適用于特定的 UI 解決方案。
在一定程度上抽象規(guī)則的同時，如果我們能夠為每一個組件都考慮到不同場景的響應式，當然就會提供更精細化的體驗。在一個完備的設計體系里，在設計每一個組件資產(chǎn)時都以漸進增強的設計策略，考慮到不同的設備及屏幕適配是非常有必要的。
響應式設計的世界煙波浩渺，書不盡言，言不盡意。Ant Design 目前計劃從布局基礎規(guī)則以及內(nèi)容密度的解決方案切入，逐步完善響應式設計的體系，這是一個重要且漫長的過程，至于文中挖下的坑還需要深入研究逐一補充，本篇初探先到這里，歡迎大家留言指出問題也很希望大家能留下想法共同探討。
分享前端好文，點亮?在看?