“无限滚动加载”适用于你的产品吗？

在家一天天宅着，倒仍然能对周六周日有清晰的概念，也真是个奇迹。

今天带来一篇关于无限滚动加载的简短译文。其实这事儿，以前在微博上也吐过一阵的槽，印象最深的就是有次在一个什么网站上想点页脚里的“关于我们”，真心点不着，每每要点的时候上面自动加载的内容就顶下来，没完没了...当时就愤恨的琢磨着你们要这页脚有毛用啊？这次看到这篇文章，觉得里面有不少能引起自己共鸣的内容，所以拿过来做，希望也能给各位朋友带来些有用的东西吧。走着。

这里进入译文。怎样通过更友好的方式来呈现一系列的数据内容，包括文章、链接、图片、搜索结果等等——对于设计师来说，这不是一件很轻松的事。在这方面，页码导航(pagination)是一种经过时间验证的、还算值得信赖的解决方案。

不过最近几年，我们可以发现越来越多的网站开始使用无限滚动(infinite scrolling)的方式来呈现内容了——当用户浏览到页面底部时，传统意义上的“下一页”数据会自动加载，并输出到当前页面中。

对于某些类型的网站或移动应用来说，无限滚动确实是一种不错的模式；但在在某些情况下，它也会造成灾难性的后果。

我们先来看一下无限滚动加载的优缺点。

优点

1. 有效的降低了界面复杂度，节省了空间：我们不再需要臃肿复杂的页码导航链接或按钮了。
2. 对触屏设备来说，交互方式更符合直觉：在移动应用的交互环境当中，通过向上滑动进行滚屏的操作已经成为最基本的用户习惯，而且所需要的操作精准程度远远低于点击链接或按钮。
3. 更高的参与度：以上两点所带来的交互便捷性可以使用户将注意力更多的集中在内容而不是操作上，从而让他们更乐于沉浸在探索与浏览当中。

缺点

1. 有限的用例：无限滚动的方式只适用于某些特定类型产品当中一部分特定类型的内容。例如，在电商网站当中，用户时常需要在商品列表与详情页面之间切换，这种情况下，传统的、带有页码导航的方式可以帮助用户更稳妥和准确的回到某个特定的列表页面当中。
2. 额外的复杂度：那些用来打造无限滚动的JS库虽然都自称很容易使用，但你总会需要在自己的产品中进行不同程度的定制化处理，以满足你们自己的需求；另外这些JS库在浏览器和设备兼容性等方面的表现也参差不齐，你必须做好充分的测试与调整工作。
3. 再见了，页脚：如果使用了比较典型的无限滚动加载模式，这就意味着你可以和页脚说拜拜了。最好考虑一下页脚对于你的网站，特别是用户的重要性；如果其中确实有比较重要的内容或链接，那么最好换一种更传统和稳妥的方式。千万不要耍弄你的用户，当他们一次次的浏览到页面底部，看到页脚，却因为自动加载的内容突然出现而无论如何都无法点击页脚中的链接时，他们会变的越发愤怒。
4. SEO：集中在一页当中动态加载数据，与一页一页的输出相比，究竟那种方式更利于SEO，这是你必须考虑的问题。对于某些以类型网站来说，在这方面进行冒险是很不划算的。
5. 关于页面数量的印象：其实站在用户的角度来看，这一点并非负面；不过，如果对于你的网站来说，通过更多的内容页面展示更多的相关信息(包括广告)是很重要的策略，那么单页无限滚动的方式对你并不适用。

了解了相关的优缺点，接下来我们看一看我个人认为在无限滚动的运用方面比较到位的两个网站。

Twitter

Twitter适合采用无限滚动加载的一个重要原因，就是每个内容单元都很短小精炼，其本身就是内容整体，用户不需要在“列表索引”与“内容详情”之间切换就可以获取全部信息，而且当鼠标悬停在某个内容条目范围内的时候，对应的操作(回复、删除、收藏等)就会呈现；所有内容与功能全部集中在当前的上下文环境中。

Tumblr

默认情况下，Tumblr是通过无限滚动的方式加载内容的，但他们在设置当中为用户提供了禁用无限滚动的选项，这种做法非常体贴。Tumblr的产品特色决定了其内容类型的广泛性，不同类型的用户所关注的内容在形式方面可能有很大的区别；允许用户自主设置内容加载方式的做法可以照顾到不同的用户群体。

默认的无限滚动方式

用户可以选择是否启用无限滚动

禁用后，回到页码导航的传统方式

下面是我个人认为不大适合采用无限滚动的例子。

Bing的图片搜索

与Google相仿，Bing在图片与视频的搜索结果页面当中采用了无限滚动加载的做法。不过当用户点击某张缩略图从而进入图片详情页面后，再回到搜索结果列表时会失去之前的定位，这使得用户必须重新滚动页面，寻找点击之前的位置。如果你的关键词会产生大量的搜索结果，这种方式将给你带来极大的不便。(现在Bing已经改变了这一做法，当用户点击了搜索结果中的缩略图时，会直接在当前页面输出包含大图及相关信息在内的弹出层；新的流程使用户不会再脱离当前环境 - 译者C7210小注)

YouTube

我爱YouTube的整体设计，同时也理解他们不断修改和调整设计方案的初衷，不过他们最近将首页的页码导航改为无限滚动的做法还是让我有些不爽。和Bing的问题类似，YouTube的实际内容(视频)是在一个独立的页面中的，用户显然不希望在看过一个视频后回到列表页面却发现列表重新加载了。

另外有些尴尬的是，YouTube的无限滚动加载不是那么的“自动”，用户需要点击一个按钮来使列表加载更多的视频内容；从某种角度上讲这不算坏，因为它确实是将控制权交给了用户，实现了类似前面提到的Tumblr的做法，但直接将无限滚动与手动触发结合在一起的形式多少有些不伦不类。

最佳实践

希望你能通过以上这些内容了解到自己的产品是否适合采用无限滚动加载的方式。如果答案是肯定的，那么下面这些要点也许可以帮助你避免掉实践当中的一些关键问题：

1. 提供降级方案：前端开发人员要考虑到在特殊环境下JavaScrit无法正常运行的状况，提供平稳降级的解决方案。
2. 可设置：如果可能的话，考虑向用户提供设置选项，方便他们选择最适合自己的浏览方式。这会让用户感到贴心，从而提升对你的产品的满意度与忠诚度。
3. 视觉反馈提示：在自动加载新内容的时候，要向用户提供必要的视觉反馈，例如各种能够表达“加载中”的动画效果，否则用户将无法了解当前的状况；在没有视觉提示的情况下，如果加载时间过长，会让用户误以为接下来不再有内容了。
4. 帮用户定位：不要因为用户访问内容详情并点击了浏览器上的回退按钮就失去掉之前的列表位置。如果确实没有办法做到，而这一点对你的产品又很重要，那么还是考虑传统方式为好。
5. 测试：使用目标用户群有可能用到的各种设备进行测试，检验无限滚动加载方案的实际表现。