译者序：当我看到这篇文章的时候，还好发布的时间不算太早，主题很对我的胃口，因为我的Blog已经这么做了。但这篇总结的很全面，提到了一个新的名词“响应式Web设计”，作为Web内容应该去更加灵活的呈现在不同的终端上。这让我想起了之前写的一篇文章《未来我们只需要浏览器》，随着智能手机和各种Pad的发展，内容终端终究会发生改变，Web展现需要去适应这种趋势，并带来优秀的阅读体验。

响 应式Web设计是在开发和设计网站过程中产生的一种方式，它的目的是让内容布局能随用户使用显示器的不同而变化。再明确点说，这种设计概念，就是让原本1292像素宽，4栏的内容，能够很好地显示在1025像素宽的用户屏幕上，同时还能自动简化成2栏。当然，让它很好的适应智能手机和其他种类电脑的屏幕也就成了水到渠成的事了。这种特殊的设计形式就被成为“响应式Web设计”。

响应式Web设计与传统的设计方式截然不同，开发人员（特别是新手）必须要理解它的优势和弊端。这篇文章正是为大家揭示一些实例的。（这里介绍一个叫“Media Queries”的网站，里面介绍了更多实例和演示）

数据表格是响应式Web设计的经典使用情景，实现它的想法与传统的设计理念有很大不同。数据表格默认很宽，当你要查看它全貌时，你得缩小表格，但这时字会变 的很小，很难去阅读。然而当你想看清楚上面的字时，就不得不再把表格放大，这时要查看完整表格就得横滚加纵滚。这么阅读表格也太KB了。或许重新格式化表格或以饼图形式展现是种解决方案。再不然，你可以弄一个迷你图，即使在窄屏幕里它也能适应。

响应式Web设计中的图像以流式图像为主，可以被上下文感知的图像所替代，这是一种更好的设计方式。这种技术的真正意义在于，能够让图像适应不同的屏幕分辨率，更大的或更小的。所以它与传统设计的理念和技术都有很大不同，合理使用会让你的网页化腐朽为神奇。

响应式Web设计实例

Simon Collison

Andersson-Wise Architects

Stephen Caver

Sparkbox

Food Sense

The Boston Globe

Think Vitamin

Sasquatch! Music Festival

Internet Images

Staffanstorp

Seminal Responsive Web Design Example

Naomi Atkinson

Forefathers Group

Spigot Design

New Adventures In Web Design Conference 2012

Illy Issimo

Arrrrcamp Conference

Robot or Not?

Earth Hour

Clean Air Commute Challenge

Launch Kit

Teixidó

Ribot

Deren Keskin

Sweet Hat Club

Glitch

dConstruct 2011

Adaptive Web Design

Authentic Jobs

Five Simple Steps

Splendid

Ryan O’Rourke

FlexSlider

El Sendero del Cacao

Do Lectures

St Paul’s School

Naomi Atkinson Design

Ben Handzo Photography

Stunning CSS3 Media Queries Example

Nordic Ruby Conference

Halifax Game Jam

ASU Online

3200 Tigres

Pixelab

Kings Hill Cars

8 Faces

Asbury Agile

Alsacréations

Sleepstreet

相关文章

1. 德国之旅-奥地利萨尔茨堡
2. 德国之旅-新天鹅堡
3. 德国之旅-纽伦堡
4. 德国之旅-法兰克福
5. 德国之旅-贝希特斯加登

这篇文章记录了Nearby Tweets改版的完整设计过程。Web开发者和商家期望借此获取些灵感。用户则更有兴趣找寻这些设计中所蕴藏的东西。当然，我希望能在文章结尾了解到你的想法和反馈！OK，我们开始吧。

故事的起因是这样地…

这一切开始于对Nearby Tweets的第一次迭代，目的是让当地的人与人、商家与商家之间能够通过一种简单的形式相互取得联系。

但产品开发向来不可能十全十美，只有不断迭代——产品好坏取决于用户认可。因此，借Uservoice的机会得尽我所能快地跟用户接触。通过Uservoice，用户可以针对Nearby Tweets的改版进行投票。

Nearby Tweets用户的主要需求

1. 默认地区
2. 保存关键字和地点
3. 令人懊恼的“抽屉”
4. 目录手册
5. 移动版本
6. tweets自动刷新
7. 屏蔽用户
8. 屏蔽地区
9. follow特性

选择哪些功能实现

尽管所有用户的请求都合理，但我得根据自己的资源和日程情况安排哪些可以实现。

移动版本要再往后排了
现在已经有web版了，所以对移动版持观望态度。因为需要更多资源和新一轮考虑，暂时没有精力。

目录手册也要往后排
市面上已经充斥了大量的Twitter目录手册应用。我的发展空间并不大，但在自动匹配地理位置领域，一直都是我的，现在是，将来也是。(参见 Twellow, WeFollow, 和 just tweet it)

其余的功能，一个个来
其余的功能需求都在我的日程上，在开始UI设计之前，我得把它们再梳理清晰一些。

缩小设计范围

为保持自己的路线，我为Nearby Tweets拟定了3个改版必备条件：

1. 获取用户反馈。在得到少量用户反馈后我迅速发布了Nearby Tweets的第一个版本，用这个有趣、有用的项目小试牛刀。通过这次改版我希望在设计过程中尽可能多地获取用户反馈。利用 Twitter，Uservoice等资源，进行私测和公测。
2. 把Nearby Tweets打造的更健壮。尽管焦点是第 一版的优势，但还是没有扩展的基础功能。这次Nearby Tweets将为用户偏好提供核心功能，以及高级搜索。
3. 保持 Nearby Tweets的简单。一直以来，我们努力保持Nearby Tweets的简单，并使它的体验更简化。

接下来，我制定了设计目标

允许用户随意查看Nearby Tweets，当需要时也允许他们调整。

将概念转化为UI设计
为保持Nearby Tweets的简洁，我拟定了2套UI设计概念：“Progressive disclosure” 和 “lazy registration”
在UI设计上实施Progressive disclosure

Progressive disclosure主张把高级和不常用的功能放在第二屏（不显眼的地方），使应用看起来简单易用，且不易出错——Jakob Nielsen

需要指出的是，第二屏可以被理解为把功能隐藏起来。

Tweet设置

对每条tweet来说，“谁说了什么”和“是谁说的”才是重点，所以我保持tweet表现成这个样子。

然而，用户还有其他需求，他们要求可以关注某人、屏蔽某人，甚至屏蔽地区。像这种高级功能就不能塞满tweet区域。Progressive disclosure的思想派上用场了。当用户把鼠标移动到每条tweet上时，上述3个功能才显示出来。就像这样：

地区和关键字的修改窗口

一个初次访问Nearby Tweets的用户也就是四处看看。所以在首页里只显示“Tweets nearby xxxxx about yyyyy.”就已经足够了。

但当用户想要搜索已经新地区和新关键字时怎么办？你会发现地区和关键字看上去像是可点的链接。当用户想修改这些信息时，点链接后会出现一个弹出层。

与其让用户看到搜索框及其他一堆筛选条件，不知所措，还不如只给个“Change”按钮，目的明确。点击按钮后进行下一步操作。实际整个区域都是可点的， 目的是为了增加用户的可点区域。

你会注意在地区弹出层里有个名叫“use the map”的按钮。在UI里设置地图有两个目的：一来，给用户位置感；二来通过Progressive disclosure提供高级搜索功能。

地区搜索利用交互地图完成

初窥地图会发现它就在Nearby Tweets的后面，营造了一个用户地区的虚拟环境，将tweet作为搜索结果不断滚动显示。

当用户搜索地区时，Nearby Tweets闪到一旁，地图就成主窗口了。这样做可以在地图不用时，巧妙地将它当作Nearby Tweets的背景，需要时再将其呼出。

用户偏好

作为Progressive disclosure的经典示范，用户可以添加保存地区、关键字，甚至更多偏好设置，目的都是让Nearby Tweets变的更好用。提高用户偏好，让我们看看它是怎么运作的。

UI中的Lazy registration
一个用户可能从不碰偏好设置，但仍能体会所有优点。要怎么做？Lazy registration是一种 growing UI trend ，它能读取用户之前的数据，自动完成已知信息的填写。

被动偏好
虽然Nearby Tweets不用注册，但它同样有一个偏好设置页面供用户配置。其中“lazy”这部分抽取的是用户喜好的集合。

• 用户每次切换地区后，都会被自动保存
• 用户每次搜索关键字后，都会被自动保存
• 主UI允许用户屏蔽某人 或某地区

默认地区
虽然用户可以设置默认地区，但通常都没必要。Nearby Tweets能自动获取用户地区信息，根本不需要用户动手，除非他想自定义。

处理用户需求

默认地区
Nearby Tweets也不是总能找到用户的位置，所以有时也需要手动覆盖掉默认地区。我想过很多方法解决这个问题，比如增加个“set to default”的选项在每个已保存地区旁边，但这可能会多出来很多链接，让界面变得冗余。

我决定在用户偏好中保留“设置成默认”这个功能。在那我用空间来展示这个选项。每个已保存的地区都可以被设置成“默认地区”。如图：

已保存的关键字和地区
我用“当前的”替代“已保存的”是因为它更贴切。关键字和地区的保存像是书签，但工作原理像浏览器历史。

Tweets的自动滚动
在控制新tweets刷新频率时有些困难。我很矛盾：如果太慢，会有用户觉得Nearby Tweets是不是没在工作；但太快，用户又没法阅读，过犹不及。在经过一些用户的测试后我发现，3秒这个速度正好。

并非每个人的阅读速度都一样，自动刷新频率可以当作用户偏好。据分析，除了3秒外，30秒、10秒、5秒和1秒也都很常见。

屏蔽用户

屏蔽地区
如何屏蔽地区又是个难题，因为要去比较tweet所在的地区与被屏蔽的地区。问题在于当用户屏蔽了“俄亥俄 州哥伦布市”，但发布者的地区是“哥伦布”。虽然人可能清晰辨别这两个是同一地区，但在电脑里，“俄亥俄州哥伦布市”并不等于“哥伦布”。

接下来如果我假设用户只想屏蔽精确匹配“俄亥俄州哥伦布市” 的地区，或者所有在“哥伦布”发布的tweets？为了使软件智能化，我让程序能够自动匹配城市名。然而，另一问题接踵而至，如果两个地区拥有同样的城市 名，就像“俄亥俄州哥伦布市” 和“佐治亚哥伦布”。那么，所有“佐治亚哥伦布”的用户想屏蔽来自“俄亥俄州哥伦布市” 的tweets时，就会屏蔽掉所有名为“哥伦布”的地区。如果它已经成为一个问题，我想我不得不竖起耳朵，听取用户的声音。

关注功能

相关文章

1. 在Google上看书
2. 一个提高了近10%转化率的改进
3. 开发iPhone版校友录
4. 可用性工程的生命周期
5. 10条可用性方面的启发

似乎性能优化永远都是属于门户网站的事儿，与咱们小民无关？！
这种想法在网络技术高速发展的今天，似乎有点落伍了。如果你是专业从事互联网的技术人员，甚至是负责优化公司网站的专家，自己的小站也别忘记适当地优化一下.

好像只有雅虎的人平时谈论这个问题比较多,是因为雅虎发明了YSlow和一套检验网站性能的机制?如果你使用的是Firefox,可以安装YSlow,来查看自己网站的性能,根据提示进行优化.总结一下,作为个站,可以做的优化工作大概这么几个:

1. 使用更少的HTTP请求;
2. 使用CDN
3. 把CSS放在页面顶部(放<head>里)
4. 把JS放在页面底部(紧跟着放</body>前就行)

这是最基本地,3,4条最容易做到.第1条,多半是由于你的blog皮肤样式里使用了很多图片,建议采用CSS Sprites把像icon这类的小图片合并在一个图片里,通过CSS控制背景位置来调用不同icon,这样只需要发送一次HTTP请求,取一张图片回来就搞定了.

这里我主要来解决第2条–”使用CDN”的问题(先了解一下CDN是什么).Google真是个好东西,总能提供一些很实用的服务.我的CDN就是利用Google App Engine来搭建的.首先做一些准备活动,需要安装一些小程序到你的电脑上,配置一些文件,但这些工作只需要做一次,之后使用时只需要运行一下程序,就可以把文件同步到Google了.

简单描述下工作原理.SVN用过吧?这个类似.
建立一个文件夹,里面放你的文件和文件夹,修改一个配置文件,把里面的application name改成你自己的.
通过Google App Engine SDK同步你的这个文件夹到Google服务器上.类似SVN的update或check in.

我是在Mac下工作的,先说说在Mac下怎么做:

1. Google App Engine是基于Python的,Mac和Linux的用户不用装,系统本身就支持.
2. 下载Mac版的Google App Engine SDK并安装,都使用默认安装就可以了.
3. 在appengine.google.com登录.当然你要先有Google帐号,用你的Gmail帐号就行了,如果没有注册一个也不麻烦.
4. 登录以后,先点击”Create an Application”创建一个application,并给它取个名字.它必须是唯一且没被使用过的,所以我起的叫”b3insidecdn”,既不重复又好记.然后保存.第一次创建application时需要输入你的手机号码(形如:+8613800138000),用于接收Google发的确认短信,确认你是Google App Engine帐号的主人.同时也为了防止spam,呵呵.
5. 下载这个文件: http://b3insidecdn.appspot.com/files/b3insidecdn.zip,我把它解压后放在”GoogleApp”的文件夹里(当然,这个文件夹名随便起).
6. 用文本编辑器修改app.yaml.把”application:b3insidecdn”改成你自己的”application:<你的application名字>”并保存.这个配置用来告诉Google App Engine你要上传的是哪些文件.
7. 呼~ 现在把你要上传的图片, css, js, 甚至视频放到你本地的这个文件夹中.我把图片都放在/img里,别的文件也放在子文件夹里,方便管理,如/css/b3inside.com/style.css.
8. 运行你安装的GoogleAppEngineLauncher.app,然后”File”-”New Application”,按下图填写,端口不要用80,因为你机器上还有Apache在跑.之后点”Create”创建即可.
   
9. 上一步将SDK和你本地文件夹做好连接后,就大功告成了.以后把要上传的文件放在你的文件夹里,通过GoogleAppEngineLauncher把它们Deploy到Google上就行了.
10. 好了,快去访问一下你的CDN吧,看看它是否已经正常工作了.用这个地址:<你的应用名>.appspot.com/img/welcome.gif(我的是:b3insidecdn.appspot.com/img/logo_alpha.gif)

如果你是WIN用户,大体做法和上面一样,只是需要多安装点东西,我把不同的地方简单补充一下:

1. 下载Python并安装.任何目录都可以.
2. 下载Google App Engine SDK并安装,安装程序会自动检测你机器上是否已经安装了Python.
3. 登录appengine.google.com.
4. 创建新应用.
5. 下载文件 http://b3insidecdn.appspot.com/files/b3insidecdn.zip,作为本地目录参考.
6. 编辑app.yaml文件,修改application的名字.
7. 把要上传的文件等放到这个文件夹中,待上传.
8. 下载这个自动比处理文件http://digitalisticcdn.appspot.com/files/deploy_digitalistic_cdn.bat,用文本编辑器修改一下,替换成你自己的Python路径和Google App Engine安装路径(注意:路径必须用引号包围).需要同步你本地目录时,只要运行这个文件就行了.
9. 都配置好后,双击deploy_digitalistic_cdn.bat来把你的文件上传部署到你自己的Google App Engine上.第一次运行需要输入你的Google用户名和密码.
10. 大功告成.测试你的CDN是否运转正常的方法,和Mac版的一样.

本文并不是对10 Easy Steps to use Google App Engine as your own CDN的简单翻译,使用CDN也只是网站优化内容之一,我们迈出的只是长征路上的第一步.

P.S.需要告诉你的YSlow, appspot.com是你的CDN服务器,所以需要做以下配置:

1. 在Firefox地址栏里输入 about:config
2. 右键–新建–字符串
3. 字符串的名字:extensions.firebug.yslow.cdnHostnames
4. 值就可以写:appspot.com

相关文章

1. 在Google上看书
2. 未来我们只需要浏览器
3. 2009互联网产品盘点
4. 用好Axure的协作功能
5. 给Notepad++换主题

如果回顾一下Sampa的注册表单，到现在它已经经历过4-5个不同的版本了。一度我们要询问您15个问题。在那之后，我们先是与当地的一位用户体验专家对此进行一些简化，而后又通过与一家波特兰用户体验公司的合作，将其变的更简，现在我们只剩8个填写项了：

1. 姓名
2. 电子邮箱
3. 确认电子邮箱
4. 密码
5. 确认密码
6. 同意使用条例
7. 你希望的网站地址（形如：b3inside.sampa.com）
8. CAPTCHA （挑战码）

先来看下这个网站的注册表单截图：

在阅读了Luke Wroblewski的“Web Form Design Fillin in the Blanks”文章基础上，我决定更深入地研究一下我们的注册表单。在拥有极好的转化率可以轻松假设一些事情以前，我一直担心改变我们的注册流程会事与愿违。好吧，但至少我还做了一处改变，不需要再动脑考虑了它了。就是使用条例的复选框，原来默认是没有被选中的，我把它改成默认选中了。

但这还不是有趣的地方。Luke在书上提到说，我们在表单中提问的很多事情都是限于应用本身的，而对用户没有价值（或者说“完全、彻底”）。你可以很明显地看到在Sampa站上有一些这样的内容。为什么我们要询问两次邮箱地址？为什么我们要询问两次密码？为什么我们需要你的名字？为什么需要挑战码？

对于上面的问题我有很好的答案，在过去两年，我们通过用A/B测试的方法对很多情景进行测试，得知我们已经很接近（表单元素）正确的排列组合，并且带来和保持了很高的转化率。但只有一块没有经过测试就取消掉了，那就是挑战码。

我们为什么需要挑战码？就像你去注册其他一些免费web服务一样（如：Hotmail, GMail, Ticket Master, Blogger,等等）。挑战码在阻止自动注册机器人创建成百上千个垃圾帐号上是很有必要的，同样也阻止了Spam和Link Farm。好人要放行，我们要把坏人挡在外边，你说对吗？

上周一下午5:13，我们去掉了Sampa上的挑战码。这不容易也不彻底，但我们创建了一套测试和规则使得我们99%的时间不用显示挑战码。我不能公布我们所做的测试，因为这是秘密，不能让注册机器人的制造者知道。

测试结果：提升了9.2%的转化率！

让整个团队惊讶的是，有如此大比例的用户想注册Sampa，但他们或者没有通过挑战码验证（可能性比较小），或者发现表单被挑战码搞得很吓人（有很大可能）。紧接之前我们的讨论，第三点是用更短的页面，让“Continue”按钮更多时候出现在第一屏内，这样会给用户一个更好的感觉：这个表单很短哦。

去看看文章中出现的Sampa网站的注册表单

以下是我的补充和总结：
让你的表单变得更有效的方法：

1. 尽量减少用户要填写的内容和选项；
2. 如果可以，就去掉挑战码，因为有些挑战码真的很复杂，给用户带来的挑战过大；（当然这要做权衡。用其他技术对挑战码进行改革，用类似Sampa的方法解决。注意观察Sampa的挑战码，都是些简单的英语单词。）
3. 缩短页面，最好控制在一屏以内，这会让用户感觉这个表单并不那么复杂。

顺便提一个数字，每给用户增加一个流程，用户完成率或到达率减少大概40%。这就不难理解为什么Sampa网站的设计人员要把他们的注册流程简化简化再简化了。前段时间我也在做同样的工作，优化注册流程，在做减法的同时，想办法缩短用户从注册到达真实产品的路径也是非常有必要的，“more earlier, more better”，越早让用户融入产品、得到他想要的东西，就越有利于建立用户成就感，从而带给用户更好的体验。

[READ]

P.S. 我联系了Sampa的CTO，也就是上面我翻译的原文的作者Marcelo Calbucci，但很遗憾，他当时没有留之前版本的截图，所以我没办法给大家做对比了。

相关文章

1. 设计表单的标签和输入区
2. 标签水平右对齐更适合中文网站
3. 用户体验案例研究：设计微博应用
4. 从中关村的购物体验侃起
5. 内容为空时提交如何处理