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