设计体系的响应式设计

点选下方“后端讲义”，选择“隆哥蒙”

每天后端合作开发蔬果第一时间送抵！

译者：TC

https://zhuanlan.zhihu.com/p/109781992

在蜜蜂外部有著数目多样且繁杂的中前台业务系统，Ant Design 一直以来致力从结构设计思路和资产的视角化解这些商品的新体验连续性难题，随着蜜蜂商品自然生态的格朗普雷县化民主化，愈来愈多的跨电子设备和不同萤幕体积导致的难题也逐渐曝露，比如：

XX 能力要在智能手机上使用，不得已原则上为终端端合作开发几个网页甚至三个商品（与此相反）；商品信息量很大，Ant Design 预设手写体 / 宽度太小了，不如紧凑型；开本不如强化，造成内部空间节约；

Ant Design 如前所述如何在小萤幕中化解重要信息展现难题这样的落脚点也在很多模块中提供了积极响应式结构设计，但保有更为完整的环境适应能力应该是三个结构设计管理体系长期的最终目标之一，因此在长期性地考量跨端、跨多萤幕体积、重要信息表面积等积极响应式结构设计方面还值得称赞我们继续深入研究。第一集该文纵向考察了 Fluent – Microsoft、Material Design – Google、Fiori – SAP、Lightning – Salesforce、Carbon – IBM、Alta – Oracle、Atlassian Design – Atlassian 等 10 家虚拟化商品结构设计管理体系的积极响应式结构设计部分，从结构设计思路、结构程序语言、实施商业模式、结构设计图五个微观大体归纳了一些重要信息，意在对积极响应式结构设计有三个简略的了解。

先理清三个基本概念，有关积极响应式结构设计一般来说会有三个两极化重新认识，即 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]

「终端优先」本质上是如前所述一种「增强」的结构设计思想，三个商品如果要同时适应于不同的电子设备，一直以来有两种思路：优雅降级 vs. 渐进增强[7]，后者认为先从最小和最受限制的低级设备（终端电子设备）入手，再为更高级的电子设备（桌面电子设备）增强重要信息和交互，这意味着在更多限制下，迫使结构设计考量如何减少、汇总，分组重要信息，有利于聚焦核心理念重要信息以及为更多限制考量。

然而终端电子设备已不再是「低级电子设备」，Fiori 尽管强调「专注增强而非降级」，但它同时提出的「提前考量终端端更多的独特特性」却与渐进增强的结构设计思想相悖，让「终端优先」沦为了某种形式化而难以执行，比如下面这个报告界面的场景里，终端端仅展现汇总的报告图表重要信息，但汇总图表并没有「扩展」到 Tablet 里而是用明细数据替换图表，而在桌面端同时包含了明细数据与图表两部分重要信息，这看上去并不像是三个「增强」的结构设计思路，更像是在全量需求下如前所述电子设备限制所采用的「降级」思路。

因此「终端优先」并不一定是形式上优先结构设计终端端，它被广泛接受和应用的是背后的渐进增强的核心理念思想。我认为在终端电子设备高度发展的当下，「终端优先」不再适合作为原则上基本概念提出来，而渐进增强的结构设计思想应该体现在更细分的场景中，比如在布局、重要信息排版以及交互反馈中，我们应该优先考量限制更大的终端端；在一些交互方式上，优先考量限制更大的鼠标操作。甚至在繁杂业务场景里，优先满足核心理念业务流程顺畅也属于渐进增强的思路范畴。

这里讲的结构程序语言是指结构设计师在具体业务中针对不同的情况可以采用的通用性结构设计图，这些结构程序语言除了原则上应用外，有时候也可以多种商业模式结合应用。Fluent 概括了 6 种对应不同情况的积极响应式结构程序语言，非常全面地涵盖了其它结构设计管理体系中的绝大部分方案，分别是：调整大小、重新定位、重新排列、显示/隐藏、替换、重新构建[8]。

调整大小是最基础的结构程序语言，是三个容器预设的积极响应式商业模式，一般来说有等比缩放、固定高度、或是在不同体积下按不同比例规格缩放三种形式，即便在无积极响应式结构设计的管理体系里，容器跟随萤幕体积而变化也是三个常见的应用方式。

改变 UI 元素的相对位置，以充分利用不同体积的内部空间。重新定位在积极响应式应用里多见在框架上，或是在模块里对一些特定元素的处理，比如 Material 的全局浮动按钮与浮动的下拉菜单以 Reposition 的形式分别在桌面端与终端端处于不同的位置。

改变 UI 元素的排列方式，这在内容弹性布局里较常见，一般来说是如前所述某种排列规则自动向下折行，并结合调整大小与栅格系统应用在积极响应式布局方面，比如 Carbon 的 Fluid Grid。

如前所述萤幕内部空间、电子设备不同特性、特定情况等显示或隐藏 UI 元素，比如大多数结构设计管理体系的框架结构设计应用在小萤幕上会隐藏侧边菜单。Material 在模块积极响应式行为里提到的 Expand 也属于 Show / Hide 的延伸。

针对不同体积的萤幕采用不同形态的模块，一般来说应用在对具体的模块做针对性积极响应式结构设计中，但需要注意用户面对变化时的认知成本。

折叠或拆分重要信息架构，这种商业模式在 Web 端较难实现，一般来说出现在一些 Native App 的场景。

除了上述 6 种商业模式以外，我把内容表面积也概括为一种结构程序语言，Fiori、Material Design、 以及 Atlassian 都提出了内容表面积的基本概念。Fiori 如前所述终端优先在终端端采用预设表面积，而针对大萤幕的 Web 端则提供紧凑型表面积的方案，他们认为终端端手指交互所需的内部空间要求更高；Material 则是针对很多表格表单类的模块都定制了 Default、Comfortable、Compact 三种表面积的视觉表现。通过被动积极响应式或主动控制内容表面积很好的化解了

值得称赞一提的是 Atlassian 通过栅格系统的宽度来控制表面积而非对内容表面积本身进行结构设计，越紧凑型的布局栅格宽度越小，这看上内部空间，相对是三个更合理的结构设计。在重要信息表面积的难题上，我们的核心理念目的其实是提升重要信息效率而非单纯提高视觉表面积，因此解法上需要更完善的考量。

实施商业模式是指结构设计管理体系为实现具体结构设计图而定义的一系列基础规则、化解方案或技术手段，经过整理总结为相对体积单位、萤幕断点、弹性布局、栅格系统 4 个方面。

几乎所有应用于 Web 的设计管理体系的技术方案中都采用 rem 相对单位，Material、Fiori、Carbon 和 Lightning 均沿用了浏览器预设的 root 体积，即 1rem = 16px，Alta 预设采用是 14px 的规格，并允许如前所述不同应用选择 12px 或 16px 的规格，预设情况 Alta 采用更小规格的单位会在小萤幕电脑上有更好的表现，这也许和他们的商品特性相关。

相对体积单位是非常具有实施价值的，它使商品能在保持重要信息节奏的情况下根据不同的情况等比例缩放内容，这使得结构设计能更方便地调整内容表面积，或许还可以配合 Media Queries 化解部分跨端的体积适配难题，且几乎没有后端成本。

国内的前端业界包括我们自己的后端同学更多将 Rem 运用在终端端，主要为了三个目的：方便计算体积、在不同宽度的电子设备上等比缩放内容，这样的用法是出于后端工程师化解萤幕兼容性的一种技术手段，在使用上本身也存在一定争议[9]，而在积极响应式结构设计领域我们还没有发挥出 Rem 应该发挥的作用，甚至很多结构设计师还并不了解相对体积单位的使用方法，广泛应用 Rem 能为我们带来哪些实际价值是接下来需要继续研究的。

萤幕断点是积极响应式结构设计的基础依据，它决定了我们要适配到什么样的电子设备或萤幕规格，并通过 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 认为不同的模块有不同的表达商业模式，因此应该针对性对模块进行强化。

Flex 布局是 CSS3 提供的强大布局能力，从更自然更具语义化的视角实现界面元素的自适应。应用于 Web 的结构设计管理体系基本上都在模块代码里广泛采用了 Flex 布局，Lightning 还将栅格与 Flex 布局结合定义了自己更完善的布局方法。在积极响应式结构设计中，Flex 布局一般来说结合 Breakpoints 使用，在三个 Breakpoints 之间让界面做更平滑的过度。除此之外其它平台也都有类似的弹性布局能力，比如 Fluent 在 windows 采用 XAML 构建布局系统。

无论是 Flex 还是最近兴起的 Grid 布局都是 CSS3 的基本布局能力，积极响应式结构设计要化解布局的难题将会深度依赖这些基础技术手段，第一集不进一步展开。

栅格系统是所有结构设计管理体系必备的，我们通常将网页纵向分为 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 – 流体栅格」的基本概念，核心理念思想是在较小的萤幕上降低栅格数目，将多余的栅格自动折行弹性布局。

在萤幕体积变化时，栅格主要有两种积极响应商业模式：Fluid、Fixed

这种将栅格系统与弹性布局相结合的方式如前所述一些简单的规则设置，在不需要特定积极响应式的场景中不再需要指定繁琐的 token，且能满足大部分高频且通用的情况，在一定程度上降低了成本。

除了通用的积极响应式规则以外，结构设计管理体系在具体模块中的积极响应式方案还有许多值得称赞挖掘，能为我们的模块结构设计提供参考价值，第一集不再一一展开，仅提三个典型的应用情况：

框架算是三个特殊的模块，在不同的电子设备中界面框架的适用有非常大的差异，几乎提到积极响应式的所有结构设计管理体系都给出了框架积极响应式方案，比如 Alta 将界面框架分为四块，以 Off-Canvas 和 Reposition 两种方式在不同体积的萤幕中显示或隐藏以及通过特定的方式展开或呼出。

一般来说情况下结构设计管理体系的框架组成按形式可以分为：

Header – 一般来说情况下常驻

Sidenav – 分为左侧右侧两种情况，一般用于放置导航，在不同电子设备会有展开，收缩，隐藏三种状态

Content – 内容区，一般来说由 Grid 控制布局

Footer – 如有，固定在网页底部

Float – 浮动框架，用于临时状态，通知或弹窗等

结构设计管理体系通过对框架的定义，以及控制不同部分如前所述什么样的商业模式积极响应萤幕体积来实施对框架的积极响应式结构设计。

Fluent 或 Material 在结构设计文档中更多如前所述基础的网格，布局，结构程序语言来阐述通用性的积极响应式规则，因此他们的积极响应式结构设计有非常好的延续性，模块的积极响应式方案基本上都遵循这些规则。

而 Fiori 以及 Lightning 在通用性积极响应式结构程序语言上的定义上没有那么全面，他们侧重于在模块微观对所有模块都考量了针对性的 Responsive 或 Adaptive 的方案。比如 Fiori 在响应式表格的模块里，在桌面端与终端端分别是 table 和 list 的商业模式，这个方案并不是通过全局抽象规则得出来的，而是如前所述对模块的针对性结构设计，正如他们为不同的模块结构设计了不同的 Breakpoints，这种针对性也适用于特定的 UI 化解方案。

在一定程度上抽象规则的同时，如果我们能够为每三个模块都考量到不同场景的积极响应式，当然就会提供更精细化的新体验。在三个完备的结构设计管理体系里，在结构设计每三个模块资产时都以渐进增强的结构设计思路，考量到不同的电子设备及萤幕适配是非常有必要的。

积极响应式结构设计的世界烟波浩渺，书不尽言，言不尽意。Ant Design 目前计划从布局基础规则以及内容表面积的化解方案切入，逐步完善积极响应式结构设计的管理体系，这是三个重要且漫长的过程，至于文中挖下的坑还需要深入探讨逐一补充，第一集初探先到这里，欢迎大家留言指出难题也很希望大家能留下想法共同探讨。