响应式 Web 设计指南「实践篇」

无论你是奔赴战场、跑马拉松，还是构建一个响应式的站点，准备工作都是关键。

创建一个响应式的站点意味着要考虑多样化的设备生态系统。

如果没有适当的准备，你将发现自己会因为缺少必要的部分而忙里忙外，并且站点的质量也将受到很大的影响。

考虑的因素

作为任何响应式项目的第一步，都应该是确定投资这个项目是否有意义。在你做决定之前，这里有一些值得思考的因素。

如果其中有任何一项造成了严重的障碍，那么也许你应该选择一个非响应式的实现，至少目前来说是这样。

性能

与有线网络相比，移动网络正遭受着显著增加的延迟和显著减少的带宽。即使在小屏幕上隐藏了内容，但是标签和CSS依然会被下载。

性能是用户体验中固有的一部分。如果你并不关心如何构建站点，那么最终这将导致一个异常臃肿而缓慢的站点。

使用环境

你的站点的用户体验会根据使用环境的不同而不同。不同的设备可以在不同的环境下完成不同的任务。

相反，一个能够在多种设备上表现一致的新站点可以运行的非常好，是因为其体验并不依赖于大量的使用环境。

内容协商

也许你会选择去重新组织或者重构站点的内容。比方说有一个页面有一个内容栏和一个边栏，如果你将布局变为单独一栏，那么边栏就会被挤到整个内容栏的下面。

很多时候，边栏的内容也许远远要比内容栏底部的内容重要。所以如果你不重新规划内容的顺序，那么页面的层级划分就会消失。

时间投入

相比非响应式的方法而言，响应式的方法通常都需要更多的前期时间投入。

因为你要考虑大量的具有不同能力的设备，还需要去观察目前已经存在了哪些设备，以及一些特殊设备如何与之交互。

这些时间并没有被浪费，在项目开始时失去的时间很可能会在维护成本中得到弥补。

如果你有时间投身到创建一个高质量的站点中去，那么你应该响应式地好好思考一下。

支持

从桌面端向下构建响应式站点，正如它在大部分情况下所实现的那样，会在很多移动设备上造成问题。

取而代之，如果你选择渐进增强的方式，那么就可以避免这些问题。首先为能力最弱的浏览器编码，然后再使用媒介查询来逐渐增强体验。

首先为能力最弱的浏览器构建站点是最明智的选择，但也不能保证更流行的设备就一定比目前的设备有更强的能力。

结论

无论当前我们的工具及心态有着怎样的局限，请不要忽视响应式设计的潜能。

一旦你已经认定了响应式方法对于你的项目来说是合适的，那么你就要考虑如何来实现它。

当我们能认真的使用它，并能将其与正确的技术结合在一起时，一个响应式的方法才可以作为大部分站点的起点。

响应式设计流程

如果你往水里扔了一颗石子儿，那它便会激起一连串扩散的涟漪，虽然撞击点很小，但影响波及甚远。

如果把我们现有的工作流程比作是水，那么响应式设计就是那颗石头，而那一圈不断扩散着的涟漪，影响着一同工作的方方面面。

可交互媒介

是时候转变一下 “Web是一种静态的媒介” 的观念了。Web是灵活的、不可预测的，因此固执地使用固定的工作流程和静态的可交付成果并不能帮助我们挖掘Web的潜能。

不要用那些其实并不存在的限制来约束我们自己，我们的工具、技术以及可交付成果应该更好地反映出Web的这一动态特性。

协作

传统的网页设计流程都是线性的，首先由设计师创建设计稿，一旦通过后便将其转换为几个静态的线框图，最后交给开发者去实现。

而在一个响应式项目中，由于你关注的是如何为大量不同的设备服务，工作流程无疑会变得更加复杂。

你不能期望设计师能预料每一种可能出现的情况，你也不能期望开发者能百分之百地与设计师设计的每个交互都保持同步，因此我们需要一种更高层次的合作。

如果在设计过程中，设计师和开发者能一起紧密地工作，那么开发者就能指出其他可能的情景，考虑就会更加周全。

沟通

从项目启动开始，设计师和开发者就应当参与进来。

通过及早地让设计师和开发者参与进来，可以确保页面与交互之间的一致性，而开发者则可以在发现潜在问题之前，就将它们指出来。

不同于简单的手手相传，一种更具协作性的工作流程能使得设计大纲更加成功。

在设计大纲中，应该安排站点在尽可能多的设备上进行测试。因为这样可以对设计中的任何瑕疵都予以指出，并可以暗示你应该做出哪些调整来为给定的设备做优化。

迭代

理想情况下，每次迭代只需要做出很细微的调整，因为对于体验的轻微调整会相对容易。

这听起来也许非常耗时，的确是这样，但这对于确保最终的产品能够给用户带来舒适的体验，也是至关重要的一步。

尊重

如果项目中设计师和开发者之间缺乏彼此尊重，那么整个过程也会失败。

我们会凭借已有的一点知识走很长的一段路。尊重，正如它所表现出来的那样，你很难将它给予那些你不了解的事物。

如果你是一个设计师，那么就去花点时间在编程上，这将使你更加深入地了解开发者们的工作。

同样，作为一名开发者则要去探索一下那些设计概念，这样可以帮你意识到设计远远不只是漂亮的颜色和字体。

与客户协作

协作不应该仅限于内部，它也同样应该扩展到你与客户的来往当中。让客户尽早地加入进来，并且从始至终都要让他们成为项目中的一部分。

如果在整个过程中都能让客户参与进来的话，那么你们之间的关系就会变成一种团队合作。客户与设计团队之间的那堵墙便轰然倒塌了，双方的意见都可以被对方听到，而且每一项提出的解决方案都会有来自双方的贡献。

系统方式思考

一个站点需要有一致性，不但包括页面与页面之间，而且还包括设备与设备之间。

要想获得一致性，就需要以系统的方式来思考问题。通过考虑单独的组件，可以将它们从页面中解耦，并迫使我们思考这些组件应该如何一同工作。

先考虑站点中单独的组在不同的环境中要如何运行，然后考虑这些组件如何能统一地创建出一种广阔的体验，这些对于任何响应式项目的成功都至关重要。

优先考虑手机

手机在爆炸式地增长：

　　随着设备数目的激增，越来越多的人们开始只使用移动设备来访问互联网。在有些国家移动平台已经占据了主导地位，因此优先考虑移动平台是很有意义的一件事。

手机迫使你专注：

　　移动设备大都只有一个很小的屏幕，这意味着能往里面填充的内容很有限。优先为手机设计可以迫使你专注于弄清楚哪些内容是最重要的。

手机丰富的能力：

　　移动设备开始加装越来越多的传感器，虽然目前还不能从浏览器中访问到，但放眼未来，我们可以利用这些传感器创建出更好的体验。

线框图

如果从一开始就创建一个高保真度的原型，那么要从完成的设计中看出之前的颜色或样式将会变得非常困难。但是如果能从创建一个低保真度的线框图开始，那么一切就会变得很容易。

通常情况下，线框图不会包含颜色、字体或者图片。画线框图的目的并不是为了演示站点布局，而是为了帮助确定页面结构，其中包括将会显示什么类型的内容，以及这些内容有着怎样的优先级。

要尽可能地让你的线框图保持简单。线框图的保真度越高，你遇到的阻力也就越大，线框图的保真度越低就越容易让人专注于页面的结构、层次和行为。

模型

是时候放弃“像素级精确控制”的那种渴望了。不完美是件好事，不完美能催生各种特质并带来可塑性。

静态模型存在着大量的问题，对于设计最终将会如何呈现，它只能给出非常有限的预测。

在浏览器里设计能够更好地演示当用户与页面上的元素交互时所发生的一切，另一个好处是可以让我们专注于内容和结构。

对于许多设计师来说，在代码中工作让他们失去了创新和试验的能力。不过在理想的工具出行之前，最重要的是学会放弃对图像编辑软件的依赖。

样式向导

为了能够对整个项目有所帮助，你需要创建视觉样式向导以及相应的模式库。

这样做不但可以确保站点可以维持一个统一的视觉外观，而且代码也能维持统一的样式，这在很大程度上简化了后期的维护。

一份良好的视觉参考除了要包含站点内各个元素的样式之外，样式向导还应该提供特定的元素要在什么时候以及如何被使用的信息。

样式向导正变得越来越流行，其中最为著名的就是 Twitter 的 Bootstrap。有了这样一份资源，即使对于新手开发者来说，快速开展工作也会成为一件容易的事。