Just Sword Wang's Blog

响应式设计实践手札

说到相应式设计,首先要提及的是其核心技术Media Queries。记得还是在我10年前上大学的时候,看着书本中描述响应式设计的愿景仿佛还如同昨日,如今随着Media Queries受到浏览器广泛支持而早已成为现实。我最早写的关于Media Queries的CSS3 Media Queries 详解一文,发布于2010-08-23,距今已然6年,并且Media Queries Lv3也已经在2012年成为W3C推荐标准——也正是2012年,算是响应式设计的爆发之年。

于是这些年来各种设计精巧的响应式页面便层出不穷,虽然国内老牌网站鲜见(业务和浏览器的各种因素),却在国外遍地开花。虽然使用的算不上多,但这些年的一些思考需要整理一下,本文就是我近年来对响应式设计的实践以及一些粗浅经验和建议,分别从设计和代码角度来看响应式页面。

响应式设计

响应式设计(Responsive web design,以下皆简称RWD)致力于提供跨设备的最佳体验。但说到底,RWD做的再好终究是无法同单一设备优化的页面相比的,RWD的优点并非是体验本身,而是基于一套代码的适应性的体验改良——从大多数意义上讲,实际是指尽可能减少相同的页面在移动端的缩放平移滚动

因为覆盖面更广,RWD的设计里多出了许多额外需要权衡的取舍,这对设计和前端都有所要求,所以如果设计和前端是分开独立运行,那么务必需要更为紧密的沟通。很多时候为了寻求设计和实现的平衡点,分工过于明确的团队会额外消耗大量的沟通时间。

个人是赞同前端自己来设计RWD的,如果只一人操作RWD,那么还是加修设计的前端更合适一些,因为从设计出发常常妨碍RWD的初衷——设计的内容无法用一种结构来描述的话,RWD意义就不大了。如果是设计师主导设计页面结构,那么一个简单的原则,就是将内容切割分块然后像堆积木一样来倒序摆放

适用范围

RWD并非万能,相反其适用面其实相当有限。广义的RWD是需要自适应到手机屏幕的,对于4-6寸巴掌大小的屏幕,信息承载能力自然有限。虽然从PC端自适应的过程中可以做减法,但页面核心内容还是被严格地限制着。所以复杂页面不可能适合RWD——一个简单的衡量标准是,页面上需要表达的点一般不超过10个。实际上互联网绝对多数的站点业务并不复杂,所以其实RWD还是很有市场,特别是对于展示类网站,RWD几乎都是首选。无奈国内小而美的战点相对较少,所以RWD也就相对要少很多。

移动web设计

这几年移动影响Web设计的趋势已经越发明显,简单列举一些常见的模式转变:

  • 滚动加载替代分页,对应手机端的滑屏。
  • 基于矢量的扁平化设计,高PPI屏幕清晰度和性能的需求
  • 内容尺寸放大,开始以拇指触碰的精度设计交互组件
  • 缩减hover的使用,使得移动端和PC端交互一致
  • 更为明显的交互态,例如Button,受限于无法hover,那么人们必须第一眼就识别出交互组件的外观
  • 汉堡图标和抽屉式页面,这些都是APP的标准交互形式,现在已经不仅仅出现在移动端页面里,甚至直接出现在PC端。

这些改变,使得我们渐渐一眼就能看出一个页面是否是RWD——大尺寸交互元素配上简单空旷的页面风格。

RWD模式

既然移动影响了相当多的PC端设计,那么也一定有相当多的固有套路,比如:

  • 通栏:总是最有效的突出内容且易于RWD控制的形式。
  • 抽屉:多种类型屏幕里,弹窗的伸缩性往往受到更多限制。
  • 折叠:屏幕的变换会使得定位元素的定位管理变得麻烦,当我们需要一个more info,往往不是弹窗不是定位浮层,而是向下展开更多内容。
  • 自然换行:和下面要讲的多语言更有关些。

多语言

RWD配上多语言,使得原本复杂的页面更显得麻烦。但是相比普通页面,RWD和多语言的相性却并不差。实际上宽松的页面结构加上原本就为不同屏幕设计自适应布局,多语言化的话反而要更为顺利一些,当然前提是设计之初就已经有了相当多的考虑。于是就会常常遇到“自然换行”,这种自然换行却恰恰也是需要设计的一部分,一个页面如果能保证大部分内容自然换行都不会影响页面整体的话,才是成功的RWD。

响应式代码

一般的认知是RWD因为一套结构的关系,所以比较节省开发资源。但实际节省下来的后端开发,与额外增加的前端工程以及设计上的制衡相互抵消。一个项目是否真的节省了资源最终还是要看项目本身的复杂度,不过从大的范围来看,相对节约资源是正确的,当然付出的代价就是一种平庸,因为融合而又要做到体验的极致是相当困难的。

Media Queries是RWD实现的基石,而宽度则又是RWD的核心维度(我们还是一如既往的不怎么关心高度~)。

设备

虽然我们常常为了某个设备制作RWD页面,但真正的RWD页面需要应对的并不是某某设备,而是页面内容本身——针对内容做响应式设计,而不是针对某个设备。当然实际情况,大多数人还是会偏向对编写针对设备断点的代码,比如下面这个是我以前为了一个团队分享所画的断点图示:

screen breakpoint

虽然已经是一年多以前的图,但近几年移动端变化已经减缓所以依旧可以看看。针对设备做优化的好处是直接有效,成本低可控制。如果当真对页面内容做RWD,单一语言还比较好控制,多语言总是会遇到各种奇葩问题,可能在各种妥协下页面的整体设计就一团糟了。

性能

就目前的流量和网络来说,RWD还是显得太笨重。之前我做过一些页面的简单对比,相同页面平均速度要差3-4倍,相当可观。分析原因主要还是因为PC的重量连带给RWD后,拖慢了整体页面的加载速度,无法与传统的单一优化的H5页面相比。这些问题等到未来网速加快会渐渐显得不能刺眼,不过当前还不能忽视。

代码特点

RWD的核心代码关键词是普通流(或称常规流,normal flow)。普通流是最能保证自适应的CSS定位机制,清晰的文档上下文秩序,在这个基础上运用浮动和有限的定位,是RWD的主流做法。在这过程中有一些常见的编码问题需要注意:

  • 严格限制的position,z-index,overflow:hidden。虽然正常情况下这些CSS属性也是需要一定限制的,但在RWD中显得更为重要。
  • 避免line-height垂直居中。由于无法确定在某种特定状况下发生换行而使得页面非常难看,除非能保证内容完全无折行可能,不然调整行高是毫无必要。
  • 字体问题。传统PC有一些奇技淫巧,比如字符箭头,在RWD里容易出问题。曾经我们可能只需要考虑桌面环境(并且往往是windows为主),而现在需要面对的则是更为复杂的客户端环境。使用的字符比以往更容易受到系统和设置的影响而出现错位,应该尽力避免。
  • 定宽的绝对定位。绝对定位常常用在宽度恒定的地方,比如icon。在多语言的情况下,如果能用定宽icon替代文本,那么应该优先考虑通用的图形。这让我想起来宜家家居的安装说明书——如果你仔细看过他们的说明书的话,就会发现安装说明只有图示没有任何文字出现。

值得一提的是,表格处理绝对是RWD的烦人问题之一。当需要把一张又长又宽的表格塞进手机里的时候,会发现真的非常无奈。目前对于这种情况往往有3种处理方式:

  1. 添加容器,并使得整个表格在容器中截断,在移动端用滚动条查看。所有表格都能搞定,体验蛋疼。
  2. 以display:table,display:table-cell等样式模拟显示PC端的表格,到移动端再将表格打散重新排布 。缺点是无法真正模拟复杂表格,对跨单元格的结构也无能为力,表格内容超长时也不如表格稳定,并且在移动端打散表格后常常会因为没有th而使表格变得意义不明。
  3. 通过巧妙地隐藏和展示部分表格单元,让表格在一定意义上变形为适合移动端的形式。这种方式通常只适合一些不太复杂的表格,但是是最为合理的方案。其中,表格th常常需要应用到CSS before为元素的content以及自定义数据,将对应的th用样式的方式写入td的开头。
  4. 两个或更多表格做切换,不是真正意义上的RWD~这里只是列一下。

响应式与React

当前前端领域,React如火如荼,但React的响应式目前做起来就不那么方便。由于HTML由JS接管,反倒是出现了连结构也根据不同屏幕变化的做法,已经与传统的响应式完全不同甚至是背道而驰的。

总结

响应式强迫性地精简了页面,是一场轻内容的战斗。未来我们可能面临更多未知的设备,响应式能否继续发展取决于这些新设备适用度。就目前来说,RWD已经是非常成熟的一种套路,使用前只需确定业务是否合适即可。目前,无论是微软,Google,Apple,他们的不少页面都有相当不错的体验。


评论加载中...

Disqus提供评论支持,如果评论长时间未加载,请飞跃长城。