Responsive Web Design 的启发

Device !  Device !  Device !

现在能随时接入Internet的设备实在是太多,而且这些设备无论在显示屏的尺寸,分辨率方面都越来越多样。

这带来一个问题,许多之前为PC设计的网页到了这些设备上,就不那么好用了。现在很多网站解决这个问题的办法是为不同设备定制不同的独立站点。比如国内各种网站就有各种触屏版啊3G版之类的。这是一个办法,只是缺陷在于成本太高,也许对于少数个人维护的站点来说,这样做很简单。但对比较大的网站而言,每个独立的站点都要经过开发,测试和维护的流程,成本的上升还是会明显的。而如果压缩成本,做出来的东西质量又很难保证。

也许对于移动设备,比如智能手机和平板电脑而言,原生的APP是最终的解决方案,而且原生的APP也将带来更多的可能性。

最早在2010年,Ethan Marcotte在 A List Aprart上的一篇文章,就用media queries, fluid grid和scalable images结合的方式提供一个解决方案。后来类似的方式就都用了那篇文章的标题来归类,即Responsive Web Design

从显示上来说,一般首要解决LayoutFont-size的问题。

对于Layout,记得在2006和2007年那一阵,960px的定宽布局是比较流行的,后来还有人讨论1024px的宽度问题。如今比较流行的是比较fluid的布局方式,也就通过百分比,而不是固定的像素来布局。当然,定宽的方式在PC上仍然没问题,在有些移动设备上由于会自动缩放,显示效果也不差。但通常在移动设备上都会通过media query的方式切换到一个fluid的布局样式。

字体问题主要通过em去解决,用em而不是px去定义字体大小,区别是在于em是根据当前字体集成的像素大小去确定的。比较有意思的是现在有一个rem的用法,rem是根据html根标签上定义的字体像素来确定的。这种用法可以更容易精确的知道当前字体大小是怎样的。一种比较兼容的用法示例如下:

span {
     font-size:16px;
     font-size:1rem;
}

而对于fluid的Layout来说,zack发现很多网站在布局用的元素上携带上了这样一些css属性。

-moz-box-sizing:border-box;
-webkit-box-sizing:border-box;
box-sizing:border-box;

这解决了css中默认的box model会将padding等一起计算入宽度的问题,使得布局控制更容易些。

media query的方法则更多的用于一些局部的修正。而一些例如导航栏之类的组件,则只好通过javascript去做一些控制,在必要的时候再显示出来。

对于一些媒体资源,最常见的是图片,处理起来根据具体情况要复杂些。有时候我们需要延迟加载这些图片,有时候需要屏蔽显示,有时候需要调整显示的区域和大小,这些通过基本的javascript和media query都比较容易实现。而对于视频元素,更常见的方法是只是转化为源地址的链接。

但凭心而论,所谓Responsive Web Design已经是两年前的旧东西了。如今比较达成共识的是若要保证良好的交互体验,还是Native App最稳妥。

不过即便是做Native App,在这个移动设备迅速崛起的年代,对信息架构设计和产品设计本身都提出了一些需要转变的思路。其实Responsive Web Design的具体操作方式并非那么重要,之所以回顾一下这个内容,只是因为在那个过程中,有一些设计思路上需要转变的启示变得更加明显。zack认为主要有两点:

1. 聚焦。给用户提供最需要的内容,宁缺勿滥。人们需要考虑哪些东西对用户和生意来说是最重要的,否则面对多平台设备的复杂性,会造成许多成本的上升。

2. 以数据为中心的设计。在过去,我们对数据契约的定义所思考的并不多,但如今如果我们对数据契约的标准化,可访问的灵活性以及完备性不够重视,那么在多个平台的适应性上就需要花费更多的成本和精力去重新设计与开发。