带页码的翻页体验与设计比较

本文引用地址：http://www.junchenwu.com/cgi-bin/mt-tb.cgi/482.1387214387

别看翻页就占那么点儿地方，它体现的是市场的策略、程序的算法和交互设计。我选择了 Amazon、Google、Flickr、新浪和淘宝这五个网站，体验他们的翻页设计。这几个站点应该还算有代表性，Amazon 是国外购物网站，Google 是搜索引擎，Flickr 是 Web 2.0 和 Yahoo 的代表，新浪是中国门户，淘宝是国内购物站点（同时还拥有优秀的设计团队）。

Amazon 商品列表页的翻页
是五个网站中唯一一个区分访问过、没访问过的链接的颜色；
不需要“上一页”、“下一页”的时候就不显示；
第一页的链接永远存在；
告知用户列表总数量和当前显示的数量（Amazon有些页面将数量显示在列表顶部）；
不提供所有的页，上图中 400 页是极限，400 页之后的内容可以通过分类选择来缩小范围（同时给出提示）。

Google 搜索结果的翻页
富有创意的设计；
不需要“上一页”、“下一页”的时候就不显示；
“上一页”“下一页”的链接区域很大，容易点；
不提供所有的页，上图中 100 页是极限，100 页之后的内容或许可以更换关键词重新搜索，但是没有提示。

Flickr 照片列表的翻页
“上一页”“下一页”永远显示，但不同情况显示不同样式；
按了“上一页”或“下一页”之后则边框加粗（成为重点），引导你继续往下点；
告知用户列表的总数量；
数量少得情况下，提供了“最后一页”的链接（图上没有）；
可以访问到所有的页，可惜如上图所示超过一定的页码，显示上有问题（IE 和 FF 都这样）。

新浪文章留言部分的翻页
新浪评论部分的翻页，Ajax 可以拖动翻页（显摆用的）；
永远提供“第一页”“最后一页”“上一页”“下一页”的链接，但是样式基本一致没有差别；
告知用户列表的总数量；
提供批量翻页（“上 10 页”）。
但是在新浪博客（新浪比较有代表性的新产品）中，我们也可以看到以下相对比较粗糙的翻页：

新浪博客的翻页
给出了“最后一页”的链接，直接显示为“第 n 页”，如上图中的“第 7 页”；
在单个博客页面上的翻页，以“>>”作为下一页，而不是常见的“>”；
提供了批量翻页（“上 5 页”）。

淘宝商品列表的翻页
永远显示“上一页”“下一页”，并且状态和形状有区分；上一页使用率较低，所以设计的较小；
永远提供“第一页”“最后一页”的链接；
提供页面的跳转，但是默认值为当前页；
在列表的顶部右侧提供了一个简化的翻页，并且与底部的翻页设计一致。

小结
必须提供“上一页”和“下一页”的链接，并根据状态和使用率区分设计；
数据量大且更新快的情况下，并且当列表按照特定排序时，一定要提供返回“第一页”的链接；“最后一页”的链接根据访问情况而定；
突出当前页的数字，并且尽量使页码容易点击（不要紧紧地靠在一起），也不要一下子把所有页码都显示出来；
一般不需要在列表的上下都提供翻页，增加程序负担并且干扰视觉；淘宝列表顶部提供的简化的翻页想法不错，但不知道使用率如何；
批量翻页是无意义的（但是可以增加 PageView），可以通过优化页码排列来替代；比如在当前页的左右两侧各提供一定数量的页码；
对于“第一页”和“最后一页”的链接，如果是在页码序列中显示，一般会附带显示第二页和最后第二页的链接，比如本文中的淘宝翻页的截图，显示为“1 2 ... 96 97”。如果单独提供，可能视觉上会以为这不是页码序列的一部分，特别是最后一页的数字，用户可能没有概念；
对于用户比较熟悉的内容，或者用户自己的内容，尽量提供“最后一页”的链接，比如 Flickr 对于个人照片就是这样处理的（文中的翻页取自某个 tag 的照片）。
如果可以通过数据确定用户的行为是较为随意和没有目的性的浏览，那么提供多种方式的翻页很有必要，比如提供跳转到固定页码。比较理性的行为，不会使用直接跳转到某页，因为无法知道那里是什么。

Shark 在白鸦的那篇淘宝的体验文章中回复到“有些东西出现在页面上是有很长的故事的，不便多说了。”我想来想去，写本文并且截图只是看看这些公司在细节上面是怎么处理的、是否用心设计，不存在绝对的对错。

数据很重要，我曾经做过一个活动广告，点击率大约是 1%，后来在广告上增加了“点击查看详情”，并且采用默认的蓝色加下划线的链接形式，点击率提高到了 10% 左右。

转：互联网的夫妻老婆店模式

互联网是有趣的行业，在这个行业里面，或许诞生了和街边的零售业一样多的夫妻老婆店。一对夫妻，做一样适合互联网模式的产品，并且把它发展成为一个伟大的公司，在互联网的世界里，一次又一次的出现，好像并不完全是巧合。

Six Apart

最近的一家夫妻老婆店，估计最因此而著名的，或许算是Six Apart。这家以MovableType起家的互联网公司，最初就是丈夫Ben和妻子Mena在自己的家里写出来的。Mena和Ben是高中同学。 Mena喜欢写东西，她在2000年的时候就开始写blog，名字叫作Dollarshort.org。但她一直苦于没有一套好一点的blog写作软件，于是就逼着他的程序员老公Ben为她写一个这样的软件。Ben就花了大量的时间，写一个专门让老婆写blog的软件。这个软件让Mena很满意，一直用，一直让Ben来修改。这个软件起名叫做MovableType。他们后来决定把这个软件放在互联网上面让Mena的朋友们也可以下载。在 MovableType放在网上的第一个小时，就有100 多人下载。在2003年，他们把以前的兴趣变成了一家公司：Six Apart。公司的名字也好似小两口甜蜜的生活：他们两个的生日相差六天，所以他们的公司就叫做：相隔六天。在此之前，他们一直把自己的工作是室叫做：Mena and Ben。他们让我开始有这个"夫妻店"的想法。

eBay?

另外的一家夫妻老婆店估计就是eBay。浪漫版的eBay的创始的故事是这样的：1995年，Pierre Omidyar和他的未婚妻Pam Wesley夫妇从波士顿搬家到了硅谷。当时Pierre的妻子是一个收集PEZ dispensers的爱好者，但是在硅谷找不到其他的收藏者，就问老公能不能帮她想个办法（我知道现在也没搞明白什么叫做PEZ Dispenser，仅仅在客齐集在eBay总部所在的那幢楼的底楼看到很多标着这个名字的东西）。Pierre想到互联网或许是个方法，所以就有了AuctionWeb.com，也就是后来的eBay。虽然后来Pierre确认最初的故事并不见得这么浪漫，但这个故事无疑是最让人觉得温暖的一个版本。

Cisco

最近在读《世界是平的》这本书，忽然注意到Cisco的创始，也是来自一对夫妇的创意。1984年，在那个大型机和PC机，IBM的系统和Digital的系统互不联通的时代，斯坦福大学计算机系实验室的Leonard和他太太Sandra办公的斯坦福研究生院只有500米不到，但是他们用的系统却没有办法把晚上买菜的清单传递过去，所以小两口就一起做了一个可以自动的把一个系统的命令，模拟成另外一个系统可以看懂的命令，并且把数据格式转换的小盒子，这也就是世界上的第一个互联网路由器。之后，两个人和朋友一起注册了一家公司，名字很简单，Cisco；就连这个名字本身也显着这对夫妇的随意 �C 仅仅是因为他们注册公司的时候开车经过了金门大桥，觉得San Francisco这个名字很好听，金门大桥很好看，于是公司就取了San Francisco的最后五个字母，公司的标志就是金门大桥的样子。一对甜甜蜜蜜的小夫妻，成就了现在这个市值一千六百亿美金的业界巨人。

互联网的夫妻老婆店模式

当看到很多大的公司，都是由夫妇两个开始，有一个产品不断的成长成为成功的大公司，我不禁要思考，到底这巧合中间，到底有没有什么必然的？

结论是，老公/男朋友给自己的老婆/女朋友写的软件，成功的可能性的确会提高。这显然不是放之四海皆准的定律，但让我觉得值得研究一下。

第一，产品由需求产生。无论Mena想写点东西，还是Pam要找到一个和她一样喜欢PEZ Dispenser的朋友，或者Sandra仅仅是要把晚上买菜的单子传给500米以外的丈夫，妻子（或者丈夫）们的想法都是那么单纯，和普通。这些需求，比起科学家在实验室里面挖空心思想到的宏大的想法，往往更加具有普遍性，也就是拥有更大的市场。Frank Guarnieri说过，"花精力在重要的，而不仅仅是有趣的东西上，而两者都恰巧是无穷多种的。"或许源自于普通的老婆/女朋友的想法通常是重要，而不仅仅是有趣的想法。

第二，使用对象明确。Mena是一个不懂技术，但写作很好的一个普通用户，在软件设计里面，是一个现成的"假想使用者"(Persona)。在写MoableType的时候，Ben对于功能的取舍很简单：Mena用得到的功能，就尽量做的完备一些，简单一些，Mena用不到的功能，就根本不用考虑。使用对象越明确，做出来的软件就越容易获得和Mena一样的人的欢迎。当设计一件产品的时候，心里想的使用者越清晰，越具体，成功的可能性就越大。产品的使用者清晰到老婆这一个人的时候，产品设计就不能再准确了。这样就避免了一般产品"谁都可能喜欢，但谁都不是特别喜欢"的状况。MovableType，至少Mena喜欢，而成千上万的像Mena一样的人就都开始喜欢了。iPod等的设计，又一次的说明，只有核心人群真的喜欢，才有可能成为一种潮流，带动更多的人喜欢。

第三：设计中有爱心。在很多细节上的考虑，是不是让使用者最方便的使用，的确是非常需要爱心的。作者在写软件的时候，或者做网站的时候是不是用心了，是不是有爱心在里面，用户是可以感觉到的。Six Apart从最早Mena和Ben家里的一件空闲的卧室开始，到一步步走到正规的公司，里面很难分得清哪些是爱，哪些是工作了。产品设计需要投入最细致的心思，最体贴的考虑，互联网产品尤其是如此，因为整个产品本身，就是一种用户的体验的设计。有了爱心为基础，也就有了一流的用户体验。

分析了这么多，到并不一定得出一个夫妻老婆店一定成功可能性大，或者不是就一定失败这样武断的结果。目的就是在于从这些组合中间天然的优势里面，学到一些创业公司值得学习的对市场的洞察，对功能的取舍，以及对用户的专注。

后注：Six Apart，eBay，CISCO都是我非常喜欢的公司。2004年冬天，我在Six Apart刚刚搬进的San Francisco办公室见到了Ben（和Mena）。在一个星期以前，在San Jose第一次见到了羞涩的Pierre。对于我来说，一直觉得他们首先是一个体贴的好丈夫，一个天才的程序员，其次才是一个商业神话的缔造者。互联网里面，还会出现多少这样的夫妻老婆店呢？

作者：Jian Shuo Wang
发表于： 2006-12-18 22:12
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
http://home.wangjianshuo.com/cn/20061218_aeecce.htm

Flickr设计中的一个小细节

Flickr的用户体验做得非常好，一直都是学习的目标，今天无意中发现一个非常小的小细节，真是佩服！当然要是我们认真花上时间来做的话也会考虑到这一点，只是很多大家都能想到的简单东西，项目实际进行的时候往往被忽视。

非常简单，一看就明白，当图片被浏览数等于零的时候就不显示，如图。

Google 应用服务网站版测试申请失败

不知道具体的审批条件是什么，不过我这个网站只有域名，或许应该用另外一个账号申请，原文如下：

daban：您好！

感谢您关注"Google 应用服务网站版"。 很遗憾，我们目前无法邀请您的域名 idaban.cn 加入测试计划。
如果我们的审批指导方针在日后有所变化，届时能够接受您的域名，我们就会通过电子邮件通知您。

谨致
Google 小组敬上

自己的狗食自己吃-Google 发布应用服务网站版

2个月前还在说Google的服务可以用于企业间的协同办公，昨天在blog中也提到了这个。结果今天在Google黑板报中就看到关于Google 应用服务网站版的介绍文章。

自己的狗食自己吃
2007年1月18日 上午 01:59:00

之前在团队内部已经利用这些工具进行过尝试，用用还不错，但是因为网络不稳定，尤其存在类似海底光缆断掉之类的危险，也不敢过分依赖这些东西。Google有时候也会访问不的。

曾经担心Google的这些软件没有很好的整合，看来已经无需担心了。马上提交相应资料给Google，现在静待审批。

不错的google服务

都在这里啦！
http://www.google.com/intl/en/options/
http://labs.google.com/

其中几个推荐：
Google Notebook
Calendar
Docs & Spreadsheets
Blogger