設(shè)計體系的響應(yīng)式設(shè)計

2021-7-2    資深UI設(shè)計者

隨著產(chǎn)品生態(tài)的多端化進程,越來越多的跨設(shè)備和不同屏幕尺寸導(dǎo)致的問題也逐漸暴露,例如:

XX 能力要在手機上使用,不得不單獨為移動端開發(fā)幾個頁面甚至一個產(chǎn)品(反之亦然);產(chǎn)品數(shù)據(jù)量很大,Ant Design 默認字體 / 間距太大了,不夠緊湊;版式不夠優(yōu)化,造成空間浪費;

Ant Design 基于如何在小屏幕中解決信息展示問題這樣的出發(fā)點也在很多組件中提供了響應(yīng)式設(shè)計,但擁有更加完備的環(huán)境適應(yīng)性應(yīng)該是一個設(shè)計體系長期的目標之一,因此在全局性地考慮跨端、跨多屏幕尺寸、信息密度等響應(yīng)式設(shè)計方面還值得我們繼續(xù)深入研究。

本篇文章橫向調(diào)研了 Fluent – Microsoft、Material Design – Google、Fiori – SAP、Lightning – Salesforce、Carbon – IBM、Alta – Oracle、Atlassian Design – Atlassian 等 10 余家企業(yè)級產(chǎn)品設(shè)計體系的響應(yīng)式設(shè)計部分,從設(shè)計策略、設(shè)計模式、實施模式、設(shè)計方案四個層面大致歸納了一些信息,旨在對響應(yīng)式設(shè)計有一個籠統(tǒng)的了解。

關(guān)于 Adaptive Design 與 Responsive Design先厘清兩個概念,關(guān)于響應(yīng)式設(shè)計通常會有兩個普遍認識,即 Aaron Gustafson 與 Ethan Marcotte 分別在 2011 年自己的著作中提出的 Adaptive Web Design (AWD) 與 Responsive Web Design (RWD) 概念,它們的核心區(qū)別在于 AWD 針對不同的設(shè)備或屏幕尺寸定制化設(shè)計多個固定布局的尺寸,而 RWD 是同一套代碼做彈性的適應(yīng),本質(zhì)上它們都在解決產(chǎn)品設(shè)計如何適應(yīng)于不同設(shè)備以及不同屏幕規(guī)格的問題,本篇所指的「響應(yīng)式設(shè)計」 概念包含了兩者,不做明顯區(qū)分,關(guān)于 Adaptive 與 Responsive 設(shè)計怎么界定以及具體的規(guī)則本篇也不進行展開。


移動優(yōu)先設(shè)計策略

提響應(yīng)式設(shè)計不得不提「移動優(yōu)先」設(shè)計策略,移動優(yōu)先的概念最早是 Google 在 2010 年世界移動大會上提出來的一種產(chǎn)品策略,基于 Google 對未來趨勢中移動設(shè)備將會逐漸擁有核心地位的判斷。后來「移動優(yōu)先」更多被提及是作為一種在響應(yīng)式設(shè)計中應(yīng)用的設(shè)計策略,它認為在響應(yīng)式設(shè)計中優(yōu)先為屏幕限制更大的移動設(shè)備設(shè)計,再擴展到大屏幕的 PC 端是一種更有效的設(shè)計方法。

例如 Alta、Lightning、Fiori 均在設(shè)計體系中明確采用「移動優(yōu)先」的設(shè)計方法,F(xiàn)iori 尤其指出「移動優(yōu)先」專注核心功能,專注增強而非降級,提前考慮移動端更多的獨特特性以及異常情況,能提供更好的體驗。Material Design 可能算是移動優(yōu)先的最佳實踐,它本身就誕生于 Android 平臺,而后再通過大量響應(yīng)式規(guī)則擴展到桌面及 Web 端,使得 Material 在多端都擁有一致貫穿的良好體驗。

(Material Design 的響應(yīng)式設(shè)計)


「移動優(yōu)先」本質(zhì)上是基于一種「增強」的設(shè)計思想,一個產(chǎn)品如果要同時適應(yīng)于不同的設(shè)備,一直以來有兩種策略:優(yōu)雅降級 vs. 漸進增強,后者認為先從最小和最受限制的低級設(shè)備(移動設(shè)備)入手,再為更高級的設(shè)備(桌面設(shè)備)增強信息和交互,這意味著在更多限制下,迫使設(shè)計考慮如何減少、匯總,分組信息,有利于聚焦核心信息以及為更多限制考慮。

然而移動設(shè)備已不再是「低級設(shè)備」,F(xiàn)iori 盡管強調(diào)「專注增強而非降級」,但它同時提出的「提前考慮移動端更多的獨特特性」卻與漸進增強的設(shè)計思想相悖,讓「移動優(yōu)先」淪為了某種形式化的概念而難以執(zhí)行。

例如下面這個報告界面的場景里,移動端僅展示匯總的報告圖表信息,但匯總圖表并沒有「擴展」到 Tablet 里而是用明細數(shù)據(jù)替換圖表,而在桌面端同時包含了明細數(shù)據(jù)與圖表兩部分信息,這看上去并不像是一個「增強」的設(shè)計思路,更像是在全量需求下基于設(shè)備限制所采用的「降級」策略。

(Fiori 報告界面的 Adaptive Design)


因此「移動優(yōu)先」并不一定是形式上優(yōu)先設(shè)計移動端,它被廣泛接受和應(yīng)用的是背后的漸進增強的核心思想。我認為在移動設(shè)備高度發(fā)展的當(dāng)下,「移動優(yōu)先」不再適合作為單獨概念提出來,而漸進增強的設(shè)計思想應(yīng)該體現(xiàn)在更細分的場景中,例如在布局、信息排版以及交互反饋中,我們應(yīng)該優(yōu)先考慮限制更大的移動端;在一些交互方式上,優(yōu)先考慮限制更大的鼠標操作。甚至在復(fù)雜業(yè)務(wù)場景里,優(yōu)先滿足核心業(yè)務(wù)流程順暢也屬于漸進增強的策略范疇。


設(shè)計模式

這里講的設(shè)計模式是指設(shè)計師在具體業(yè)務(wù)中針對不同的情況可以采用的通用性設(shè)計方案,這些設(shè)計模式除了單獨應(yīng)用外,有時候也可以多種模式結(jié)合應(yīng)用。Fluent 歸納了 6 種對應(yīng)不同情況的響應(yīng)式設(shè)計模式,非常全面地涵蓋了其它設(shè)計體系中的絕大部分方案,分別是:調(diào)整大小、重新定位、重新排列、顯示/隱藏、替換、重新構(gòu)建。

Resize – 調(diào)整大小

調(diào)整大小是最基礎(chǔ)的設(shè)計模式,是一個容器默認的響應(yīng)式模式,通常有等比縮放、固定高度、或是在不同尺寸下按不同比例規(guī)格縮放三種形式,即便在無響應(yīng)式設(shè)計的體系里,容器跟隨屏幕尺寸而變化也是一個常見的應(yīng)用方式。

(Resize)


Reposition – 重新定位

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


(Reposition)


Reflow – 重新排列

改變 UI 元素的排列方式,這在內(nèi)容彈性布局里較常見,通常是基于某種排列規(guī)則自動向下折行,并結(jié)合調(diào)整大小與柵格系統(tǒng)應(yīng)用在響應(yīng)式布局方面,例如 Carbon 的 Fluid Grid。



(Reflow)

Show / Hide – 顯示 / 隱藏

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



(Show / Hide)

Replace – 替換

針對不同尺寸的屏幕采用不同形態(tài)的組件,通常應(yīng)用在對具體的組件做針對性響應(yīng)式設(shè)計中,但需要注意用戶面對變化時的認知成本。



(Replace)

Re-architect – 重新構(gòu)建

折疊或拆分信息架構(gòu),這種模式在 Web 端較難實現(xiàn),通常出現(xiàn)在一些 Native App 的場景。



(Re-architect)

Density – 內(nèi)容密度

除了上述 6 種模式以外,我把內(nèi)容密度也歸納為一種設(shè)計模式,F(xiàn)iori、Material Design、 以及 Atlassian 都提出了內(nèi)容密度的概念。Fiori 基于移動優(yōu)先在移動端采用默認密度,而針對大屏幕的 Web 端則提供緊湊密度的方案,他們認為移動端手指交互所需的空間要求更高;Material 則是針對很多組件都定制了 Default、Comfortable、Compact 三種密度的視覺表現(xiàn)。通過被動響應(yīng)式或主動控制內(nèi)容密度很好的解決了不同尺寸屏幕的信息獲取效率問題。

(Material Design 的內(nèi)容密度示例)


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

(Atlassian 與 Material 的柵格密度對比)


實施模式

實施模式是指設(shè)計體系為實現(xiàn)具體設(shè)計方案而定義的一系列基礎(chǔ)規(guī)則、解決方案或技術(shù)手段,經(jīng)過整理總結(jié)為相對尺寸單位、屏幕斷點、彈性布局、柵格系統(tǒng) 4 個方面。

Rem – 相對尺寸單位

幾乎所有應(yīng)用于 Web 的設(shè)計體系的技術(shù)方案中都采用 rem 相對單位,Material、Fiori、Carbon 和 Lightning 均沿用了瀏覽器默認的 root 尺寸,即 1rem = 16px,Alta 默認采用是 14px 的規(guī)格,并允許基于不同應(yīng)用選擇 12px 或 16px 的規(guī)格,默認情況 Alta 采用更小規(guī)格的單位會在小屏幕電腦上有更好的表現(xiàn),這也許和他們的產(chǎn)品特性相關(guān)。

相對尺寸單位是非常具有實施價值的,它使產(chǎn)品能在保持信息節(jié)奏的情況下根據(jù)不同的情況等比例縮放內(nèi)容,這使得設(shè)計能更方便地調(diào)整內(nèi)容密度,或許還可以配合 Media Queries 解決部分跨端的尺寸適配問題,且?guī)缀鯖]有前端成本。

國內(nèi)的前端業(yè)界包括我們自己的前端同學(xué)更多將 Rem 運用在移動端,主要為了兩個目的:方便計算尺寸、在不同寬度的設(shè)備上等比縮放內(nèi)容,這樣的用法是出于前端工程師解決屏幕兼容性的一種技術(shù)手段,在使用上本身也存在一定爭議,而在響應(yīng)式設(shè)計領(lǐng)域我們還沒有發(fā)揮出 Rem 應(yīng)該發(fā)揮的作用,甚至很多設(shè)計師還并不了解相對尺寸單位的使用方法,廣泛應(yīng)用 Rem 能為我們帶來哪些實際價值是接下來需要繼續(xù)研究的。

Breakpoints – 屏幕斷點

屏幕斷點是響應(yīng)式設(shè)計的基礎(chǔ)依據(jù),它決定了我們要適配到什么樣的設(shè)備或屏幕規(guī)格,并通過 Media Queries 這樣的技術(shù)實現(xiàn)不同 Breakpoint 條件下的不同 UI 表現(xiàn)。一般情況 Breakpoints 都是基于 Phone、Tablet、Desktop 的維度來設(shè)計的,包括考慮了移動設(shè)備的橫評豎屏情況,關(guān)于詳細的規(guī)格設(shè)置其實并沒有太大參考價值,設(shè)計體系都是根據(jù)自身定位以及設(shè)備覆蓋的情況來制訂的,例如 Material 的斷點在低分辨率范圍分得非常細,是因為 Material 主要服務(wù)的 Android 平臺有著數(shù)量繁多的設(shè)備分辨率。在滿足自己需求的前提下,屏幕端點不需要太多,無論怎樣基于數(shù)據(jù)驅(qū)動的屏幕斷點設(shè)置將會是一個更科學(xué)的方法。


(屏幕斷點分布)

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

(Fiori 的 Table 組件適配情況)

(Fiori 的 Form 組件適配情況)


Flex Layout – 彈性布局

Flex 布局是 CSS3 提供的強大布局能力,從更自然更具語義化的角度實現(xiàn)界面元素的自適應(yīng)。應(yīng)用于 Web 的設(shè)計體系基本上都在組件代碼里廣泛采用了 Flex 布局,Lightning 還將柵格與 Flex 布局結(jié)合定義了自己更完善的布局方法。在響應(yīng)式設(shè)計中,F(xiàn)lex 布局通常結(jié)合 Breakpoints 使用,在兩個 Breakpoints 之間讓界面做更平滑的過度。除此之外其它平臺也都有類似的彈性布局能力,例如 Fluent 在 windows 采用 XAML 構(gòu)建布局系統(tǒng)。

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

Grid System – 柵格系統(tǒng)

柵格系統(tǒng)是所有設(shè)計體系必備的,我們通常將頁面橫向分為 N 列,定義每一列的尺寸與間距,這為界面布局提供了一致性和成本便利。傳統(tǒng)的柵格系統(tǒng)在響應(yīng)式方面的應(yīng)用主要是結(jié)合 Breakpoints 與一些 Responsive Token 來實現(xiàn)的,通過給 UI 元素指定不同的柵格數(shù)來決定他們分別在不同屏幕下占多少列,同時一些設(shè)計體系還提供了可見性相關(guān)的 token,來控制界面元素在不同屏幕的顯示與隱藏。

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

另外 Material、Carbon 還明確提出了「Fluid Grid – 流體柵格」的概念,核心思想是在較小的屏幕上降低柵格數(shù)量,將多余的柵格自動折行彈性布局。


(Carbon 的柵格定義)

在屏幕尺寸變化時,柵格主要有兩種響應(yīng)模式:Fluid、Fixed


(Fluid)


(Fixed)


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


組件應(yīng)用

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

框架

(Carbon 的框架設(shè)計)


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

通常情況下設(shè)計體系的框架組成按形式可以分為:

  • Header – 通常情況下常駐

  • Sidenav – 分為左側(cè)右側(cè)兩種情況,一般用于放置導(dǎo)航,在不同設(shè)備會有展開,收縮,隱藏三種狀態(tài)

  • Content – 內(nèi)容區(qū),通常由 Grid 控制布局

  • Footer – 如有,固定在頁面底部

  • Float – 浮動框架,用于臨時狀態(tài),通知或彈窗等

設(shè)計體系通過對框架的定義,以及控制不同部分基于什么樣的模式響應(yīng)屏幕尺寸來實施對框架的響應(yīng)式設(shè)計。


(Material 的響應(yīng)式框架)


組件

Fluent 或 Material 在設(shè)計文檔中更多基于基礎(chǔ)的網(wǎng)格,布局,設(shè)計模式來闡述通用性的響應(yīng)式規(guī)則,因此他們的響應(yīng)式設(shè)計有非常好的延續(xù)性,組件的響應(yīng)式方案基本上都遵循這些規(guī)則。

而 Fiori 以及 Lightning 在通用性響應(yīng)式設(shè)計模式上的定義上沒有那么全面,他們側(cè)重于在組件層面對所有組件都考慮了針對性的 Responsive 或 Adaptive 的方案。例如 Fiori 在響應(yīng)式表格的組件里,在桌面端與移動端分別是 table 和 list 的模式,這個方案并不是通過全局抽象規(guī)則得出來的,而是基于對組件的針對性設(shè)計,正如他們?yōu)椴煌慕M件設(shè)計了不同的 Breakpoints,這種針對性也適用于特定的 UI 解決方案。

(Fiori 針對 Table 的響應(yīng)式設(shè)計)

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

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





藍藍設(shè)計建立了UI設(shè)計分享群,每天會分享國內(nèi)外的一些優(yōu)秀設(shè)計,如果有興趣的話,可以進入一起成長學(xué)習(xí),請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務(wù)合作,也請與我們聯(lián)系。

截屏2021-05-13 上午11.41.03.png


文章來源:站酷  作者:Ant_Design

分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責(zé)聲明:藍藍設(shè)計尊重原作者,文章的版權(quán)歸原作者。如涉及版權(quán)問題,請及時與我們?nèi)〉寐?lián)系,我們立即更正或刪除。

藍藍設(shè)計bouu.cn )是一家專注而深入的界面設(shè)計公司,為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)





分享本文至:

日歷

鏈接

個人資料

存檔