翻译：1-8 by MartinRGB
响应式设计领军人物，“移动优先”（Mobile First）设计策略提倡者，经典交互书籍《Web表单设计》作者,Luke Wroblewski在我心中一直是神级人物。
不但在设计理论上颇有建树，往往能提出一些创建性设计思维。而且，具有良好的习惯，定期观察、评论互联网/移动的发展趋势。
他写的设计文章通常深入浅入，能够将富有灵感的理论写的浅显易懂。
于此同时，他还是重磅应用Polar的设计者
著作一览
移动优先
Web表单设计
在交互方面，他无疑是一位多才多艺的大师，著作等身；
而在设计理念方面，除了提出了颇有实际用途的“移动优先”理论外，他还具有务实的设计理念：他很耐心，他会围绕一款应用
，花一年的时间去完善、去重设计。这一点很令人肃然起敬。
关于Polar
在没有接触Polar这款应用之前，就看到Lukew在他的博客上发表了一系列文章，来讲述这款应用的设计细节。里面的一些道理非常的中肯，能够很方便的联系到一些实际设计项目中。
而接触Polar这款应用后，我上瘾了！清爽的界面，贴心的设计细节，有趣的投票体验。
优秀肯定不是一蹴而就的，我们一起来看看LukeW亲口讲述的设计细节。
导读：几乎每一本设计模式书籍/设计模式库上都建议，当页面需要读取时，最好提供读取指示器或者进度条来缓解用户角度，
但是，这样真的好吗？
原文地址：http://www.lukew.com/ff/entry.asp?1797
传统的经验告诉我们：当程序加载需要一段时间时，必须要在界面中告知用户，让用户安心等待。大多数手机应用都采用了读取
指示器，来告知用户程序正在加载，请等待。尽管有读取指示器比没有要好，但实际上，指示器并不好，不能达成良好的用户体
验。
为什么这么说？因为读取指示器会攫取用户的注意力，用户本来就着急使用应用，现在需要等待，注意力自然集中在读取指示器
上面了。想象一下当你着急干某事，却不得不等待时，你会看表——而一旦你凝视着秒针的转动，你会发现时间似乎变“慢”了，于是你越来越着急。指示器设置的快点？用户会很急躁（既然读取这么快，为何还没载入新界面？）指示器设置的慢点？用户会不耐烦（似乎读取速度很慢）
在Polar这款应用中，我们发现了这一点，为了避免此问题，我们艰难的设计，做了一点实验，一点一点的读取界面内容。这样的等待让用户感到确实值得——因为每秒等待的结果看得见，他们能够看的见应用是如何努力一点一点的从服务器接收数据，然后呈递给用户。
最开始，为了让用户知晓元素正在下载中，我们添加了旋转式读取指示器，来展示正在从服务器处接收。用户会在应用中发现
旋转的指示。
可结果呢？用户给予了我们如下的反馈：
“感觉等待耗时太长了，读取、刷新的速度太慢——感觉没有上一版本快”
正像上面说的那样，读取指示器容易让用户感觉时间变“慢”，因此应用等待耗时相对的就“长”了。而且从设计的层面上讲，这么设计仅仅聚焦于“指示器”，而不是“程序的加载”。用户得到的是“等待”，却看不到“程序加载过程”。
经历了这番思考后，设计思路明晰了起来，我们应该向用户展示一步一步读取的过程，而不应该省事的一个进度条了事，让用户陷入无尽的等待中。
例如，在谷歌搜索应用中，加载中的网页的界面顶端会有一个移动的读取进度条，让人感觉内容正在读取中。谷歌成功的
转移了用户的注意力，让用户的目光移动到了进度条的读取上，一点一点完成读取流程，最后读取完成的瞬间，用户会很
满足。
上面是方法一，下面的方法二也不错，叫做构架读取。我们在Polar使用了这种技术，因为进度条虽然比指示器先进，但是
其实本质都是一样，只不过进度条更具有某种“欺骗性”，而构架读取不一样，读到了什么地方，就显示出什么地方，所见
即所得，能够大大的增强用户的信任感。渐进式的数据读取，最后达成完整界面的传递。
技术总是在发展的，对不对？用“读取进度可见”的进度条取代指示器是一种进步，用“展示读取内容”的构架读取取代进度条又是一种进步。
导读：网站/应用都想让用户邀请用户的朋友，不但可以增加用户数量，还可以提高用户体验（人多才好玩，如果有朋友一起来玩，肯定更好玩），但是如何委婉的让用户邀请朋友来注册呢？
原文地址：http://www.lukew.com/ff/entry.asp?1798
在好莱坞大片中，敢于挡住火车运行路线的人，一般没什么好结果。一般没什么东西能承受得起那么大的动量冲击。因此，如果你遇到这种情况，别跟火车争，明智的选择是让路。上面这个经验教训与移动应用设计有关，你信吗？在这里，“你挡住火车的运行路线”是为了“得到设计上的目标”，“火车”指的是“用户体验”。
换句话说，不要为了一些目的去妨碍用户的体验。用户的力量不可抵挡，他们是上帝。让我以Polar这款我们开发的应用举例，Polar这款应用提供了一个意见收集、创意分享的平台，而且使用起来非常的有趣味性，用户要进行照片投票。用户非常喜欢这款应用，每个用户每天平均投票40个问题。Polar具有一种沉浸式的体验。但是呢，如果用户和朋友一起参与这个游戏，无疑投票会更好玩。一开始，我们试着在每次投票后都提示，想要寻找你在Polar中有哪些现实朋友吗？
结果是很少有用户去拉朋友入伙，或者寻找已经安装Polar、并且现实认识的朋友，而且他们对这种骚扰感到厌烦，因此我们试着换一种方式，我们不妨碍用户体验，用变通的方法来实现我们的目的。
所以呢，我们设置为“用户投票19次后”，第20个问题投票是“要在Polar上寻找朋友吗？”第一个答案是“好的，他们在哪里？”，第二个是“我宁愿孤独。”一般都会选第一个，然后会让用户联系他们在各个社交网络上的朋友，邀请来一起投票。
这就是引导，这就是不妨碍用户，这就是良好的用户体验。合理分析用户的心态，为他们着想，才能更精确的命中用户需求。我们从“找朋友”这个功能上找到了突破点，利用这种方法，重设计了很多功能。
导读：同样的，很多设计模式库/设计模式书籍中会提到，应用应该提供用户交互，那么传统的用户教学未免过于理论化，如果让用户在实践中完成学习呢？
原文地址：http://www.lukew.com/ff/entry.asp?1786
倘若没有明确的操作语境支持，触摸交互基本上都是隐形的——我们不知道结果是什么。为了处理这个问题，很多移动应用加入了“新手指导“环节。就是第一次进入应用时，会教你如何进行手势操作，出发点是好的，但是结果不太理想。事实是，90%的人都会跳过此环节，即便没有跳过，学过的东西马上也会忘记。问题出在何处？所谓“实践出真知”，没有实践，教用户“纸上谈兵”你觉得用户能掌握吗？而且用户的心理是，想尽快的操作应用，这一点也被忽视了。界面的模样都没看到，便教用户怎么去进行界面操作，未免太荒谬。
一些移动应用在打开时，就在界面最顶端弹出新手教学，力图图文并茂的展示，但是用户缺少实际操作，并不知道这么多手势中，最常用的是哪个。因此用户学起来“全而不精”。
所以这种情况下，提前教学是不好的，教学要在用户最需要的情况下出现，这样才有效。Josh Clark称这种方法为“及时教学”，这是很灵活的办法，在Polar中，我们便采用了这种方法。当你大致浏览了Polar，并投票几次后，你发现信息全部浏览完了，这时候底部就会又一个提示：滑动我以获得更多信息，然后会弹出教学，教你怎么跳过不感兴趣的投票，获取更多的投票内容。
这则提示信息会在用户使用应用一小段时候后出现。类似的，更高级的交互方式也会适时的出现。
将繁复的指导隐藏、分解，在用户需要被指导时出现，用户看完指导立马实践，这样的教学效果绝对好。用户需要时，满足他们的需要。用户不需要时，别去烦他们。
导语：怎样才能让用户对你的应用保持新鲜感呢？看看下面的几个案例
原文地址：http://www.lukew.com/ff/entry.asp?1772
桌面时代，大家使用的设备屏幕都很大，因此产品、应用的品牌标识也非常容易推广——做一个大大的Logo即可，反正屏幕那么大。而移动时代，屏幕空间有限，留给品牌进行推广的余地很小。那么对策应该是什么呢？答案是启动画面。
老看同一个画面，即便再精美也会厌烦，例如，Hotel Tonight每次升级时都会更换启动画面。这能打造一种与众不同的用户体验，象征着：我们一直在变，一直在提高品质。
那么，除了启动画面，交互组件是不是也可以加入这种充满“变数”的特质呢？可以，在Polar这款应用中，通过下拉进行刷新，每次下拉时，都会显示不同的卡通角色，这样让用户感到生动有趣，不是那么的呆板。
但是要注意，在“变数”的基础上要保持一定的一致性，要么是主题一致，像最上面的Hotel Tonight，均有一个“H”；要么仅仅对部分元素做出改变，比如说上面的Polar。不要过度改变，否则这样会让用户混淆。
可以试着进阶设计，为设计加入一点“变数”。让每一次的体验都独一无二
导语：iOS6->iOS7的迁移，让很多应用头疼，除了美学问题，应用还必须符合iOS7的生态，这是个难点。
原文地址：http://www.lukew.com/ff/entry.asp?1800
我们逐渐的适应了iOS7的设计语言和美学。适应之后，便是进一步的发展，作为设计师，创新是我们心中永不熄灭的火种。如何让iOS7的界面设计”更上一层楼”呢？从某种角度来说，iOS7″看起来”很容易设计，因为iOS7界面简约。但是从另一种角度来看，正是这种”简约”增加了我们的设计难度。
前面已经提到过，和iOS6相比，iOS7的界面具有天生的简约性。表面看来，似乎设计工作简化了。实则不然，过去的加法设计需要花时间添加细节，现在的减法设计需要花时间思考、简化元素，设计师并没有轻松多少。
“真正的简约设计是：作品必须不断的被简化，一改再改，直到设计最终成形。”——Jonathan Ive,2013
Jonathan Ive的这番话的意思是，iOS7上的界面设计需要经历多次的版本迭代，精雕细琢的进行简化，你看下图的对比，可能有人会说，”看起来差不多嘛。”。实际上，这是精心改进的结果（下图），右面的输入区域感觉更简约，整体的风格也更统一，柔和流畅，左面iOS6的相比之下就不如右面。
iOS7上的标头需要下功夫去设计，这就要求我们提高对标题这一元素的理解，要求我们更深入的了解其本质。
标头中加入了毛玻璃效果，这是iOS7体验特色之一，具备透明效果的标头便能和系统状态栏的颜色一致（下图），不会像iOS6那样出现状态栏和标头之间毫无过渡，略带割裂感。首先，我们要考虑标头如何与状态栏风格统一（以前只考虑标头就行了），
其次，标头下面还要呈现模糊效果的内容，这就是工作量的提升。
控件不占用内容空间，在需要的时候又出现，这是界面设计的至高境界。
iOS7的毛玻璃效果很华丽，但是又有一定限制，你看下图，还是占用了一定的界面空间（这里如果清晰一点就好了，可是模糊又有模糊的好处，见下文）。
这里提倡一种变通方法：便是当用户向上滑动手机界面时，页面向下滚动，标头消失，以便更大限度的让用户寻找信息。
当用户向下滑动一定量后，页面向上滚动（用户要么在该界面找到了所需信息，用户需要进一步仔细阅览；要么用户没有找到，用户需要返回上一级。无论如何，两种情况都需要导航工具），标头会重新出现，这样就能方便用户导航。
这是Polar这款应用的下拉刷新设计，我参与了这款应用的设计，刚开始我们觉得明显一点比较好，这样用户便能快速发现此功能，但是这导致了一个问题：标头的文本内容可读性降低了。因此我们增强了模糊感。
（你看，之前提到的毛玻璃效果由于过于模糊而占用空间，而此处因为不太模糊而影响用户阅读标头，可见毛玻璃效果怎么设置取决于场景）
你看，通过增加模糊感。标头的深度感、可读性均得以加强。双赢。在上面的种种案例中，我们发现，iOS7的设计语言肯定不是尽善尽美的。我们要通过自己的思考，在iOS7设计美学的基础上，构建超越iOS7的设计。
相比iOS6，iOS7的视觉元素有所减少。问题一，没有了拟物的”隐喻”，用户该要如何理解界面元素。问题二，更简化的层级该要如何打造？
“大巧不工”，可真正能有几人能够理解这种”不工”的境界？
让你用六个词汇描述一个物体很容易，可现在有所限制，仅仅给你两个词汇去描述，你该如何传达清晰？同样的，以前我们有更丰富的色彩，更细腻的材质，更逼真的光影效果，以及更富层次的信息层级。而现在”扁平化”之后，手段变得有限了。我们要如何达到跟以前一样的结果，甚至超越？
看看Twitter iOS6版与iOS7版的比较，iOS7版本的界面元素间缺少对照，导致某些关键控件不突出，无法有效的引起行为召唤(Call To Action)
现在该贬贬iOS7了，很明显左面的Tweet按钮要比右面的明显。右面的界面中元素辨识度不高。
iOS7的界面中很多主要交互元素仅仅在字体粗细和颜色上做了调整（下图的Agree按钮），不仔细看，还真不是太好认。
当然，我们还是有办法利用少量的视觉元素打造高效的视觉对照和信息层级，但是很艰难。我们回想一下开头引用Jony Ive的话吧：”必须一改再改。”
我们再来用Polar这个案例来解释一下种种问题吧。
这是我们的早期设计，你看”添加”，”搜索”以及”创建新投票”这几个栏混杂到一块儿了，用户很难加以区分。
这就是挑战，我们在iOS6中以来阴影和材质来区分彼此，形成对照。在iOS7中，要想以简约的、扁平式的风格打造优良的信息层级很困难。我们做了种种努力去区分彼此，但是最后的结果往往是各个元素混合到一块儿，看起来差不太多。
嗯，很杂乱，不是吗？我们思考之后，认为是元素太多了，按照简化的思路，移除了一些视觉元素，移除了材质，这似乎奏效了一点（上图从左到右）。然后通过颜色对比来打造对照感（下图）。
在iOS7中打造优秀的辨识度不容易，个人认为这是iOS7界面设计的关键所在，也是难点。它逼迫着你不断简化，元素更少，对照感相对就容易设计。
再来谈谈Polar这款应用的标签栏设计，我们这款应用的标签栏图标设计的很赞，很个性化，很直观。我们从iOS6升级到了iOS7，采用了iOS7那种纤细的线条轮廓，问题出现了。
首先，仔细看看上面这组对比，有人提出上面的图标更有效率，我们做了用户调查，也确实如此。为何？因为从视觉冲击力的角度讲，空心不如实心，细线条不如粗线条。用户能够对第一组图标迅速做出反应，而第二组需要先辨识一下这组图标的不同之处，再进行操作。
其次，这么一修改，把图标的”个性化”改没了。所以，我们需要”一改再改”，下面是标签栏的升级图。
标签栏的反复更改后得出的经验：你的应用界面固然有自己的”个性”，iOS7的界面也有自己的”特质”，如何完美平衡，不太容易。iOS7的设计美学可以作为参考，但是不能一味的模仿，要根据自己的情况来设计。
在”创建新投票”这个界面中，我们也犯了错误，一开始设计的”不是那么扁平”稍稍一来了一下深度感和、材质，但是效果不尽人意。（下图为修改的两个版本）
我推荐使用模糊效果，效果还不错，用两块模糊的毛玻璃”夹住”最核心的信息，这样便打造了视觉焦点，信息层级很清晰。
好的产品必然是要经过不断升级、重复迭代的。
还是那句话，”不要墨守成规，要学会变通”，思考是设计良药。
导语：多屏交互时代即将来临，面对多设备协同模式，Polar是如何应对的呢？
原文地址：http://www.lukew.com/ff/entry.asp?1745
网络无处不在，设备种类和浏览器种类不断增多，网络成为了我们生活中必不可少的助手。有时候，我们需要重新思考一下互联网——不仅仅是下载、获取数据，网络的意义在于连接。
我们Polar团队携手微软，利用互联网，在Polar上打造了多设备协同交互体验。
从超链接再到社交网络，网络连结了人与人，连结了信息与信息，而且，网络还能连结设备与设备。从这一点出发，我们来思考新式的互联网体验。在美国，超过80%的用户在看电视的时候玩弄手机，20%的用户会对着电视玩手机。
尽管设备种类、操作系统功能、应用数量不断增多。但是电视和手机之间、设备与设备之间的联系还没有得到重视，多设备协同交互体验设计其实很有市场潜力。网络能够帮助多个设备建立紧密的联系，依托应用的功能，实现更有趣的交互。
我认为这种协同交互体验代表着下一代网络发展趋势，很高兴，能够和微软的IE团队一起合作，改造Polar。
Polar是一款投票应用，能够让你分享你的观点，可投票的话题有很多，从食物选择再到iOS7图标设计。在布局上，我们对响应式设计进行了改良，根据不同类型设备的特点，针对性进行布局。同时在交互上，针对不同设备的输入特点，也进行了优化。
但是，实际情况是，大部分用户都拥有不只一件设备。所以我在思考，如何结合用户的多种设备（电视、电脑、平板、手机），协同运作，打造更紧密、更一致的交互体验呢？
请看本文提供的视频，你可以看到，大屏主要用来展现影视、视频等等。而小屏可以用来投票、回答问题。两者实时同步。
或者是：利用小屏的浏览器来进行交互操作，滑动、投票、切换话题；而大屏幕用来体现操作反馈。
这可不是天方夜谭，我们已经实现。小屏控制大屏只是多屏协同交互的一种。
一旦完成了投票，可以在大屏幕上显示投票结果，来显示其他人的看法。于此同时不妨碍你观赏视频。
因为是互联网，所以无所限制，多屏协同交互体验可不只有这一种。不光是电视与手机这种大小屏，还可以有平板对手机、平板对平板多种搭配。
正如你所见，互联网充满了无限可能，多设备协同体验能够让你的生活发生改变。
现在，仅仅是计算机和移动设备的互联。一步一步，越来越多的网点，越来越紧密的“蜘蛛网”正在构建：回到家，用手机控制咖啡机，然后放下手机充电，躺倒床上，用平板开启电视，调节空调。如果想了解更多“多设备协同交互”的概念，不放上微软的官网看看。
导语：除了经验，当我们需要问题时，同样需要记录，记录下思考方式和当前解决方案，以便日后解决。
原文地址：http://www.lukew.com/ff/entry.asp?1816
关键词：屏幕尺寸 输入方式、输出方式与操作姿势/距离之间的关系随着设备种类的增加，响应式设计变得流行开来。很多设计师和建站者利用响应式设计，在多种设备上打造出几乎一致的体验。对用户来说惊艳，对设计师来说高效。
响应式设计成熟了吗？完美了吗？完全没有，虽然在理念上没什么问题，但是还有很多地方需要小修小补。
比如说最近提倡的一种响应式图标设计（大屏幕上需要更大的图标和更多的图标细节，小屏幕因为空间限制以及网速问题，需要更小的图标和更少的图表细节）就很有趣，推荐各位学习一下。
其实还有一个非常严重的问题：太多太多的响应式设计，仅仅依赖屏幕尺寸来进行布局调整，而忽略了很多其他因素。
根据屏幕尺寸进行布局调整，没什么错误，但是我们绝对不能仅仅依赖屏幕尺寸进行响应式设计。大屏幕的视觉体验要比小屏幕的好，这算是一个常识。
可大家有没有发现，手机端的转化率在大幅增长，在越来越多的行业中手机的转化率已经超越了传统桌面。短时间看来，不是移动设备取代桌面设备，而是移动设备、桌面设备实现大小屏物尽其用的多设备交互。因此我们不能只考虑移动端的交互体验，还要考虑到桌面上的体验（别忘了微软还为WinXP做了好几年的后续更新呢。系统虽然旧、虽然落伍，但是还有用户在用。）。
做设计的，要尽可能的面面俱到，要考虑到用户的使用场景，也要考虑到用户所使用的设备，屏幕尺寸仅仅影响交互体验的因素之一。总而言之，我们要考虑到以下几点：
1.浏览器是运行在移动端还是桌面上？
2.网络连通是否顺畅？
3.设备的输入模式是触控？语音输入？还是其他方式？
太多的响应式设计者，仅仅考虑到了屏幕尺寸，却忽略了以上几点。自然而然的，输出的结果不是那么的理想，兼容性也不是那么的高。
让我用一些事例来说明我的观点：
在平板、电脑、电视上的Win8系统中，我们在运行天气应用时，从屏幕边缘拉取出日历应用(Snap Mode，捕捉模式)。

不知你发现没有，无论是PC、电视、还是平板，拉出的日历应用宽度量非常相近（相对像素），但是手机的界面中显示的不是日历，而是日程管理。当然，控件布局也根据手机的操作习惯、屏幕大小进行了调整，如下图。

不了解的读者可能会问：这里怎么不参考一致性原则，也设计成日历啊？
首先，手机屏幕空间有限。其次，要考虑到底部法则：控件居下，内容处上（控件位于上方，手会挡住屏幕影响内容读取。）——由此可见，响应式设计可不是简单的根据屏幕尺寸进行比例缩放，要考虑到设备的特点。
在Windows Phone设备中，IE使用了320px的设备屏幕宽度。而在Win8平板、电脑和电视的捕捉模式中，拉出的天气应用同样占用了320px的设备屏幕宽度。
因此，在响应式设计中，智能手机和“电视屏幕捕捉模式区域”具有相同的设备屏幕宽度(320px)

但是界面为什么不一样呢？因为看电视，我们一般会离电视超过10步远（10英尺）。而我们玩手机时，离手机屏幕的距离也就30多厘米（1英尺）。而效果一不一样呢？
根据个人经验，还是手机看起来更爽。所以，用户的姿势（或者说用户的视角/与屏幕距离）也是需要考虑的一大因素。而电视的输入模式也跟手机不同，电视可以选择多种输入方式：键鼠、触控、体感(如果有Kinect并破解）、语音。手机大多采用触控或者语音。如果你能够在设计时考虑到距离问题以及输入问题，那么你会能发现更多问题，会根据设备特点进行更针对的设计。自然而然的，不同设备间同一应用的界面也有所不同。
我们来比较一下Polor这款应用在电视和手机上的界面。这幅图是以用户的视角（假设理想情况下，用户拿着手机，手机离用户的脸1英尺，电视离用户10英尺。）
通过捕捉模式，电视屏幕中左端显示了投票功能。手机屏幕中显示的也是投票功能。
两者的屏幕宽度一致，但是界面并不一致。在电视中，我们设计了列表式预览、黑白对比强烈的色彩以便提供更佳的可读性。而且输入方式也不一样，手机很明显是触控，而电视很明显不能用触控（操作一次便需要走进电视一次。）
所以说，屏幕尺寸，不能作为响应式布局设计的唯一考量。
看完了Win8，我们再来看看安卓，比如说，Google Glass谷歌眼镜。
据官方说法，谷歌眼镜能够提供“在8步远的地方观看25英寸高清电视”般的视觉效果。
跟众多手机浏览器一样，谷歌眼镜也采用了动态视角，来调整页面。
谷歌眼镜的默认视角宽度是960px，可以根据情况缩小。比方说用户浏览雅虎金融站，谷歌眼镜中所呈现的画面如下，不是很好，为了适应宽度，页面不得不缩小了一点。
谷歌的网页浏览器允许页面响应式的调节。比方说，如果将宽度从960px变为640px，在谷歌眼镜中的呈现效果就完全不同（用户感觉有点像在玩平板），界面会自动适应更小的视角宽度。
上面的就是谷歌眼镜的响应式设计，根据屏幕尺寸进行的缩放。但说实在，640px的可读性虽然比960px有所增强，但是我觉得640px屏幕宽度的可读性还可以更高。
不得不提的是谷歌眼镜上的应用，比方说这款股票应用，提供的股票信息几乎和雅虎金融站差不多。640px视角宽度下效果更佳。（所以说傻乎乎的死板缩放不行吧？还是需要根据具体情况优化的。）
综上所述，屏幕尺寸不是万能的。
界面的响应式设计，不但要考虑屏幕尺寸，还要考虑到输入模式、输出模式以及距离的问题。我们需要把这几点因素结合考虑。
正是这种不确定性才有挑战，有挑战的设计才有趣。
有什么聪明的办法吗？有，我想了一个支持所有场景、所有情况的响应式设计方法：
不应该死板的缩放，而是询问用户的意见，谷歌眼镜这种模式就不错，你可以让用户自行调节距离，是想要10步远的视感？还是想要2步远的视感？让人来决定如何变化，而不是让屏幕尺寸来决定如何变化。这符合互联网的自由精神。
但这个方法也不是很理想，因为以前设计界面，是更有经验的设计师根据经验来优化页面界面效果，而这种寻求用户意见的“支持所有情况”的设计方法，需要用户掌握一些设计知识。（毕竟不是每个用户都懂设计，他们可能会因此花费大量时间调节，所以还是设计师提供用户以优化过的界面比较好）
不得不说，距离问题以及输入问题，是响应式设计的大挑战。设备的种类会越来越多，真的不可能针对每一种设备分门别类的进行优化。现在急迫需要一种长期有效的、兼容性强的设计方法，更好的实现响应式布局。
依赖屏幕尺寸式的响应式设计也有死角，再走下去，将不适合多设备的网页浏览。
更多的因素，还需要考虑。
导语：一款应用，一个用户帮助就够了吗？不！Luke W告诉你，不同设备上的用户帮助应该是不同的，这样才能让用户最快速的实现操作。
原文地址：http://www.lukew.com/ff/entry.asp?1842
时至今日，互联网已经不再是桌面的天下，手机、平板、更多智能设备的加入，让互联网时代迈入了“多设备阶段”。用户的操作方式相应的千变万化：他们可能使用鼠标键盘，也可能使用触摸屏、触控板。
再考虑到各种各样的使用场景。互联网的可能性增加了，设计师的挑战也同样增加了。新的时代背景下，你的应用该要如何设计？如何帮助用户解决问题？提及“用户教学”，就不得不提及“用户帮助”，最传统的用户帮助方式是“内联帮助”
内联帮助通常会放在用户需要帮助/用户出现问题的地方，通常是可见的，这样当用户出现问题时，用户直接就能看到。这是一种非常有效的办法，能够指引用户操作界面。
传统的内联帮助如上设计，新的时代，手指取代了鼠标，那么用户帮助需要怎样的相应变化呢？
例如，我们最近设计了一个完全响应式的网页应用，能够在手机、平板、桌面上进行操作。
在这个网页应用中，用户可以缩放图片、调整图片尺寸。操作方式主要取决于输入设备，不同的输入设备有不同的操作方式。
定位一张图片可以用点击操作，可以简单的使用手指来拖移图片。可以使用放大/缩小手势来缩放图片。也可以通过双击操作，来让调整图片大小，使其尺寸刚好适应当前所需尺寸
当然，使用鼠标和键盘也可以实现同样的功能。只需按下左键，拖移即可。
用鼠标滚轮和触控板也可以实现缩放手势。鼠标双击也可以实现自动调整图片尺寸。
正如你所见，虽然最后实现的操作结果相同，操作方式也比较相似，但实际上，操作方式还是有所不同的。
用户基本都熟知触摸屏的操作方式，都能很自然的利用手势缩放图片，而桌面端用户却并不熟知滚轮缩放手势。
怎么让桌面端用户快速实现缩放手势呢？我们想到了前文提到的内联帮助。
其实非常简单。只需要检测用户是否有鼠标或者触控板设备即可，如果有，采用这种方式，如果没有，那么就不采用。
在早期的项目中，我们面临着同样的问题。平板和手机用户可以非常容易的与Polar应用交互，动动拇指就行了，而键盘和鼠标用户的交互方式比较笨拙。要知道，拇指操作，可以直接完成选取->投票操作，而鼠标用户则不能。
那怎么办？我们想到了一种键盘交互方式，用户按键盘的左右键，即可选择投票，按上下键，即可进行投票/取消的操作。更迅速、更有效。
这样设计虽然方便用户，但是又面临了一个新的问题：用户不知道可以这么操作。
同样的，根据上面的方法，在用户进入应用后，我们需要检测用户是否拥有键盘设备。
如果有，那么显示内联帮助。
经过几次失败的尝试，我联系到了微软的几个朋友，找出了解决方案。
毕竟，新时代的交互是多设备交互，不光是桌面端，还有移动端，是笔记本、桌面电脑、手机、平板共同谱写的美妙乐章。
非常可惜，上面提到的解决方案不是最完美的。以现在的网页浏览器技术来看，依然无法有效解决这一问题。
网页尚无法根据硬件种类来完美选择交互方式，我们只好根据屏幕宽度来推测用户使用的设备种类，进而选择交互方式。
如果屏幕宽度超过某个数值，说明用户使用的是鼠标键盘，从而加入更多的内联帮助，以实现用户的快速交互。
我之前也写过一篇文章说过，仅仅“依赖屏幕尺寸而判断设备种类，继而进行响应式设计”的这种设计方法局限太大，是不完善的，但是目前，我们尚无更好的解决办法。
没错，我们完全可以在用户开始使用应用之前，先给用户展示不同设备的不同交互方式。
可是这样做的话，就没有了帮助的有效性、及时性和针对性。
我们只能先让用户初步交互，继而判断用户的设备种类，提供相应的帮助。
你以为帮助很好设计么？最理想的状态是：一款应用，多个版本的帮助，在手机端提供手机版交互指引，在桌面端提供桌面版交互指引。
小细节成就大未来。我们需要一个个这种细节，让用户体验更加完美，实现未来无缝式的多设备交互。
http://www.MartinRGB.com
234
作品
1.7w
粉丝
413
关注
大牛，别默默的看了，快登录帮我点评一下吧！:)
登录 立即注册