作者：[美]Stephen Hay
出版社：信息技术第一出版分社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
响应式Web设计全流程解析试读：
版权声明
Responsive Design Workflow （ISBN: 9780321887863）
Stephen Hay
Copyright © 2013
Authorized translation from the English language edition published by New Riders.
All rights reserved.
本书中文简体字版由美国New Riders出版公司授权人民邮电出版社出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。
版权所有，侵权必究。序
我不得不说，你正在读的这本书非常棒。
路德维希•维特根斯坦说过一句话，我很喜欢：“我的语言的界限就是我的世界的界限。”这个概念很神奇：这意味着你的词汇量越大，你的视野就越宽广。
我常常会想这句话，还有我的第一份工作。因为回忆过去，我才意识到我的Web设计入门遵循了一条非常狭隘的路，被四个词局限住：发现、设计、开发、发布。我被教导的是，每一个设计项目都被分为这四个独立的步骤。先是调研，然后设计阶段，然后就是编码实现，最后站点上线。简单、直观、线性开发。
开发流程有点像是接力比赛，团队成员必须完成自己的工作，然后其他人才能开始，一个一个传下去直到最终站点上线。当然，现实中有时候会出现一些意外和混乱。但是当我们不要仅为桌面设计站点，还要把我们的设计延伸到越来越多的设备上时，这种老旧的线性工作流程开始暴露出局限性。团队需要更多的合作。调研、设计和开发之间的联系比我们想象中更加紧密，而传统瀑布流的方法将它们割裂开了。
幸运的是，在本书中，Stephen分享了他在这几年的思考，这是一种为Web设计和开发量身定做的响应式设计流程。他引导我们通过一个设计练习来了解新的线框模型，然后给客户展示响应式的设计，这让我们确信，这确实是更好的工作方式。
如果我们的世界的界限是由我们的语言限制的，那么Stephen的书就是一本名副其实的词典，它包含了新的原则和技术，它会颠覆你已有的思考方式，不光使你重新思考设计，还有Web的本质。
这本书会大大扩展你的视野，好好享受吧。Ethan Marcotte
译者序
关于什么是正确的Web设计流程，这个问题没有统一的答案，探其原因，是因为Web设计是一门非常年轻的行业。
十几年前，Web设计是由传统的平面设计师兼职的，在之后十几年变化中，这一职位渐渐分裂为Web设计相关的各个职位，包括用户研究、交互设计、视觉设计、前端开发。这些职位的分割带来了设计流程上的隔阂，每个人成为流水线上的一环，专注于输出自己的“交付物”。交互设计师输出线框图、流程图以及可交互的原型。视觉设计师参考交互设计师的交付物，输出精美的视觉设计稿，如果是响应式设计，需要输出多份设计稿。前端工程师根据视觉设计稿来输出静态页面。
这一现象带来的弊端有：很慢的开发流程，在输出产出物上无谓地浪费了时间；在针对需求变更的时候不能很好地响应变化；在移动浪潮来临的时代因为要输出多份交付物，流程显得更慢；大家的工作方式更像是传统软件公司的流程，而不是互联网公司的流程。
本书作者Stephen对这一现象提出了自己的疑问，并给出了自己亲身实践的一套流程方案。
Stephen鼓励耦合度更高的设计流程：设计团队更加紧密地坐在一起，为同一个项目快速研发。
鼓励关注内容，关注基本内容的可用性，这样能确保在最糟糕的情况下，用户得到的网站也是可用的。
鼓励设计师身兼数职，不再区分交互设计师和视觉设计师，因为现在的交互线框图太具体明确，视觉设计师没有发挥才能的空间。
即使仍然保留交互设计师和视觉设计师的职位区分，也不再输出传统交互线框图，而是使用可迭代的交付物。交互设计师输出HTML页面，视觉设计师可以基于此来工作，避免时间浪费在交付物的输出上。
鼓励设计师学习一些自动化工具，比如简单的HTML和CSS、自动截图脚本、静态服务器等，把自己从无聊的大量输出中解放出来。目标读者
如果你是：
大公司或者小公司中的交互设计师、视觉设计师、前端工程师，并且你希望能改善现有的设计流程，更好地拥抱变化和移动互联网时代。
独立Web开发者，在针对客户的需求变更和响应式的需求时疲于修改，希望能改善流程。
希望能学习更多Web知识的学生。
那么这本书就是为你而写。
对于专注交互和视觉设计师来说，这一创新流程是不小的挑战，因为要跳出自己的舒适区，学习一些技术相关的知识。而对于已经习惯已有流程的同事，要推进新的流程在整个部门的落地势必会遇到很大的阻力。
虽然挑战很大，但随之而来的回报是颇为丰厚的，在移动互联网的时代，谁更快、更能拥抱变化、拥抱多终端设备，谁就能更成功。余果腾讯ISUX高级前端设计师2014年6月8日
译者简介
余果
腾讯高级前端设计师，负责本书的部分翻译和全书的校对工作。有志成为全栈工程师，并积极地利用技术来优化用户体验。
周天牧
前腾讯产品经理，现创业。信仰互联网精神，坚持学习，对产品、技术、设计和商业模式。
陈伟华
前腾讯前端设计师，现居新西兰，是一位自由职业者，正在学习油画。
林钊仕
前腾讯前端工程师，现创业。热爱Web事业，热爱分享。
黄雪莲（snowdrop）
金立前端工程师，常年混迹于互联网。专注技术，捣鼓翻译，热爱跑步，享受在个人局限中无限燃烧自己。
王琨琛
iFLYTEK项目经理，热血青年。喜欢摇滚、足球、机车、马拉松。第1章拥抱变化互联网是个神奇的存在，是个不断变化，并且在创新中见证奇迹的地方。如果你记得最早的互联网长什么样，你会有更深刻的感触。1995年建立的网站和那时的“设计”，在现在来看可能更像一个笑话。某种程度上说，现在网站的设计流程已截然不同，但反过来说，却也丝毫未变。从互联网的伊始，设计师们就在绞尽脑汁将创意落实到浏览器里。最早火起来的互联网设计师是那些爱耍小聪明的家伙，用hacking技巧来帮助自己实现目标。从spacer GIF和表格布局（layout tables）到滑动门（sliding doors）、伪等高布局（faux columns）和图像置换，再到编程框架、CSS预处理器和[1]JavaScript polyfills，他们将设计与网页融合的招儿想了个遍，即使需要把页面内容和无实际含义的表现元素相结合，甚至破坏语义化的Web。时光流逝，不论是上网设备、浏览器还是用户本身，都随整个互联网发生了巨变，但设计流程还基本保持着早期互联网时代的模样，更准确地说，与互联网产生之前一样。1.1精美设计稿的诞生
我以前在传统设计行业工作。那时候刚毕业几个月，我就去了荷兰，花几周时间打遍了周边所有设计公司的电话，通过了其中一家公司的面试并拿到了实习offer。那是1992年，大部分荷兰人在3年后才接触到互联网。我所在的这家小公司有台电脑，我记得是台苹果的Macintosh LC。它只能用来写信或者开发票，唯独不能做 设计，而那时的设计稿都是用昂贵的彩色马克笔手工绘制的。
那时候我们做设计纯靠手绘。就像在学校学过的那样，先画草稿，越多越好，选几幅好的，再画初稿。然后再从初稿里选1到3幅画出成品，因为广告公司都喜欢以量取胜，所以一般都是3幅。在那个年代，负责马克笔渲染的设计师是最牛的。印前工作都是整体或部分外包给专业公司的。而常和电脑打交道的我，很费解为什么电脑在行业里没有被充分利用，但这种情况很快就不一样了。
6个月后我转正了。源于对电脑字体排版的钟爱，我探索出一条路：在公司的Macintosh Quadra 700电脑上（在我开始实习不久后买的）用QuarkXPress创建设计稿，打印出来，并在这个设计稿的基础上做马克笔渲染。这对我们的客户来说有更实际的好处—所见即所得。我认识的其他设计师也纷纷效仿，开始把彩印图片加入设计初稿而非手绘。没过多久我就开始用Photoshop和QuarkXPress在电脑上做完整的设计稿。这期间许多经验告诉我，用电脑做设计很省事儿，只需要在印出的设计稿上用马克笔画阴影就行了。于是我开始用Photoshop完成全部设计，因为这样效果看起来更真实。客户都爱Photoshop渲染，而那些曾经很厉害的马克笔渲染设计师，从此以后就接不到我们的活儿了。
我对这样的工作方式很满意，但当时却没有意识到电脑正在逐渐取代马克笔，我在创造产品而非仅仅实现视觉。不过事后来看，用电脑排版，批量复制样式精美的作品确实节省了时间，也成为了常规的工作方式。当我开始用Photoshop的时候，与其他纯手绘的公司比起来，作品质量确实鹤立鸡群。客户都希望看到他们将得到的是什么，于是我们每次都胜出。最终，大家都选择这么做。
有趣的讨论接踵而至。是否因为我们使用了新的工具就削弱了创意？以往大家的印象是，用马克笔在纸上作画是创意的延伸和实现，而电脑却从某些程度上僵化了这些创意。作为视觉设计的工具，电脑是不是让我们变得缺乏创意？抑或是一个更有效的实现已有创意的工具？整个行业在基础重复性工作上投入大量时间值得么？真的有必要在售前阶段细化如此多的细节吗？
不论如何，事情自然发展着。客户都开始期待优质的精美的静态设计稿。我们的做法是，把打印好的设计稿贴在展板上展示给客户，告诉他们这就是方案。当时我们也没想到更好的办法展示，因为稿子用电脑打印总比马克笔手绘更接近现实。1.2静态设计稿舒适区
在我们做精美的静态设计稿几年后，发生了有趣的事情——互联网诞生了。你可能会期待，这个改变全世界的新事物能否也在设计领域催生什么变化，正如当年电脑帮助设计脱离了纯手工劳动那样。但什么都没发生。我们仍然用Photoshop合成漂亮的产品设计稿，而客户也认可，于是我们就这样继续了多年。
停下来想想，设计界随着电脑的出现产生了天翻地覆的变革。作品变得更真实，它们比以往任何时候都更准确地展示了最终产品的样子。为什么类似的变革没有随着互联网的出现而产生？
我个人的观点是，网上展示出来的东西看起来不够好。早些年里，网页字体不是抗锯齿的，而Photoshop设计稿却能使抗锯齿。所以它看起来更美观，因此也能卖得好。
这种总把网站设计稿处理成漂亮图片的办法带来了麻烦。最后我也厌倦了总是向客户解释，为什么网站上线后看起来总是比设计稿差很多。于是我放弃了抗锯齿化，并且要求我的员工也这么做，因为我不想让客户有这种不愉快的“惊喜”。这么多年来，我们使用图像编辑软件，比如Illustrator或者Photoshop时，一直尽可能坚持真实。与此同时，我们采取两个配套措施：一是多说话，第二是生动、精确地解释我们做出来的网站长啥样。这些策略在很多项目上救了我们的命，但那个时代正在过去。
响应式互联网来得很自然。它不是台式机互联网，不是最新的Safari浏览器互联网或者移动互联网或者iOS互联网，也不是平板电脑互联网。它是不受终端设备和物理限制，所有人都可以访问所有网上信息的终极网络。
现在的互联网设计更具挑战性，正如开发者Jack Archibald所说，现代网站分为文档型网站和交互型网站。设计交互型网站（或者叫Web App），我们不仅要考虑形式和内容，更要考虑人机交互，而用视觉把交互表达好是很难的。1.3专家的入侵
很久以前，每个公司只要一个人就可以完成绝大多数的网页设计，不包括项目管理、后台开发，只包括视觉设计、交互设计和常见的前端开发。
1998年，前端开发主要的工作就是写写HTML，也有些Flash要做。我最早的员工都不知道什么是CSS，还得我来给他们解释。那时候还有很多用CSS做不了的事情，而JavaScript还完全名不见经传。
那时候设计一个网站大概是这样的：在Photoshop里画好设计稿，切图，把它们放回HTML，用Photoshop渲染的内容替换对应的部分，不论这个网站是小的静态宣传站还是CMS的模板站。图1.1 早期的线框比今天常用的线框简单。
当开始系统化、模块化地思考网站的视觉架构时，我们用最简单的线条，称为线框或者图表，来描绘网站。即使文档型网站也有交互方式，而这些特性都需要在设计流程中沟通清楚。图1.2 许多设计师和信息架构师仍然用Jesse James Garrett视觉图表来描述网站结构和交互。
在我的记忆中，从2002年开始，事情有了转折。当项目足够大，网页上的工作量足够复杂时，我们会在一两个前端体验上专业化。许多设计师还在写HTML，而网站图表和线框是信息架构师的工作范畴。像“Jame Garrett的视觉词汇表”这样的工具给了我们一个方法，可以根据基础交互实时查看网站结构。随着交互形式的变化，从客户端和服务器的交互到更小而具体的客户端侧交互，专家们使用了大量细化的线框来展示。这些线框逐渐变成了没有颜色和图片的网页，有时在设计稿里为了客户可以点击，在线框里配上链接可以互相跳转。
不久之后我们意识到，继续做一个全面的网页设计师很难了。网页设计领域诞生了信息架构、交互设计、视觉设计、前端开发等细分子领域，几年后又相继出现了更多子领域，比如每个网站都有强需求的内容运营和时常含糊的用户体验设计。这时，作为交互设计师重要的产出之一，线框已经足够细化，而视觉设计师的职能也相应有略微改变。即使在笔者成文的今天，在很多网站设计和开发公司，许多视觉设计师仍遵循传统瀑布流程，跟随着交互设计师的脚步。这意味着，视觉设计师拿到手的是复杂的线框图，并且是由客户看过并且认可的，没办法改动。这让他们的工作简化成了令人尴尬的“根据编号涂颜色练习”。视觉设计师被要求在线框的基础上做设计——改改字体排版、按网格排整齐、上色并画出图像——基本可以概括为在线框的底子上做点小修饰。图1.3 今天的细化线框毫无想象空间。
在这种情况下，真正的设计工作是由交互设计师完成的，他们才是解决问题的人，而视觉设计师只是按照线条上色罢了。这看上去很不公平，因为不解决问题的设计师仅仅是在做装饰，而做装饰不是设计。1.4我们都是交互设计师
Archibald所说的文档型网站和交互型网站之间的区别并不那么明显，有时候文档型网站也需要有交互性的内容。搜索或者过滤信息、登录或请求文档、填充表单、甚至在网站不同模块之间点击跳转都是由用户不假思索就完成的交互动作。
我认为交互设计师和视觉设计师应该是同一个人。实际上我敢断言，只要是做前端网页相关工作的设计师或者开发者，都可以被称为交互设计师，因为他们工作的某些方面总会影响用户体验。一个优化性能的开发者是在积极地提升用户体验和交互；一个设计师有意用颜色、空间、大小和表单的排列方式也是为了让用户更顺畅地使用网页；而一个内容运营者认为某些内容重要，某些内容不重要，也是在考虑如何提升用户体验。
这并不意味着纯做交互的设计师没有自己的地位，只是想表达，从古至今，视觉设计师一直在解决各种交互的、可读性的、可用性的、美学的问题，没有必要在网页设计领域让他们只做装饰。至少，交互设计、视觉设计和内容运营（也可能还有其他领域）应该比现在有更多的重叠。这需要增加各个步骤间的合作，而不是把现有的每个步骤独立。1.5跳出瀑布模型
我建议用跨职能的迭代方法取代瀑布方法，这样可以让客户体验到整个设计从头到尾的进化过程，绝无可能产生不愉快的“惊喜”。我建议采用重叠的、合并的职能安排，在设计流程内彻底把坑填满。
我期望演进、迭代的设计流程，特性和元素都是根据需求添加的。这个流程基于“小步快跑”原则，从最简单的结构式设计稿开始一步一步迭代到最终的复杂成品。这个流程的特点是，从小开始，慢慢变大。它很杂乱，是因为没有先完成线框然后交给设计师。线框是简单的，它逐渐变成设计，直到变进了浏览器。
互联网给了我们绝好的机会，让我们可以在设计的同时有个媒介来检测结果。别再设计网站的图片了，想想怎么切实在各个方面同时提升用户体验吧。
这本书展示了我在这个创新过程中的尝试。1.6压死骆驼的稻草
对于本书理念的思考开始于四年之前，那时我正在跟进一个客户项目，在Photoshop模板中创建设计。Photoshop模板能表示对应的Web页面和页面中包含的元素。我们需要对这些页面进行清晰的描述才可以做设计稿。我们一般也是这么做的。但在这个项目里，做前端的公司要求每个元素必须在Photoshop文件里精确描述。如果链接是蓝的，那Photoshop模板文件里所有用到这个链接地方都得有所体现。我们不能简单标注下＂链接是蓝色的＂，因为Photoshop模板文件就是他们的文档。好吧这也是一般的做法，但是紧接着一件令我不爽的事发生了，客户反馈需要在段落间添加元数据，并且头部的尺寸要改，虽然这些在当时也很常见。接下来的两天，我所做的只是打开一个Photoshop模板文件，增加所需改动部分的高度，手工移动每一个像素，最终对每个Photoshop模板文件依法炮制。
如果这个项目是个该死的＂响应式＂设计项目会怎样？在100个Photoshop文档上做了相同的操作后（假设每个文档20页，五屏大小），我宁愿像个胎儿一样蜷缩在某个黑暗的角落。
当我意识到两天的工作量用两行CSS代码就能搞定时，我立刻决定再也不用Photoshop做模板了，并开始创造一种全新的、省时省力省脑细胞的工作流程。
2010年我成为了一名独立顾问，可以有机会实践我的新工作流程：客户必须无条件接受我的工作方式。我发现，不论对客户还是对我自己，这种方式效果都很好。并不是说这种方法没有自己的问题（这些问题现在仍然存在），但和瀑布流程相比，它更快、更简单、更有趣，客户也更喜欢看见从结构化内容到成品的整个设计演化流程。另外，无需我多言，他们也能看到并欣赏我们为一份设计稿的诞生所做的努力。1.7屋里的大象
考虑采用全新工作流程的主要原因之一是为了响应式设计。从本质来看，响应式设计让一屏单独的静态页面变得毫无意义。在图像编辑器里创造的图像不是任何浏览器里的页面，更别提种类繁多的浏览器的背后还有更种类繁多的跨平台多视图（见图1.4）。总之在我看来，响应式设计比单独的页面设计高明太多。图1.4 对于因屏幕尺寸不同而变的布局，静态设计稿太费时。
图像编辑器仍是有价值的工具，比如用来编辑图像、组合图片，制造有创意的情绪变化，例如萨曼塔·沃伦发明的Style Tile。Photoshop和其他图像编辑器早已变成了很多设计师的视觉游乐场，用他们来创造静态设计稿太老掉牙了，建议设计师们用一点心思来探索你们的设计工具吧！1.8这并非福音书
直到今天，我仍然使用这个设计流程。虽然它不是一个完美的从头到尾的网站设计开发过程，而且有些地方会有点乱，但它是我认为最理想的视觉设计流程，让内容策略、交互设计、可用性设计与实用性都能有所重叠。
这本书的设计流程已经在项目中实践过了，不可能被一句轻描淡写的“只是对自由职业者有用的小玩意儿，但对我们大型的Web工程毫无意义”所雪藏。因为，本方法的有效性已经在或大或小的项目实际操作中得到过印证。
本书的观点比较中庸，有老的有新的，也有各种观点的糅合。你也许会看到自己的思路，也有可能和其他同样优秀的观点混杂。 书中的工作流程并不是一定是对的或者错的，但它会挑战很多深入人心的工作习惯和思维。1.9这是个挑战
这本书会督促你从不同的角度思考，你怎么设计，用什么工具设计。它会挑战你去学习一些HTML、CSS，甚至在可怕的CMD界面下操作命令行。它会鼓励你跳出固有的思维模式和设计工具，学习一些开发者的工具来释放你更多的精力去思考，更快捷高效的工作，而不是仅仅做一个切图仔。实际上，你会很享受需求变更。呃，当然，只是一定程度的变更。
这本书也记录了两年来的试验、观察、阅读、思索和实际操作。这个工作流程对我有效，但并不意味这里的描述也对你们一样起作用。我邀请你来发现对自己、客户和团队有用的部分。我的希望是，至少书中部分思想可以改变你设计的方式和你对设计的看法。
希望你获得乐趣，不断学习。
[1]JavaScript polyfills指一些浏览器暂不支持的高级CSS或者HTML特性，使用JavaScript实现类似的功能，作用是让使用高级CSS和HTML功能的开发者不用纠结浏览器兼容性问题（译者注）。第2章从内容开始响应式设计的第一步是建立一个内容清单。哪怕你对这个已经很熟悉了，也可以听听看我是怎么处理结构化内容的。你可能会发现我这里的内容清单和你所熟知的迥然不同。一般我们认为“内容为王”。我不太赞同这个观点。设计师Paul Rand将设计描述为“将内容和形式合为一体之道”。Rand的描述印证了我对设计的看法：内容与形式可以相得益彰，也可以格格不入。也就是说，结构化内容可以立足于自身。形式（包括构图、色彩、图像和排版）与内容相结合的设计可以令信息更加通俗易懂，同时使用户界面更加易用。所以，我觉得“（形式与内容相结合的）设计为王”。结构化的内容是很高级别的术语。这里的结构不必（也不应该）以纯可视化的形式展现，而应作为可编辑的元数据存于它所表示的介质中。如同HTML这样的标记语言、或者是文字处理中的结构化元素。结构化内容是语义化的，它描述的是各个部分的内容究竟是什么。“这个是标题”“这个是段落”“这是对应表头的单元格”。HTML虽不完美，却是我们在网络上描述内容最主要的方法。我们试着用语义化的标记语言来描述每一个元素。如果还无法准确描述，我们会使用类、事实标准、微格式这样的HTML属性，以及像RDFa和微数据这些其他的元数据标准。2.1微结构vs.模块化结构
为了方便称呼，我们将文本级别的语义化结构命名为微结构，因为它是网页中最小的元素。对于这样文本级别的微结构，我们无法进一步拆分。比起微结构，还有更高级别的内容结构。我们下面以一个登录表单（见图2.1）为例。图2.1 即使像登录表单这样简单的页面也是由基础的HTML元素组成的。
图2.1中的登录表单是一个由很小的结构化元素组成的结构化元素。有人称之为“模块化组件”。这个表单组件包括了一些基本的HTML元素。● 一个标题● 一个标签和一个用户名输入框● 一个标签和一个密码输入框● 一个用于记录用户登录信息的选项卡● 一个按钮● 一个用于注册和获取遗忘密码的链接
我们做了什么？这个列表就是一个简单的内容清单。记住这里的例子，我们稍后将会回顾。
在网页或网络应用程序的界面上，组件通常由更小的组件或元素组成。在本书中我们更关注于这些组件，而不是构成他们的HTML结构。例如，我们更加关心“主导航栏”组件，而不是组成它的
Jeff Veen曾把内容清单称为“深陷网站中的枯燥漫游”。内容清单一般事无巨细地列出已有的所有内容。但这并不是我们所期望的——太麻烦了。在我们的响应式设计工作流程中，第一步是列出那些页面上必要的东西，而不管它们之前是否存在。对“清单”这个概念，我指的是一个简单的列表。我定义的内容清单并非意在取代传统内容清单，我们只是借用了它的思路，作为设计的起点。
还记得登录表单的内容清单吗？这样的内容清单列出了一个页面上较大并且有意义的组件,这是响应式设计工作流程的第一步。思考一下你想在Photoshop这样的图像编辑器中展示的第一个页面。想想哪些内容组件是你需要在页面上实现的。这是你列表的起点。因为很可能你不是最终在网站放上内容的人，所以最好在设计之前先和内容决策人聊聊。即使你只做设计小样，考虑实际内容也能帮助你产出一个合适的设计。传统内容清单上也可能会列出一些必需的内容，这样就很棒。试着在后续的设计流程中使用一些实际的内容。2.3通用的例子：本书网站
在本书中，我们将使用一个相对简单的项目为例子，来解释和说明响应式设计流程的步骤。本书网站（www.responsivedesignworkflow.com）包含了每个步骤中需要的一切，并且足够简单，不会因为规模较小而有任何含糊。但是，别被表面的简单骗了，我曾把相同的流程成功应用于大型组织的大型项目。一旦你遍历过了每个步骤，你就可以按这里的方法，将各种点子运用在你自己大大小小的项目中。我鼓励大家自己动手尝试一遍创建本书网站的流程；或者你愿意的话，也可以将这些步骤应用于你自己的项目。
每个项目的开始都有特定的目标和理由。本书的网站意在提供一个具体的地方以供集中改进本书，同时它也提供了各种购买本书的途径。另外，这里也是一个勘误、发布相关信息、翻译和其他有用信息的资源库。2.4渐进的设计原则：零界面
在继续之前，我想先阐述一个指导性的设计原则：零界面。几年前，我在大学讲座时引入了这个概念，后来它在我的设计思维中变得不可或缺，我就用它来命名这个原则。
零界面的含义正如其名：完全没有界面。这是一种从用户直达用户所需的信息，所求的结果的交互方式，完全没有任何中间过程。零界面让用户靠“想”在亚马逊下单，想想就能完成。我想要大卫·赛德瑞斯的新书，想想就能完成。我想了解续签我护照的一切信息，想想就能完成。
显然，这种用户界面尚不存在，但这不是重点。在设计过程中怀揣“零界面”的理念，可以帮助我们更好地做决策。
关键是要记住：你对零界面添加任何东西都可能是画蛇添足。它可能让应用崩溃，赶走用户，也可能把信息扭曲，迷惑用户。
如果你把零界面作为设计原则，每次当你试图在网站或者App里加入新元素的时候，无论是一个投影效果，一整个区块甚至一整个功能点，你都会问自己一个相同的问题：谁会用？为什么他们会用？有没有其他更高效的备选方案？它对提升整个网站的整体目标有没有好处？既然理想中的“想想就能完成”现在不可能实现，哪些步骤和元素是帮助用户满足他们最基本需求的必备之选？
例如，设计师们实现某个创意，一般都从最常见的页面样式开始入手。他们一般会先画导航栏。反过来想，你怎么知道你需要导航栏？这个例子并不能表达的特别清晰，因为你基本永远都需要导航，不过仍应该根据需求而非“常识”来做选择。用页脚来举个例子，你真的需要在某个具体的网站上加上页脚么？养成三思而后行的习惯吧，在用常见的设计模式时，更应仔细斟酌。
但现实很骨感，作为设计师或者前端工程师的我们，通常没有足够权力做这些重大决定。一般我们只需要乖乖闭嘴，完成别人要求的任务，就已经非常符合预期了。很不幸，但这就是我们需要面对的现状。这并不是说你需要像无头苍蝇一样一味无脑执行。从内容策划，到视觉设计师，到前端工程师，只要是在整个设计过程中的人，都可以批判性的思考，并把更有效的解决方案抛回给做决定的人。2.5创建内容清单示例
记住，内容清单只是个列表。它可以把各个项目列举，以备后用。再强调下，我们只考虑最本质的功能和内容：我们的清单目标是内容组件，而不是微结构（HTML元素），或者布局区域（header、footer、传说中的“主内容”和“侧边栏”）。
那么本书的网站呢？现在这里只有一个页面。以后它可能会变，也说明了设计的可变性。不论怎样，建立内容清单的过程还是一样的。
这有个初步的清单。
1．标题
2．书籍摘要/描述
3．购买选项和可选版式
4．勘误表
5．出版商信息
不是为了建立而建立详尽无遗的内容清单，仅仅是为了枚举你准备实现的页面数量。每做一个页面的模型，你都得做一遍，而这个例子包含了整个网站，刚好可以一箭双雕。
既然内容清单仅仅是个列表，你就可以用任何格式写：纯文本、表单、脑图或者任何你习惯的方式。然后给每个项目加一点描述信息，就像传统的内容清单那样。注意在下面的例子中，描述信息是与这个特定的网站相关的，所以不能复用到每个图书网站。
1．标题
书的标题不是logo，书的封面可以用特殊字体，但标题和内容应该在印刷排版上一致对待。
2．书籍摘要/描述
这里应该放一张书的图片，也可以来一张图表。
3．购买选项和可选版式
你需要从出版商那里获取更多相关信息。可以从同一出版商的其他书籍网站借鉴基本的格式，这样也有些讨论和提升的空间（见“鼓动性的讨论”）。
4．勘误表
显然，这里会因为书中无误空着。好吧，但也许呢？
5．出版商信息
这里可以包括联系方式，但这部分是否可以变成清单中单独的元素？那是另一个问题，需要和出版商讨论了。
想像一下你和项目编辑讨论了我们的小清单，并且得到了反馈。首先，他说应该包含作者信息，例如简短生平和照片。他也同意单页的想法，以及购买选项可选版式应该与出版商的其他书籍一致，除了价格，你可以作为变量保留。但是，他提到了一点，既然书中讨论了大量软件，包含许多代码样例，页面上应该包含这些软件的链接和必要的代码。另外，不再需要出版商信息了，因为它已经包含在书籍描述部分。
这些都是很有价值的信息，你需要把它们加入内容清单。
1．标题
书的标题不是logo，书的封面可以用特殊字体，但标题和内容应该在印刷排版上一致对待。
2．书籍摘要/描述
这里应该放一张书的图片，也可以来一张图表。它还要展示出版商信息，包括ISBN、页数，等等。
3．购买选项和可选版式
这本书至少会出一份电子版和一份平装纸质版。按钮和链接会把读者带向网站中可购买本书的页面（无论是在出版商的网站还是在亚马逊之类的网站）。同时我们会提供一份样章供下载。
4．资源
这包含了书中分类的，甚至是备注过的资源链接。资源可以是文章、书籍等。提供必要的范例代码下载、demo链接。
5．勘误表
勘误表会在每次再版或者重印时发布，保持内容与最新版本一致。
这些细节目前已经足够了。虽然基于真实内容的设计很重要，但也要记住你在做设计稿，不是网站，所以最微小的细节可以后续完成。没有精确的公式可以决定目前这个阶段必须包含哪些。但普遍的原则是，如果你发现自己卡在内容里没有得到解答的问题上，那你需要补充这些问题的答案。但是如果你沉迷在那些对整体设计影响不大的细节里，那你就该适当删减内容清单，或者把细节另外记录了。
下一节里，我们会开始利用内容清单的帮助，建立响应式线框。
鼓动性的讨论有时候，对于设计稿中需要哪些组件，你只有一个模糊
的想法。这可能是因为你没有了解足够的客户信息，也可能
因为烦人的项目进度要求你在内容最终就绪之前完成设计。
也有可能是，内容已经确定了，但是你对其中最重要的部分
心存疑虑。你可以随便做些文本排版（这些排版也会有用），
但这样很可能导致设计稿与最终结果显著的区别。你得知道
足够多的内容，才能做设计。如果你了解得不够多，可以尝
试补充，或者从其他源头借鉴一些。我并不是在教你直接从
其他网站抄袭内容，我指的是使用他们的基础结构。比如说，
在本书网站上，我记下了我不知道“购买选项和可选版式”
部分应该放那些信息。看完类似网站后，你就会对可能的元
素和结构有个概念。在把这些参考方案放入清单时，你完成
了两件事。1．明确了你没有足够信息。2．开始了一场讨论。如果客户（在本例中是出版商）看见这个内容清单，他
会提供你所需的信息。如果这个信息是无效的，那你需要与
客户沟通，看是否需要对这些有疑问的内容进行改动。如果你的项目中有内容策划，他可能会帮你从客户那里
获取所需信息。永远尽量获取更多真实的内容或者信息，它
会帮你更适当更高效地做设计，并且长久来看可以帮你节省
时间。2.6试试看
看完这章后，你可能会觉得，在自己公司或者团队里实践这个方法有些困难。例如，作为视觉设计师的你，拿到的已经是交互设计师输出的线框图。你“不应该”考虑或质疑内容，因为内容早已为你准备好了。这会最终让你退化成一个“根据编号涂颜色”的装饰者，你会怎么做？如果你愿意尝试新方法，去建立一个内容清单吧，即使“不应该”由你做。这是个很好的练习，可以让你洞察到内容里的漏洞，反馈给团队。最理想的情况是，内容策划、交互设计师、视觉设计师甚至前端工程师都应该参与到建立内容清单的过程中。这本书中重复出现的主题就是，我们不能再孤立地工作了。开发网站不是在流水线上装配汽车，我们应该认识到各种工作的边界是有交叠的，并且以开放包容的心态面对，协同工作。任何让团队在这个方向上前进的举措都是好的。
基础的内容清单相对比较容易制作。很快要开始迭代，就像头脑风暴后的点子列表一样。每个人都从他的专长角度出发思考，第一版的迭代很可能比你想的好。在理想的情况下，内容策略制定者应该参与到每一个设计或者修改过程，保持与客户的沟通以保证所需的信息。
只为后续会被实现为设计稿的页面建立内容清单，如果你会为某个页面做PS设计稿，那么可以考虑为它做一个简历内容清单。
你现在就可以尝试，如果你是视觉设计师，想想你可能设计的页面并按照这节的内容建立一个简单的内容清单试试。
如果你是工程师并且刚拿到最近某个项目的设计稿，仔细看看，思考下它是否有意义，看看你能否为逆向工程做出内容清单。如果你是个设计师，看看你能否用给你的线框图做出一样的设计。试着辨识出主要的页面内容组件并分析这样的线框图和设计哪里把握得好，哪里不好。
如果你是个交互设计师，你应该建立内容清单，为每个组件添加交互说明，描述交互动作和为视觉设计师和工程师们考虑的其他潜在可能性。把那错综复杂的线框图丢在家里吧，它们太过时了，现在老线框图又回来了。第3章内容参考线框图在早期的网页设计中，线框图（或者叫示意图）只是简单的一些框，来表示页面上组件应该怎么摆放。线框图是设计稿的上游环节，通过快速对产品设计进行填充内容，来让我们对网站的主要结构有所认识。而现在的线框图却过分注重细节，他们一般都包含了真正的内容。有些看起来已经是基本完成了的网站，只是少了颜色、图片和字体。布局已经完成，放什么内容，怎么摆放都已经决定。在我看来，现在的线框图很奇怪，并且限制性太强（见图3.1）。创建线框图的人（大部分情况下是交互设计师）已经做了大部分的视觉设计的工作。视觉设计师拿到这些交互图的时候，经常会被告知交互图并不代表最终的设计。但是客户可不这么想。曾经有一个客户问我是不是不了解这个项目，因为我设计的样子跟几个月前他看到的线框图不一样。最后，他要求我使用最初的线框图作为基础框架。这种令人沮丧的事情发生了好几次，我再也不相信“这不是最终设计”这种声明会管用了。它并不代表最终的设计，但是很有可能客户真的非常喜欢它。如果线框图代表了设计，那它就是设计，而不是线框图。如果它不代表设计，那我们为什么还加入那么多细节？图3.1 有一些线框图看起来像已经完成了的页面，这让设计师的工作简化为“填色练习”。线框图的真正问题不是你是否声明“这不代表最终设计”，而是客户总会看见它。如果线框图只用于团队沟通，那么想怎样声明都行。但是就我之前提到的经验，当你把它展示给一个客户，就是在展示一个设计。客户会根据他看到的而有所期待。但有的时候，我也会遇到截然相反的情况：不止一次客户和交互设计师否定了我的设计，因为它看起来太像线框图。这让我如何是好？假如交互设计师确实已经提出了最好的方案呢？设计稿太像线框图会被挑战，而设计稿不像线框图同样会被挑战，这真是糟糕！3.1别把线框图复杂化
我猜，细节线框图是为了应对客户总在设计到了视觉设计阶段再大改需求而诞生的。这也合乎逻辑，因为改动视觉设计成本相当之高。
我喜欢把那些老派的线框图称作参考内容的线框图。我之所以喜欢这个名字，是因为它描述了线框图如何处理内容：它们只是引用它，而不是描述它。在响应式的工作流中，每一步都基于同一个思路：第一步包括了简单的内容列表。这个步骤中涉及制作简单的线框图，无非是一些涉及相关细节的内容框。
在本书中，我建议不要把太多责任都推到线框图身上。我们就用它处理可视化内容的位置、确定不同屏幕间的相对重要性的工作。我们把有关于布局与交互的选择放到后面适当的阶段。在本书中规定的工作流中，低保真的线框图最终将演变成可以研究、测试、修订并且得到客户认可的高保真设计。图3.2 参考内容的线框图是最小化用于参照内容的，而非描述它。请注意，我对线框图的意见只是基于我个人不喜欢细节
线框图，以及我对它们在网络工程中实用性的怀疑。我并不
反对交互设计师或其他什么人使用它们。我并不喜欢交互设
计本身。不过我认为，所有前端设计的规则与交互设计是相
互重叠的，因为大多数前端决定影响网站的交互。很多决定
都是在线框图完成并且获批准后才做出的。我也相信研究并
修改交互最好是在浏览器中使用实际的设计，而非静态的线
框图。这里我指的不是笨重的、可点击的线框图，而是高保
真的设计。这在本书中描述的工作流程中是可能的。3.2第一步：创建低保真的、基于网络的设计稿
我要求你做的第一件事就是，忘记你用来创建线框图的小应用，文本编辑器除外。我们将用文本编辑器、HTML、CSS和浏览器来创建低保真线框图。别担心，这很简单。
对于本书网站，内容参考的线框图比较好做，不仅是因为内容的单一，而更是因为我们从结构化内容开始。
目前我们只是在为网站布局打草稿，所以用线性布局就好。3.2.1 创建基础HTML
刚开始，你需要一个基本的HTML文档。我假设你对HTML有一些了解，并且可以把我的样例活学活用，变成自己的模板。如果你没有HTML经验，可能需要复制下面的代码，或者手打更好。打开你的文档编辑器，创建一个基本的模板HTML文档，就像下面这个。
接下来，看看你的内容清单并对内容优先级排序。假设浏览屏幕很窄小，用户不得不用线性方式查看内容（这种情况非常常见）。哪些内容最重要，一定要放在顶部？那些内容不那么重要，可以往后放？
另一种思考方式是：想象你的任务是把这些内容变成印刷品，比如说一本书。你的内容清单需要分模块。很多模块需要标题，其中可能有些还有子模块，子模块也有自己的标题。你如何把这些内容排序？哪些放最前面，哪些放最后？
让我们再看看本书网站的内容清单。
1．标题
2．提纲/描述
3．购买选项和规格
4．资源
5．勘误表
这很简单，看起来符合逻辑，顺序也是按重要程度排列。我们继续往下看。
上文提到要协同工作。线性顺序内容是需要由所有相关人员参与讨论的，包括视觉设计师、内容策划、交互设计师和客户，都应有思考和价值输入。
下一步需要在HTML文档里创建容器元素，按刚才决定好的顺序展示清单中的内容。在本书网站中，我们把这些元素放在body里。
id属性是可选的，但当你的线框图进化成一个更细化的设计时，它可以让你更轻松地读懂自己的代码。id属性标识出了代码中的各个元素，所以虽然是可选，但完全有必要。
如果使用像OmniGraffle或者Photoshop这样的软件，你完全可以不需要任何HTML。所以除了一些HTML代码在语义上可以发挥些微作用之外，线框图代码的重要性体现在，你可以把它作为后续产品的基础。如果你是这么打算的，还是沿袭你正常的编码习惯，只要这样是有益的。
如果你保存HTML文档并在浏览器里打开，你什么也看不到，因为我们还没有添加任何文本内容。现在我们给这些模块加上标题并编号，这样可以让我们更好地查看页面，并且看线框图中的各个模块与内容清单如何对应。
现在再看文档，你会发现内容清单以HTML头部的形式展示在页面（见图3.3）。图3.3 每个模块的标题依次渲染在浏览器中。
接下来，我们需要给线框图添加一些样式。为了更清爽，我们给body元素添加特殊的类属性，等线框图成为设计后再去除。
这可以确保你给线框图写的CSS规则不会应用到设计里。3.2.2 形成基本样式
创建一个基本CSS，无论视口宽度如何，这个样式总是需要加载。命名为base.css并放在HTML文档同一目录下，或者放在“style”、“CSS”之类的子文件夹。如果你是开发者，沿用你自己的命名习惯就好，但要注意，这里的例子假定了在HTML文档所在目录下有个“style”文件夹。
在文本编辑器里打开base.css，给body一个背景色。
然后，给线框图的各个模块加点样式。这些样式纯粹为了线框图，主要用来决定区块如何展示。你可以选定边框（borders）、背景（background）或二者的结合，记得保持简洁。这有个例子（见图3.4），但你也可以自由发挥。图3.4 应用了线框样式的模块标题。
在这我用了CSS颜色名，你当然也可以用任何你喜欢的颜色。当且仅当body元素里有线框图这一类时，这些样式才会被应用在各个模块上，而且仅仅是线框图阶段才会出现。这就是为什么我们要设定字体的原因：在线框图进化为完整设计设计时，确保线框样式和新添加的样式不冲突。
将样式表与HTML文档关联，就可以在浏览器中查看文档的样子。
现在在浏览器中打开文件。我们就快搞定了，但还需要一些微调。这些标题看起来很大、很暗，而且还是左对齐。我觉得把文字居中可能更易读，尤其是一扫而过式的。这里稍微做些修改：
我使用small作为字体大小而非具体单位（比如px或者em）的原因是，在这里我仅仅想要文本显示的小些，small这样的关键词可以不假思索地使用。这种线框图的关键在于，越快越好，细节还并不重要。
接下来，加上页边边距（margin），并且去除body里默认的内边距（padding）和页边距。图3.5 完成了线框样式的模块标题。
这样看起来还不错（见图3.5）。根据你自己的代码，你可能需要添加或者去除某些样式，比如说如果你选择不用边框，可以给各个模块添加衬垫。
整个简历线框图基本文档的过程仅需要几分钟。完成过一次之后，你可以在每个项目的建立阶段用同样的方法，几乎立刻就可以跑起来。
请注意，这些是我一步一步的教的，非常基础的CSS，即使是新人也很容易上手。现在你有了一个线性的、宽度可调节的线框图，并且可以在浏览器甚至移动设备上打开展示。3.2.3 移动优先版线框图
如果可以的话，要么把你的文件放在Web服务器上，用智能手机打开浏览器，要么用手机模拟器打开。如果条件允许，尽量用真实的移动设备测试网页文件（对，即使是线框图）。如果以上你都做不到，可以把浏览器窗口调小点，但这是个不怎么样的替代方案。
你会看到你的线框图：一个按固定顺序排列的内容列表，页面上每个区块展示了一个内容模块。各个区块的高度是由区块内标题的尺寸所决定，这很不现实。
聚焦回线框图线性的外观上，包括在手机端，尝试粗略评估你希望各个模块有多长。评估的准确与否并不重要，因为我们明白默认高度并不合适，所以只需要做很粗略的评估，并在各个模块加上对应的样式来体现。我们会用ID来定位具体的模块，并继续在wireframe命名空间内优化线框图类名来避免冲突。
有一种办法可以互动地调整这些值，用浏览器的开发者工具在浏览器里调整CSS，等你感觉高度差不多了，把这时的值写进CSS即可。
再回来看看这时的浏览器。高度的数值可能相差甚远，但感觉起来更真实，因为各个模块占空间最多的部分是内容而非标题，而内容本来就具备很大差异性。我们发现又回到了内容上，你在问关于内容的问题，思考内容对形式的影响。如果你在设计一个Web应用（与信息类网站对应，比如本书的范例网站），你会思考UI元素的相对尺寸和你能在屏幕上放多少内容的问题。也许，你会由此发现滚动窗口或者分屏都是可选的设计方案。图3.6 估计各个内容模块的高度，让你快速看到添加实际内容后大概是什么样。
实际上，在这最初的几个变化后，你可能已经意识到我们现有线框图的第一个问题：线性格式下，想看到底部部分必须一直滚动到底（比如购书网站），因为我们忘记加导航啦！3.2.4 添加导航
小屏幕上的导航很有挑战，因为有很多情况要考虑。如果我们仅仅简单在页头标题或者logo下添加导航，可能会占用过多垂直空间导致首屏除了菜单没有空间展示更多内容。有些开发者通过JavaScript收缩菜单项来解决问题，但它需要支持JavaScript的环境。我更偏爱的方法是在页面底部添加导航，然后在页头放置菜单的链接或者按钮，让用户点击后跳去底部菜单。这在支持JavaScript的环境下可以提升用户体验：导航放到顶部并收缩，等用户点击或者触摸菜单链接，才下到底部菜单展示菜单项。
在这个阶段考虑导航貌似和保持简洁的原则冲突，但其实很有用处。你可以看到在响应式设计的线框图中，导航如何随着不同屏幕宽度而变。
导航包含了交互动作，这是很好的契机，交互设计师、视觉设计师和前端开发者可以一起思考不同设计方案优劣。这对于把方案决策的过程给客户同步也有帮助。在把完整的线框图展示给客户时，刚好可以说明和演示这些思考。这是在设计过程的早期。
让我们来实现底部导航范式。如果我们决定后续使用其他的导航模型，也可以快速更改，只需要很快地改动CSS。
首先，我们在内容模块后添加一个导航模块。
然后为导航添加链接。我们把它添加到模块以外，在page所对应的div根目录下。
我们也给导航加上与内容模块相同的样式。
然后添加规则，把菜单链接放到页面的右上角。
现在在线性线框图的基础上，右上角有了链接。点击后会跳转至底部的导航模块（见图3.7）。我们可以给导航模块一个高度值。图3.7 在小屏幕上，顶部链接跳至底部导航很常见。
又一次，我们在猜测。尽管小屏幕可以有更丰富的布局样式，但
试读结束[说明：试读内容隐藏了图片]