栅格之外

. 10 min read . Written by seki
栅格之外

了解响应式设计的人,大多都见过这样的一图流:

https://s2.ax1x.com/2020/01/23/1Vaxhj.jpg

也可能是这样:

https://storage.googleapis.com/spec-host/mio-staging%2Fmio-design%2F1576174064000%2Fassets%2F0B9msDEx00QXmaldJd3BqU0NJUWc%2F01-ui-regions.gif

它们试图展示一套标准,这套标准一般被称为栅格系统(Grid system),用于描述视窗分辨率变化过程中界面元素的变化规则。栅格的概念源于印刷品时期,作为一种辅助版面设计的秩序系统,被沿用至GUI时代。

但栅格是否真的可以辅助GUI设计?在我的经验中,栅格系统可以帮助设计师在不同宽度下分割内容块,并保持间距稳定,但并不能解决响应式变化问题。

栅格系统并不复杂,同时它也不能解决太复杂的事情。对于响应式布局,实际上我们要解决的问题是:

  • 当窗口分辨率变化时,GUI元素大小应相对固定,而不是跟随内容拉伸、变大
  • 不同的分辨率和使用场景下,用户体验尽可能一致
  • 用尽可能简单的方式,让开发者理解并实现变化策略

这些需求和栅格系统没有太大关系。

此外,页面中文字的行高是固定的,这导致很多元素都会保持固定高度——标题高度是固定的,列表行高是固定的,图片和icon更不用说,大部分情况下它们宽高都是固定不变的。因此,设计师一般只考虑各模块的宽度变化。

1.响应式与自适应

响应式(Responsive)和自适应(Adaptive)是一组容易被混淆的概念,Fiori Desige是这样定义的:

  • 响应式 描述不同分辨率下UI保持一致的规则
  • 自适应 更关注不同终端下的表现

在WIMP模式下的桌面端,尤其是web端中,响应式更需要重视。允许用户在一定范围内自由控制窗口宽高,而UI中各个元素也能随之适应性变化,这无疑是很好的体验。

但这并不意味着,web端上的元素仅仅通过改变元素大小和位置就能够很好适配移动端UI。例如,表格是web端常见功能模块,但照搬到移动端上恐怕会体验不佳,而移动端的使用场景实际上高度碎片化,表格这样存放大量数据,需要长时间聚焦的模块实际上并不适用于移动端。因此,“在移动端上浏览表格”本身是伪需求,作为代替,移动端只展示关键数据即可。这样的设计策略便是自适应,自适应并不追求“一致”,而更强调“取舍”。

2.与开发者协作

假如设计师设定好Gutter/Collumn的值,并向前端同学解释清栅格系统的概念,是否就能保证页面具有良好的响应性变化?

实际上早几年的UI框架Bootstrap就做过这样的事。这些组件库指明了两个需要关注的点:

  • 断点(Breakpoint)——仅仅通过移动元素位置、压缩画布宽度来实现自适应变化是有极限的,借助断点,我们可以让布局结构发生变化以满足进一步的视窗宽度压缩。这些临界点被称为断点,在web前端中往往通过媒体查询(MediaQuery)实现。
  • 移动端优先原则(Mobile first)——简单来说,当布局足以满足移动端苛刻的视窗尺寸和场景时,适应更大更沉浸的桌面端自然不在话下,对于设计师来说,这相当于提取出最必不可少的功能(奥卡姆剃刀)再一步步做加法,也很符合思维逻辑。在我看来,Mobile first原则相当于一种简化的自适应策略。

总之,开发者关注的是具体实现:媒体查询的值、宽度固定与否、弹性布局的比例。栅格系统或许有助于设计落地,但并不是必要的。

3.制定策略的维度

需要从什么维度设计响应式策略?一页、一屏,还是一行?

对于那些内容有着较高一致性的产品,一整页沿用一套响应式策略是可行的。例如几乎是纯图片/视频的PinterstDribble来说,只需要保持固定宽度,设置多个断点即可

而门户这样内容不算繁重,迭代和交互不太复杂,但模块间又略微不同的页面来说,保证每一屏能够做好自适应也可。

https://s2.ax1x.com/2020/02/19/3ZSU76.png

但绝大多数情况下,我们需要从模块的角度思考响应式设计——每一个块都可能有自己的Adaptive,即便同一行中,也会存在定宽元素和响应式元素放置在同一行的情况。上图常见的图文排版中,预览文字的宽度、省略是很适合进行响应式变化的,但图片却需要固定宽高以保持最佳体验。

4.列表(表格)

我们可以把列表看作半形式化的文本内容。

文本内容属于“内容”,而内容要尽可能填满窗口——一般来说,这个值有上限,字号为14px时,文本块的宽度一般在600px至800px之间,而当文本块的宽度在200px以下时,阅读体验会急剧下降,因此我们可以认为文本内容的宽度应在200px至800px间自由变化。

文本块之所以有着较好的可变化性,源于它本身是一种成熟的内容架构——绝大多数人从识字以来就习惯从左自右、自上而下的阅读顺序(也有例外,比如阿拉伯语),即便整体宽度增删,也依然符合认知。

https://s2.ax1x.com/2020/02/16/39B9iD.png

而作为半形式化文本的列表,应当遵循同样的规律,即:

  • 如果希望列表宽度响应式变化,列表文本内容应保持左对齐
  • 如果内容不遵循左对齐,列表宽度应保持固定

例如上图右侧的列表中,“事项”和“数量”分别向左和向右对齐,不遵循左对齐的阅读顺序,因此该列的宽度保持固定,只有页面左侧保持响应式变化。

https://s2.ax1x.com/2020/02/16/39rFbt.png

但这些规律也并非绝对,既然是“半形式化”,就意味着列表可以做到文本块无法做到的事情,例如通过竖线划分不同的“列”,从而让最大宽度超出800px的界限。当列之间内容关联性不强,甚至形式有所区别时,并不需要完全遵循对齐规律,上图的表格中不仅包含文本,还含有tags和按钮这两种不同的元素,因此三者的列间距完全可以响应式变化,以获得更好的阅读体验。

5.图表

https://s2.ax1x.com/2020/02/19/3VqmgP.png

大部分情况下,图表可以被归类为两种:极坐标与笛卡尔坐标

极坐标,常见有饼图环图,不常见有玫瑰图雷达图玉玦图。总之,它们的特点就是“圆”——宽高始终保持1:1关系,这意味着当宽度发生变化时,极坐标的整体高度也必须变化。

如文章开头所说,页面中元素行高需保持固定,而极坐标图表的特性违背了这一原则。所以结论是,极坐标类图表尽量保持固定宽度。

笛卡尔坐标图表,常见的有折线图面积图柱状图,它们显然很适应做响应式变化,这里说一些需要注意的点:

  1. 折线图和面积图一般用于展现趋势,其中x轴代表时间。很多时候图表的时间范围由用户自由调节,这种情况下需明确时间单位颗粒度,例如,一周内数据可以以一小时为单位记录,而当时间范围扩大至一年时,这个值显然过密,如果再考虑上响应式变化…

  2. y轴也同样需要重视。是否有负数?有些数据波动很小,是否需要动态缩放y轴范围?

    https://s2.ax1x.com/2020/02/18/3FeTFP.png

  3. 留意柱状图的x轴刻度是否过密。如上图AntV图表,即便把刻度标签倾斜,也依然难以保证阅读体验。趋势类图表可以通过省略部分刻度避免此问题。

迷你图表可以嵌入到列表之中

字不如表,表不如图。用户在浏览图表时,通常先通过图形了解趋势,再进一步查看数值。实际上,图表里唯一不可或缺的只有图本身,数据可以隐藏在hover等交互中,从而渐进的展示内容,这意味着数据标签甚至图例都是能省略的。

6.为每类页面单独设置响应式策略

以ToB常见的控制台为例,我们可以把产品中的页面分为三类:

  1. 概览页面,主要由一块块的信息卡片组成,可响应式变化的宽度范围较小,所以概览页的最大宽度一般不会太大
  2. 详情页,起到展示信息的作用,内容常常由列表、表格、文字块等构成,其宽度越大越好,以承载更多信息。
  3. 表单页,承担信息录入的需求,一般由输入、选择组件构成。输入框不需要太大宽度,因此表单页宽度一般是产品中最小的。

可见,即便是强调“体验一致”的ToB系统中,响应式策略也各不相同。指望通过一套系统解决页面变化的问题,是不切实际的想法。