一、如何理解本条内容:

一个“简单”和“复杂”的例子

在我和开发人员沟通一个项目需求的时候，他们频频慨叹Mockup的设计所考虑情况之细致，很多程序要实现的预判和“非基础功能点”让开发人员望而却步不情愿去实现。相比较设计师为了让用户避免出错而绞尽脑汁去设想和考虑，开发人员更倾向于直接给到一个只能容许的操作行为，其他非法请求全部报错：“程序是严谨的，他错，我报错，以不变应万变。简单一点不好吗？”程序员们甚至笑言：“考虑他们的体验那么多，我们开发的体验真不好，please，咱们能不能不要把事情搞那么复杂”。

在这个例子里，程序员看来，对于用户在和系统交互的过程中可能出现的各种情况均予以考虑，找寻用户理解起来最明确、操作最简单的、用户犯错最少的设计是缺少效率且浪费时间的。设计师这样做，是在将简单的事情复杂化。OK，现在就有这样一个问题，什么是“错误”？每当程序要处理错误的请求，是否是用户真的在“犯错”？

1、问题一，是谁的错？

我在某一天使用了一个网站的相册功能时，遇到了这样的情况（如下图）:

“普通上传”是当前的选中状态，而上传“取消”的Button也是同样的样式。因为选中状态具有“肯定、确定”的潜在暗示，这样消极操作和积极操作的状态完全混淆了，用户在上传过程中很容易出现错点“取消”Button当作确定完成上传任务的误操作。

如果真的发生了这样的情况（应该不在少数，像我就发生了在本地好不容易选择好的图片误点了很像“确认”功能的“取消”而做无用功的情况），是的，用户犯错了，但是责任难道在用户吗？ “本来我不会犯错，是你的设计使我犯错，或起码增加了我犯错的几率。”类似这样的错误，系统可能会报错，也可能不会；但真正应该检讨的却是系统本身，即： 用户对界面的理解和本身的系统意图出现误差，系统设计的歧义等固有缺陷导致用户出错。让用户频繁碰壁、产生挫折感的设计，其原因不是用户的愚蠢、而是设计的愚蠢。

2、问题二，这是不是一个错？

关于“错误”一词解释的第二点主要针对用户对系统的行为层来说，即：用户在人机界面交互过程中的误操作，系统未能通过更好的设计减少和避免用户的误操作带来的损失。

还是以“上传照片”为例（如下图）:

一个模态的警示框，赫然告诉你，你想在这里上传相片，根本不该使用除了ie之外的浏览器！除了事先不打算通知你之外，同时也没的商量，因为我没有给你提供别的替代性方案和其他选择。

可以想象,用户想要使用这个上传相片的功能，之前已经需要经历过许多步骤，比如要打开自己相册存放的线上地址、要成功登录进入管理后台、要寻找到上传相片的功能模块等等，已经付出了相当一部分的操作成本。但是系统却很残酷的让用户的所有工作都白做了，不仅如此，还很野蛮的方式告诉用户：你从一开始就错了！在这个情况下,用户对系统的理解并不存在误差，但还是在交互过程中产生了严重的挫折感。但是，这真的是用户的错误和需要承担的责任吗？我认为不是：“严格说来，我不是犯错，我只是不清楚我能做什么、以及应该怎么做的规则。”

由以上两方面的案例，我想已经可以初步回答程序员同学的问题了：“是的，简单总是好的，但是在交互过程中，事件永远是复杂的，所可能发生的情况的可能性永远是那么多的，不是你为他考虑的多，让他简单；就是他自己试验和受挫的经历更多，更复杂，体验更差”。

3、问题三、该如何做：

关于容错设计的三个境界：

1、保证不是我们自己的错：屏蔽会引起歧义的设计、本身不合理的设计，不让用户因为系统的设计缺陷而导致犯错。

2、把简单留给用户，把复杂留给自己：通过系统的优良设计约束和指引用户的操作，把出现错误的可能降到最低。

3、减小错误的代价，帮助用户做对：当用户还是犯了错误，通过设计引导用户走向正确的方向。

对交互设计师而言，第一条是本应遵守的设计底线，二三两条是设计时可供遵循的设计指南。其中的第三条，关于出现错误后如何帮助和引导用户做对，尚轩同学接下来会专门撰文探讨这个问题，此处暂不赘述，下面主要就第二条谈一些看法:

二、如何做到避免用户出错：

1、给予用户适当的行为约束——为用户封闭掉不正确的道路

这是Gmail的邮件处理区。

上图表示当没有选择任何一封邮件的时候，操作项被置灰，不可点选。这样在有效避免了误操作的同时，也展示和预告了当符合操作要求时，“更多操作”内提供的全部功能的内容。

下图则是已有选择邮件的时候，操作项全部激活为可用状态时的情况。对比上一张图未激活的状态，可以注意到除了激活与否的状态差别，还有其中的 “加注星标”功能在初始激活状态下是只有加注而隐藏了删除功能的、充分考虑了加注和删除功能的互斥性而予以隐藏。

通过用户的使用状态，通过有选择性的设置功能项激活、待激活的状态，以及功能项展示、隐藏的状态，是有效避免用户误操作的常用手段。这个考虑细心周到的设计在很大程度上预防了用户可能发生的操作失误。

2、给予用户必要的预判性错误提示——告诉用户，这样走可能会错

这是Msn的登录界面。

当光标定位于密码输入区时，如果此时键盘的大写锁被不小心打开了，界面会提示用户此时处于Caps　Lock处于启用的状态，很可能会出现密码输入的错误。

这样处理比用户输入完成点击提交之后再提示用户出了什么问题要来的友好和有效很多；比只是一味的批评用户 “你错了”从头至尾完全不告诉用户出了什么状况的界面要友好太多。

当用户的一个行为很可能会引发预见性的错误，越早提示用户，并给出可行性的建议，错误越容易被接受和改正，用户的损失也就越小。

3、告诉用户操作所处的状态和正确的操作方式——告诉用户，怎么走才对

Flickr的媒体上传页面。

对于用户在这个页面需要做什么、可以做什么有清晰的划分，对现在需要进行的、当前所处的操作阶段予以高亮显示，吸引人进行操作；对于还未进行到的操作阶段也预先做了一个介绍，很清晰的介绍了完整的任务流程。

让用户知道在一个流程之中，自己已经完成了什么，将要做什么，还有什么没有做和应该怎样做，才能使任务成功，是避免用户出错的很积极的一个应对方式。

让我们摒弃作为设计师的中高级用户视角，深入挖掘用户行为习惯和心智模型，真正从用户的角度去分析使用上可能会出现问题，通过系统的设计去尽量避免错误的发生——“把简单留给用户、把复杂留给自己”。About face3.0 第25章“错误、警告和确认”中讲到一条重要的设计原则：让错误成为不可能。很美好。以此与各位设计同仁共勉之。

对于搜索结果页的一些探索，看完这篇文章或许有一些启发。

其实最好的搜索结果页应该是能把最需要的信息给用户，这个值得探讨。。搜索结果的智能推荐需要大量的数据分析做支持。。扯远了。。。这篇文章描述的是如何规划搜索结果页的信息展示。。避免无用信息的堆砌干扰到重要信息展示~~值得借鉴思考。

很多网站都会非常关注购买行为的用户体验而忽略了如何促进用户去进行购买操作。其实对于用户来说只有当他决策了之后才会去进行购买的行为，那么我们首先要了解，怎么样能让用户更容易决策呢？

用户决策的最根本目的就是用最短时间找到最佳的选择，这个行为一般在搜索结果页就特别突出，因为我们面对页面上几十甚至更多的搜索结果集，这个时候决策的重要性就凸显了出来。

现在很多网站的搜索结果集非常的冗长，信息量很大，无法让用户一目了然，做出决策。

我经常听到需求方跟我说：请帮我在列表项突出xx信息。而当我问起理由的时候他通常会告诉我用户会用的到，或者是他认为用户觉得因为这个信息而影响决策。这个导致在我设计搜索结果页的时候，最初干净简洁的版本就变得越来越冗长，越来越多可用可看的信息，也导致css的同事们经常1px1px的压缩列表宽度，为的就是避免换行而造成的不必要的错位。

所以急需帮我们的搜索列表减减肥。

1.        那么减什么呢？

凸显关键信息，减少不必要的干扰

提取关键性信息

比如说机票列表项信息有很多，时间、机场、航空公司、舱位、航班、机型、价格、折扣、备注、燃油机建费、飞行时长、退改签、礼盒、日历展示的价格。对于这么多信息，我们如何去了解用户真正的关注点呢？

由这张热点图可以看出，用户始终在价格和时间上反复比较，所以在机票的搜索结果页中对于用户最关心的因素应该是价格和时间。我们在设计搜索结果页的时候就应该突出时间和价格两个特征。他们也同样关注如航空公司或者机型等信息，但是这些信息是否真正影响用户的决策呢？曾经有一个用户参加访谈时聊到，非常关注机型，可是当她参与眼动任务流时，在决策中却完全没有关注到机型信息。所以这种现象被称为“夸耀效用原理”：人们喜欢自己被包围在不必要的功能中 [来自《简约至上》] 。我们需要保留的是那些真正影响用户决策的关键信息。

2.        怎么减的“凹凸有致”？

对于一个搜索结果来说，关键性信息也许会有很多，那么如何更合理的组织这些信息，并且让它们呈现的更加有层次，使用户在搜索结果这个步骤中更易进行选择呢？

合理组织信息

所谓合理组织信息，就是将关键性信息以及辅助信息内容按照相关性、从属性进行区块化呈现。

比如一般的搜索列表项会包括重新搜索区域、筛选区域、主要产品区域、辅助特价区域。目前大部分网站对于这四个区域的块状划分还是比较清晰的，但是对于用户最关注的产品列表区域反而有些参差不齐，也是对设计师挑战最大的地方。

我们可以来看一个案例：

如果让你判断是否缺货，哪个图让你更能一眼看出呢？

在A中，将无货通知夹在价格信息下方，导致其关注度远远降低，无法被用户关注到。

B做的相对较好，他将到货通知放置在购买的位置上，使得用户在想要购买该商品时就能一下子看到无货的通知；

C不仅在购买位置上放上了到货通知的按钮，并且还在图片区域明显标志使得该信息更加明显。

所以从这个细节点就能看出，合理组织信息，能够帮助到用户更快速更有效地了解产品信息避免给用户造成困惑。那么如何才能合理的组织信息呢？我们可以通过一些案例来进行分析。

a)      将信息按照不同的功能模块来组织构架

比如，机票信息，分为航程信息、航班信息、舱位信息，在信息中，和航程信息相关的，比如出发城市到达城市，出发日期到达日期等都是航程类信息；航班类信息包括，如机型、起抵时间、起抵机场、航空公司；舱位信息包括，如价格、折扣、备注、退改签等。那么在组织这些信息的时候需要考虑信息的从属和相关性，应该把其对应呈现，如下图：

将来如果有任何其他信息的加入可以考虑对应信息类别来放置其位置。

b)      做成纵向列表并且结构化会更容易比较

如下图所示：B和A均为纵向列表，但是B的产品信息呈现方式是按照从上至下从左至右的顺序组织，而A的产品信息是经过结构化分类之后而分栏展示的。很明显用户能在A中进行上下不同的信息的对比。

c)      避免不必要信息的重复显示

如携程列表项中燃油机建和飞行时长信息，在列表项中重复出现，在用户访谈中，用户基本对于灰色条目并没有任何关注度，因此作为辅助型信息相对比较重要的燃油机建信息更换位置，删除飞行时长。

d)     某些辅助信息可以隐藏显示，但保留入口

如上图，赠品作为辅助信息，也许未必能影响主流用户对于产品的决策，但是做成小的icon hover上去显示出其赠品，也给予喜欢查看赠品信息的用户保留了一个显示的区域，又不干扰用户对主要信息的获取。

信息呈现有层次

有很多次，需求方经常会要突出某个重要信息，而要求设计师增大字体，增加颜色或者加粗等等行为，但是经验表示，当你想突出某一个信息的时候，或者加粗或者做明显的颜色都行，但是当信息多的时候，那么你这些举动也许完全没有帮助。所以如何呈现信息的层次性不仅需要删减非关键信息，还需要视觉上做合理的设计。

e)      降低辅助信息的显示层级从而来突出关键性信息是一个好方法。

上图中，虽然信息层级是从左到右按照用户浏览方向依次减弱其重要级别，但是右侧各种花哨的icon和信息内容反而影响到用户对于评价和成交信息的关注度。

f)      块状化列表项

使得列表块状化的方式可以通过：框线或者空间间隔等各种视觉方式来实现。

g)      最重要的信息层级请保留给用户操作区

上图所示，在购买区域明显的颜色区别，使得用户一目了然。

3.        考虑不同产品和不同人群的差异性

不同的产品类型或者不同的用户也会有不同的关键性信息。所以我们在减肥的时候需要对症下药，去了解产品的特点也需要去了解用户的关注点。

我们还应该要考虑到不同产品类型。就以淘宝为例，不同行业的产品会有完全不同的信息展现。就好比dvd、围巾和服装产品对于图片的关注度是由低到高，因此从下图中可看出，它们的搜索结果，对于图片的尺寸处理也是从小到大的。

度假产品的人群是非常多样化的，有自由行、团队游、邮轮、当地游等等。每一类型的产品所展示的信息是各有特色的，因此携程在对度假产品搜索结果页进行处理的时候，是根据不同的产品类型，做成了不同的tab切换模式，来进行合理的人群分流。

总结：当我在设计搜索列表的时候，虽然尽量的给搜索列表减肥，可是它的顽固性完全不亚于真正的减肥。在不经意间，不停有人提出的增加这个信息那个信息的要求，慢慢地使搜索列表的减肥不仅不成功，反而反弹的更凶猛。这个或许就是无法协调的业务型需求和用户型需求的永久矛盾。所以减肥不仅仅是交互设计师需要考虑的项，而是更多部门协作更多部门理解的大话题。

本文作者：S++　转载请注明来自：携程UED

一、Pinterest简介

Pinterest，Pin（图钉）+Interest（兴趣），把自己感兴趣的东西用图钉钉在钉板（PinBoard）上。美国的一家创办于2011年的正迅速成长为受世界瞩目的图片视觉社交网站。 Pinterest页面底端自动加载无需翻页功能，让用户不断发现新图片。为用户提供在线收藏和分享Pinterest视觉艺术图片的服务。

该项目的创意来自于创始人 Ben Silbermann 为他的女朋友寻找订婚戒指之时。他发现了很多还算中意的戒指，但又需要反复比较，于是他就开发了 Pinterest，把它们随手贴在同一个页面上。（Via）

目前Pinterest也支持视频的分享，之前Pinterest获得了最新一轮2000万美金的投资，据传估值达到了2亿美金，国内类Pinterest服务又成为了一个热点，今天和大家分享一个对于Pinterest的理解和想法。欢迎大家通过微博 @web20share 和我们分享您的观点。

二、Pinterest功能介绍

先介绍几个Pinterest里面的核心功能吧：

• Pin：字面意思是图钉，你可以理解为把一张图片（或视频）贴到一个板（Board）上，直白来理解就是收藏一个图片（或视频），每一个分享的图片的展示方式如下图，左侧是这个Borad上的图片（或视频）缩略图，右侧是图片或视频详情；
• Repin：你看到别人分享的一个Pin，觉得不错，可以拿来贴在自己的板子（Board）上，类似于转发的意思，你Repin之后，专注你的人，或者关注你Board的人便可以看到这个图片（或视频）
• Like：自己喜欢的图片或视频，类似于私藏，个人可见；
• Borad：上面提到的板子，可以理解为图片（或视频）的组，就是一个板子（Borad）上可以贴很多张照片（或视频）

所以对于一个用户而言，其可以做几个操作：一是Pin，二是Repin，三是关注，这里面用户可以关注人，也可以关注用户的某个Board，用户通过Borad来整理自己感兴趣的内容，其他用户通过Repin的方式传播自己感兴趣的内容，并且重新组织到自己的Board。

用户可以创建共享的Borad和其他朋友一起来协作将内容收藏到一个Board。

另外Pinterest有一个公共的类别，Pinterest会提示用户将自己的Board添加到其公共类别以便于其他人通过分类浏览这些内容。

三、Pinterest模式分析

1.人和信息的关系：人-Board-图片，Board其实就是兴趣，只不过兴趣的载体是图片。用户可以关注人、关注一个人默认等于关注这个人所有的Board。其实是Pinteret将人定义为一个兴趣组（这些兴趣组体现为Board），Pinterest关注的最小的维度其实是Board。

2.展示方式：大家熟知的瀑布流，这种方式真是很好的解决的图片信息的展示问题，对于各种大小的屏幕自动适应的方式，有人称之为将手机上的展示方式直接移植到Web上，相信这种展示方式会被很多网站所借鉴。

3.信息的有序组织：每个人将图片整理至Board的过程其实是一种将信息有序化的过程，这种过程直接在传播中完成，这种由用户重新组织的兴趣内容组将很有价值，也会吸引更多人的关注。Pinterest提供的协作功能也允许多个用户来协作一个Borad的内容。

四、商业模式

目前大家普遍比较认同的方式就是和电子商务相结合的方式，不过在我看来，只要通过一种方式能够逐渐沉淀用户的兴趣，这种商业价值可能会有多种的回报方式。比如基于兴趣的广告。

五、国内类Pinterest网站

• 拼范网：http://www.pinfun.com/
• 迷尚网：http://www.mishang.com/
• 凡客达人：http://star.vancl.com/
• 美丽说：http://www.meilishuo.com/
• 蘑菇街：http://www.mogujie.com
• 淘宝哇哦：http://wow.taobao.com
• IDsoo：http://idsoo.com/
• Topit：http://topit.me/
• Mark之：http://markzhi.com/
• 布兜：http://www.budoou.com/
• 堆糖：http://www.duitang.com/
• 花瓣：http://huaban.com/
• 码图网：http://www.markpic.com/
• 新鲜网：http://www.xinxian.com/
• 易惊喜：http://www.ejingxi.com/

好吧，每次介绍国外一个颇受关注的模式，总会列出国内的列表，当然上面只是个不完全列表，实际应该更多，并且最近应该也还会有不少会出来。大家看了上面的介绍会发现其实有一些只是形式象而已（当然也有一些诚心拷贝），大家都在学习瀑布流的展示方式，当然借鉴模式去发现自己的方式也是可以的，但是千万不要在模仿中迷失了自己。

六、问题与挑战

国内目前类似的服务也越来越多了，除了上面的信息关注机制和展示方式以外，如果这些只是表面的形式，那这些Pinterest服务谁能胜出比拼的应该是什么呢？个人列出一些觉得比较重要的点：

1.如何吸引核心用户群（UGC用户）

本质上还是一个UGC的网站，这种形式固然可以吸引用户来，但是从站外贡献内容的还是极少的比例，如何建立这种分享驱动力并且构建合适的激励机制的需要考虑的？

2.分享图片、发现图片本身不是需求，用户想要得到什么？

个人觉得还是如何解决后续用户的需求的问题，除了发现图片和视频，用户后续的需求是什么需要去考虑。

3.商业模式

如何将用户的需求和商业模式很好的结合。国内最成功的应该是美丽说 但是其实不是标准的pinterst形式，其更关注其用户群的需求，展示方式其实其中的一部分而已，通过满足用户群的需求来吸引这部分用户才是核心，那是否以为着需要更好的关注自己的用户群呢？

七、小结

Pinterest的出现确实给我们带来了很多有价值的启发，比如对于图片信息的展示，未来会是个读图时代，因为图片能够承载的信息更多，但是纯粹的展示方式还不能够支撑一种商业模式，还是需要专心思考，用户是谁，除了展示效果以外，为用户提供的价值是什么，当然也要考虑可能的实现价值回报的方式。

来自：

简介

如果你经常网上冲浪，这样参差不齐的多栏布局，是不是很眼熟啊？

类似的布局，似乎一夜之间出现在国内外大大小小的网站上，比如 Pinterest (貌似是最早使用这种布局的网站了)，Mark之，蘑菇街，点点网，以及淘宝最新上线的“哇哦” 等等，倒是很流行哈~ 在淘宝即将上线的众多产品中，你还会大量看到这样的形式呢。

这种布局适合于小数据块，每个数据块内容相近且没有侧重。通常，随着页面滚动条向下滚动，这种布局还会不断加载数据块并附加至当前尾部。所以，我们给这样的布局起了一个形象的名字 — 瀑布流式布局。

几种实现方式

随着越来越多设计师爱用这种布局，我们作为前端，要尽可能满足视觉/交互设计师的需求。所以，我们整理了下这种布局的几种实现方式，有三种:

1) 传统多列浮动。即 蘑菇街和哇哦 采用的方式，如下图所示:

• 各列固定宽度，并且左浮动；
• 一列中的数据块为一组，列中的每个数据块依次排列即可；
• 更多数据加载时，需要分别插入到不同的列上；
• 线上例子。

优点:

• 布局简单，应该说没啥特别的难点；
• 不用明确知道数据块高度，当数据块中有图片时，就不需要指定图片高度。

缺点:

• 列数固定，扩展不易，当浏览器窗口大小变化时，只能固定的x列，如果要添加一列，很难调整数据块的排列；
• 滚动加载更多数据时，还要指定插入到第几列中，还是不方便。

2) CSS3 定义。W3C 中有讲述关于多列布局的文档，排列出来的样子:

• 由 chrome/ff 浏览器直接渲染出来，可以指定容器的列个数，列间距，列中间边框，列宽度来实现；

    #container {        -webkit-column-count: 5；        /*-webkit-column-gap: 10px；        -webkit-column-rule: 5px solid #333；        -webkit-column-width: 210px；*/        -moz-column-count: 5；        /*-moz-column-gap: 20px；        -moz-column-rule: 5px solid #333；        -moz-column-width: 210px；*/        column-count: 5；        /*column-gap: 10px；        column-rule: 5px solid #333；        column-width: 210px；*/    }

• column-count 为列数； column-gap 为每列间隔距离； column-rule 为间隔边线大小； column-width 为每列宽度； 当只设置 column-width 时，浏览器窗口小于一列宽度时，列中内容自动隐藏； 当只设置 column-count 时，平均计算每列宽度，列内内容超出则隐藏； 都设了 column-count 和column-width，浏览器会根据 count 计算宽度和 width 比较，取大的那个值作为每列宽度，然后当窗口缩小时，width 的值为每列最小宽度。这边其实很简单，简易自己尝试下，详细可参考https://developer.mozilla.org/en/CSS3_Columns 中的说明。
• 线上例子。

优点:

• 直接 CSS 定义，最方便了；
• 扩展方便，直接往容器里添加内容即可。

缺点:

• 只有高级浏览器中才能使用；
• 还有一个缺点，他的数据块排列是从上到下排列到一定高度后，再把剩余元素依次添加到下一列，这个本质上就不一样了；
• 鉴于这两个主要缺点，注定了该方法只能局限于高端浏览器，而且，更适合于文字多栏排列。

3) 绝对定位。即 Pinterest ，Mark之，KISSY 采用的方式:

• 可谓是最优的一种方案，方便添加数据内容，窗口变化，列数/数据块都会自动调整；
• 线上例子。

缺点:

• 需要实现知道数据块高度，如果其中包含图片，需要知道图片高度；
• JS 动态计算数据块位置，当窗口缩放频繁，可能会狂耗性能。

KISSY.Waterfall 实现思路

KISSY 的 Waterfall 组件主要包含两个部分，一个是对现有数据块进行排列计算各自所在的位置； 二是下拉滚动时，触发加载数据操作，并把数据添加到目标容器中。

1) 数据块排列，算法步骤简述下:

• 初始化时，对容器中已有数据块元素进行第一次计算，需要用户给定: a，容器元素 — 以此获取容器总宽度； b，列宽度； c，最小列数； 最终列数取的是容器宽度/列宽度和最小列数的最大值，这样保证了，当窗口很小时，仍然出现最小列数的数据；
• 获得列数后，需要保存每个列的当前高度，这样在添加每个数据块时，才知道起始高度是多少；
• 依次取容器中的所有数据块，先寻找当前高度最小的某列，之后根据列序号，确定数据块的left，top值，left 为所在列的序号乘以列宽，top 为所在列的当前高度，最后更新所在列的当前高度加上这个数据块元素的高度，至此，插入一个元素结束；
• 当所有元素插入完毕后，调整容器的高度为各列最大的高度值，结束依次调整；
• 性能效率上的注意点: a，如果当前正在调整中，又触发了 resize 事件，需要将上次调整暂停后执行这次调整(见 timedChunk 函数)； b，resize 触发会很频繁，可以将回调函数缓存一段时候后执行，即当这段时间内多次触发了resize事件，但回调函数只会执行一次(见 S.buffer 函数)
• 感兴趣的可以参见源码。

2) 异步加载数据，前面讲的是如何对容器中已有元素进行排列，但很多情况下，还需要不断加载新数据块，为此专门设计了一个独立的模块 KISSY.Waterfall.Loader，其实这个功能就更简单了，仅包含两个步骤:

• 绑定滚动事件，并确定预加载线高度值，即滚动到哪个高度后，需要去加载数据，其实这个就是列的最小高度值，这样当前滚动值和最小高度值比较一下即可判断出来，是否要触发加载数据；
• 加载数据，为了不对数据源做太多限制，完全由使用者自己决定数据源从哪边获取和其格式，这样更好的方便用户使用。为此，该组件只提供一个load(success，end) 接口，怎样load 由用户自己去定义，而其中的 success/end，分别给出如何添加新数据(suceess 即同 addItems)/如何停止加载的接口。这样真是太方便了~~
• 感兴趣的可以参见源码。

KISSY.Waterfall 示例和文档

看到这边，是不是很想试用一下~~ 嗯嗯，这里给出一些相关学习资料和示例，以供参考:

• Waterfall API 文档，相关构造器，配置项，方法都在这里；
• 示例，包含静态和动态两种。

欢迎试用和提出意见~~

最近在做iphone端Web App的项目。由于产品形式新颖，技术环境不成熟，公司给与了较宽松的研发时间。在一个月的交互设计阶段，每个环节都得到多次讨论推敲，我从中感悟颇多。导航系统的设计是一个比较典型的点，拿出来与大家分享讨论一下。
导航系统所遭遇的挑战

iphone Native App较常见的导航如下图所示：

手机屏幕底端：A、B、C、D四个tab组成该Native App的全局导航，这是我们经常见到的tab导航栏。

手机屏幕顶端：主要有四种形式。第①种形式是在该位置中心显示产品的logo；也可以将logo适当调整位置，将常用操作或快捷入口放在该位置的右侧。第②种形式是在该位置有两或三个tab选项。第③种形式是在该位置中间显示当前任务标题，在左右两侧放置导航控件或功能控件。第④种形式是在该位置放置搜索框。

与以上的Native App导航方式相比，Web App导航方式有着巨大的不同，如下图所示：

Safari浏览器的工具栏将一直占据着屏幕的底端位置，全局导航只能被动移动到屏幕的顶端位置。这是影响Web App导航设计的最重要因素。

如果产品的功能比较少，且没有特别要突出的功能的时候，可以设计成上图中第①种导航方式。此时存在的问题是如何表现出产品的品牌，毕竟在Safari浏览器登录某网站比运行一个Native App给人的品牌认同感弱很多。

如果将产品logo表现出来，且产品需要将用户常用功能突出（比如刷新功能或者发布入口），就需要设计成上图中的第②种导航方式。

如果在A功能板块下，还需要设置子类别选项，则导航栏中又多一组tab。此时的导航方式就如同上图中的第③种了。

当然，在执行某一项任务的时候，全局导航可以暂时“归隐”，只保留一行标题栏和左右两侧的导航控件或功能控件。如上图中第④种导航方式所示。

在该产品设计中，为方便用户在各功能板块之间快速省力地切换，设计师希望全局导航栏可以保持长久悬停，不要像一般wap网页似的让导航随网页滚动消失。这样的话，基于浏览器的Web App 导航系统便捷性就和Native App相媲美了。

然而，浏览器工具栏将全局导航逼到了屏幕的顶端，却又造成了导航头部过于沉重的问题。如下图所示：

如果将logo栏中的常用功能（例如刷新或发布入口）和全局导航都设计为悬浮停留的形式，内容区的信息展示空间就比Native App减少了一行的高度，如上图中的①。而且，某些页面需要在全局导航的下方出现二级导航；悬停不动的3行导航大大吞噬了屏幕本来就很宝贵的内容显示空间，如上图中的②。

让用户在如此狭小的空间不得不频繁滑动屏幕浏览信息，这样的体验太糟糕了。这个严重的问题很让设计师困扰，因此需要重新设计一下导航系统。设计过程主要包括：优秀竞品分析、方案遴选。

优秀竞品分析

首先，分析对比了三款优秀的Web App：Google+、FT Web App、Twitter的导航方式。浏览环境均为iphone Safari浏览器。

1.Google+

导航系统特点：

￭全局导航单独形成一个页面，其他页面不出现全局导航；

￭导航栏沿用了ios系统原生控件的形式：标题+导航或功能控件；

￭标题栏在页面中悬停不动

优点分析：

保证了每个信息浏览页面的导航栏简洁轻薄，尽量少的占用信息详情的显示空间；保证了其核心功能（此处是微博浏览功能）的良好使用体验。

缺点分析：

全局导航隐藏较深，降低了用户在不同功能板块快速切换的便利性；全局导航隐藏较深，用户看不到其它板块功能，大大降低了用户点击使用其他功能的可能性。

2. FT Web App

导航系统特点：

￭Safari浏览器URL一栏一直悬停存在，并将品牌文字FT Web App显示在顶端;

￭全局导航被隐藏起来，点击功能键后在页面顶端出现；

￭二级导航出现在页面顶端；

￭全局导航和二级导航由于新闻板块数量较多，都采取了单行空间不完全呈现的方式，可滑动选择其中某一项；

￭所有导航随页面滚动，不在屏幕中保持悬停；

优点分析：

FT Web App导航设计最大的优点就是繁重导航的轻量化处理。全局导航和二级导航中的新闻板块都非常多，若将这些板块都展示出来，恐怕要占用屏幕的一半显示空间。FT Web App于是将全局导航隐藏在一个功能键之后，二级导航也只给了一行的显示空间。

缺点分析：

展示给用户的导航只是其全部新闻板块的冰山一角，无法给予用户全部概况浏览的机会，也就无法很好的激励用户去尝试被隐藏的新闻版块；同时，用户寻找某一个新闻版块或者在页面底端回到页面顶端的操作成本略高。

3.Twitter

导航设计特点：

￭全局导航只有一行，品牌展示浓缩在主页图标中（Twitter小鸟图标）；

￭全局导航一直保持在屏幕顶端悬停不动，不随页面滚动而滚动；

￭二级导航在点击全局导航某tab后，以菜单列表形式出现。

优点分析：

在屏幕顶端悬停不动的全局导航，可以方便用户在不同的功能板块之间快捷切换，降低了用户的信息寻找成本；Twitter Web App的导航只有一行，为用户保证了尽量大的正文内容显示空间。

缺点分析：

一些常用的功能键被隐藏在二级导航中（比如新信息发布入口），一方面增大了用户的寻找成本，另一方面降低了这些常用功能对用户的激励使用效用。

基于对以上三款Web App产品导航系统的分析，设计师对目标项目的导航系统设计形成了以下框定：

￭全局导航方便用户快速寻找以及功能板块间的切换；

￭导航尽量轻薄化处理，尽量保证足够的正文内容区显示空间；

￭将用户经常使用的功能键呈现在前面。

方案遴选阶段

基于项目的实际需要以及对竞品分析的思考总结，设计师尝试了3款导航设计方案，并对每一款方案的优劣之处进行了详细分析。

导航设计方案一

设计说明：

￭ ABCD是产品的四个功能板块，组成全局导航。

￭ 全局导航在屏幕顶端保持悬停不动。

￭ E是新消息发布入口，属于用户常用功能。

￭ E采用半透明显示方式。

￭ E停留在屏幕的右下角

该方案的优点：

屏幕顶端只有全局导航一栏，导航的轻量化为正文内容区节省了尽量大的显示空间；全局导航悬停不动，可以便于用户快速切换到不同的功能板块。

该方案的缺点：

右下角的新信息发布入口致使浏览页面不够清爽，会对用户造成一定的视觉干扰；新信息发布入口没有必要在任何页面都显示，于是可寻性出现了危机；品牌logo无法显示，品牌感较弱。

导航设计方案二

设计说明：

￭ E是新消息发布入口，属于用户常用功能。

￭ ABCD是产品的四个功能板块，组成全局导航。

￭ 屏幕顶端的两行导航栏在用户刚进入页面的时候出现，在用户滑动屏幕浏览信息的时候消失。

￭ 屏幕右下角半透明功能键在导航栏消失后出现，点击该键导航栏出现。

该方案的优点：

浏览信息的时候导航栏消失，为用户提供提供了最大的正文内容显示空间；可以显示logo，品牌感较强；新信息发布入口的可寻性较好。

该方案的缺点：

屏幕右下角半透明功能键致使浏览页面不够清爽，会对用户造成一定的视觉干扰。

导航设计方案三

设计说明：

￭ E是新消息发布入口，属于用户常用功能。

￭ ABCD是产品的四个功能板块，组成全局导航。

￭ 屏幕顶端的两行导航栏在用户刚进入页面的时候出现，在用户滑动屏幕浏览信息的时候第一栏向上消失，第二栏上移至顶部保持悬停不动。

￭ 手动下拉全局导航栏，可以下拉出第一栏导航。

该方案的优点：

浏览正文信息的时候，仅显示全局导航一栏，做到了导航的轻薄化；全局导航悬停不动，可以便于用户快速切换到不同的功能板块。

该方案的缺点：

下拉全局导航时，可能会有误操作的危险，虽然可能性很小。

综合以上的分析，考虑到正文内容区显示空间的大小、对产品的操作便利性以及产品品牌感三方面因素，最终决定将方案三作为导航设计的基本形式，并继续进行进一步丰富细化。

总结：

浏览器的工具栏一直占据着屏幕的底端位置，全局导航只能被动移动到屏幕的顶端位置。如何平衡操作的便捷性与正文信息显示空间最大化的关系，是Web App导航设计的关键所在。

最佳方案总是权衡的结果。每一款设计方案解决某些问题的同时也会产生新的问题。此时设计师需要知道哪些功能是最重要、优先级最高的，保证核心功能的良好用户体验是评判设计方案的重要准绳。