Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'wp_maintenance_mode' not found or invalid function name in /home/po1ggfgtskj6/domains/blog.wangjunyu.net/html/wp-includes/class-wp-hook.php on line 289
猫窝 | 猫的世界观 | Page 8 | Page 8

猫窝

那些就在眼前的好想法

2012 年 10 月 26 日 by 6 Comments

《社交网络》所赐,大众大约会认为创业是一件很讲究想法的事情——只要有了一个「好的想法」,成功就会站在不远处向你挥手了。不说大众,即使是业界 blog,大多数文章也是讲述一个个激动人心的新想法。遗憾的是有好多次我兴冲冲地去 App Store 下载一个刚刚看到介绍文章的新产品——五分钟后,我一边删除这个应用,一边暗想:「如果这个应用能像它所声称的那样工作就好了」。

什么是「好的想法」呢?我每年给 Dropbox 付 20099 美元,换取 100GB 空间。这笔钱在 Google Drive 能买到 200GB,而且 Google Drive 还有识别图片这样的华丽功能。唯一的缺点在于,它就是不能像 Dropbox 一样,能在不弄得我电脑风扇 CPU 狂转的前提下顺利地把我的文件同步上去。简单地说,Google Drive 对我来说不是一个能用的网盘,而 Dropbox 是。

拿这个例子来说,什么是「好的想法」呢?也许 Google 和 Dropbox 的想法都是做一个「网盘」,只是做得好坏的区别。但我更倾向于认为,结果的差异,是因为 Dropbox 的核心想法就是「做一个能用的网盘」。「能用」是 Dropbox 的想法的核心,但对其它人来说,不是这样的。

就这么简单。有时候,最朴素的想法可能就是最有力的。你不一定要很用力,才能拿到这个想法,就看你有没有意识到。

我最近做了一个事情,也让我自己体会到了这一点——我们对豌豆荚的手机客户端的改动。

最早豌豆荚在手机上的客户端是一个「空壳」。可以把它理解成一个代理——从技术上来说,电脑无法直接操作手机里面的数据,但可以指挥手机上面的应用来做事情;所以,为了让电脑能管理手机,我们才做了一个手机应用进手机,它本身没有任何功能,甚至一度我们连图标也没有放,只是后来担心被用户以为是可疑的流氓,才做了个界面。

到 2011 年年底,豌豆荚在电脑上的应用搜索业务相对成熟,再加上我们认为手机上也缺乏一个好用的管理文件的工具,我们就在这个「空壳」上加了搜索应用,管理手机图片、视频、音乐、电子书的功能。这是第二版,我们内部称之为 Phoenix。很多人对豌豆荚的印象仍然还停留在一个 Windows 客户端软件。但事实上,随着 Phoenix 的发布,越来越多的用户只在手机上使用豌豆荚,而不是坐在电脑前了;也越来越多用户只知道豌豆荚的手机客户端,反而不知道豌豆荚在电脑上还有一个版本了。这对我们来说,是个好现象。

那下一步的「想法」是什么?如果做头脑风暴,那会出来无数有趣的想法——事实也是这样的。我们可以像张小龙一样添加一些「直指人心深处」的功能 (「摇一摇」?) 也有很多虽然和我们现在做的事情不直接相关,但同样是帮助用户把手机变得更简单好用的事情是可以做的,例如省电省流量等等。

但这些是「好的想法」吗?

创造想法的过程一不小心就会用力过猛,因为你很容易为了创造而创造,为了新的想法而新的想法,而对那些显而易见的事情就是视而不见。

无需调研,问我们自己几个问题——今天,你在使用这个产品过程中,对痛苦的几件事情是什么?

结果是明显的,因为我们自己都是用户,我们自己每天都用豌豆荚。手机输入没有电脑方便,现有界面大量依靠输入文字搜索,很痛苦;手机的网络、性能也没有电脑好,运行不流畅、下载速度慢的问题更突出,很痛苦;Android 的屏幕种类越来越多,现有界面太死板,办公室里面添置的 Google TV,就因为豌豆荚的手机版本不支持横屏而无法运行,这也很痛苦。

那我们就解决这三个问题吧?可这是好的想法吗?这些事情,难道不是「是个人就应该想到」吗?用户会买账吗?

想了想,还是先抛开那些更华丽的想法,先动手了。说起来平淡如水,这里面还有一些类似的决定。

例如,由于要减少用户需要输入的部分,界面布局是不可避免要大改造的。改造后,是改用 Android 系统的原生风格还是继续自己的风格?和「不要为了创造想法而创造想法」类似,我想优秀设计师的一个基本素养就是不要为了体现自己的存在感而专门做点什么——街上接过的小传单上乱七八糟的繁复修饰,无不在体现「这张传单是我们是花钱找了设计师做的」。

但做为设计师,当然都要有做出令人耳目一新的界面、引领潮流和趋势的梦想。如果能像 Path 这样,能有一个按钮被全球各地各种不同类似的应用反复抄袭;或者像 Windows Phone 7 一样,创造一种独特的全新界面设计语言——那对设计师来说是多么让人自豪的事情。

但我们试了好几套很「豌豆荚」的风格后,最后还是决定回归系统原生风格。一方面,是我们认为 Android 系统的原生风格已经「足够好」,我们不必在每件事情上都如此用力;另一方面,在界面上进行大幅创新也是需要大量时间和精力的,就目前来说,我们更愿意把这些时间和精力放在其它更关键的地方。

所以我们最后采用了 Android 的原生风格。设计的结果,就是一个特别难以被普通人注意到的界面。你关注的完全是内容,不会感到这个界面的存在,一切操作、滑动都和你的期望一致,你不会感到惊叹。这对我们来说,就是好的界面设计的其中一种。

这些想法都是如此的显然,以至于公司外的同学都能猜到——不止一次被问到,你们手机客户端最近在忙着「改版」吧?有一段时间没更新了。

好在团队很给力,几个工程师和一个设计师,只花了两三个月的时间就高质量地完成了重构工作,比我们 Windows 客户端的重写工作顺利多了。抽样测试,上线。

最大的收获是我们自以为了无新意的改动,用户是能注意到的。有些重度「谷粉」原来看不上豌豆荚,现在表扬我们说比 Google 自家的 Google Play 还 Google-y。新版本上线一个月不到的时候,用户使用率已经上升了接近 100%,大部分的用户已经是在手机上接触豌豆荚,而不是在电脑上。

我突然觉得「是个人就能想到」就是个不错的评判想法的标准。就是有那么多的想法,当你想到它的时候,你会觉得「是个人就能想到」,但偏偏所有人在之前路过的时候,都是视而不见的。有时候我们需要用力做出让人惊叹的想法,而有时候我们需要做的,仅仅只是轻轻一推,让小球滚向它应去的方向。

这是如此的显然,以至于当你发现的时候,都忍不住想打自己的脸,怎么之前就是没想到。

正如网盘应该能用而不是不能用。正如手机应该用手指控制,而不是触摸笔。正如好的产品首先应该保证有尽可能少的 bug。等等。

本文为供新浪科技稿。

我们是怎么重新设计豌豆荚的

2012 年 8 月 25 日 by 0 comments

二月份做完这个项目后,在公司里面写了一篇总结,后来在爱范儿3W Coffee 合办的一个活动上也分享过。黄龙中鼓励我要「笔耕不缀」,所以还是整理出来,发表在了爱范儿上,这里再自转一下。

豌豆荚还有很多不足,也还远没有到「State of the art」的理想境地,但看着往这个方向一点点前进,还是一件值得开心的事情。记录下设计过程,也是供同行们参考。

附有视频一则。

今年 2 月份的时候,我们发布了豌豆荚 Windows 版 2.0。这个项目的设计和开发时间有 10 个月之久,这对很多公司来说可能并不算长。但考虑到这 10 个月占据豌豆实验室当时两年历史的接近一半,豌豆荚 2.0 对于我们来说就显得很重要了。

2009 年年底,我们开始豌豆实验室的时候,就希望做不一样的公司、开发不一样的产品。用我们的产品和技术,来帮用户解决问题。而不是像很多同行一样,用其它的更捷径的方式。两年的时间里我们做了很多尝试。有些尝试失败了,也有些尝试成功了。

「成功」有一个简单的标准,即被「借鉴」。2010 年,我们刚刚推出第一代产品的时候,用了和过去的类似软件很不一样的产品设计,特别是功能大为减少。有些朋友忧心我们的产品过于简洁,也有人警告我们说,这种「阳春白雪」的产品在中国是走不通的。但时至今日,我们已经拥有了超过 5000 万的安装量,而今天市面上所有有点影响力的桌面手机管理软件,基本上也并没有脱离开豌豆荚定义下来的框架。可以说,我们在过去两年的时间里重新定义了桌面手机管理软件。

我们不介意别人对我们的跟随,因为当别人还在跟随我们的时候,我们其实已经给明天做好了准备。

这就是豌豆荚 2.0 的设计背景。

为什么要动手做豌豆荚 2.0?要回答这个问题,就得知道豌豆荚 1.0 是在什么样的环境下出炉的。

豌豆荚 1.0 开始开发于 2009 年 12 月,当时市面上最为流行的 Android 手机是 HTC HeroMotorola Milestone 刚刚推出,Nexus One 还不见踪影,Android 手机在国内的数量,应该仅在百万级别。这种情况下我们将豌豆荚专注在 Android 上,其实上是一种冒险。实话实说,我们自己也并不清楚用户需求到底是什么样的。

因此,对于豌豆实验室来说,最重要的任务就是尽快推出最小可用的原型产品(Minimum viable product, MVP),验证用户需求。

说到这里稍微绕远一点——为什么这些年来很少创业公司会选择 Windows 客户端这个领域?原因很简单:开发成本太高。要做一个非常好的 Windows 客户端实在太难了,要比做 Web 服务、iOS、Android 应用都要难得多。这也是为什么我们现在想把我们创造的这种 Web 客户端的框架开放出来的原因,因为实在太难了。

因此,可以理解为什么豌豆荚最早选择了用 .NET framework 来开发——在开发效率还是用户体验这个问题上,我们选择了开发效率。尽管这个决定后来被屡屡诟病,但即使再来一次,我们也一定会做同样的选择——因为这可以确保我们能用最快的速度将产品推向市场,迅速摸清用户需求。快速迭代。

所以你可以想像,那时候我们的心态是:尽快用积木搭个能走的小车,别的再说。即使很小车不牢靠,但至少能走。而能走了以后,我们应该有时间重新做个好点的车。

一晃一年过去了。2011 年 2 月份,我们迎来了第 100 万个用户。如我们所料,用户需求变化很快,一年的时间里面产品进行了多次大幅改动,但基础仍然是那个用积木搭成的小车。

积木小车已经不堪重负了,已经有太多的新功能、太多的缺陷,不推倒重来无法解决。

我们最终下定决定要推倒重来,重新设计和开发豌豆荚。这是在 2011 年的 2 月份。扔掉 .NET framework 的架构,重新用 C++ 开发——我们知道这是一件很难的事情。但,实际情况比我们想象的还难。

无知者无畏。

我们最初的计划是 在2011 年 6 月发布豌豆荚 2.0。不过,到 5 月份的时候,我们估计新产品在 7 月份发布的话,可以比较安全。到 6 月份的时候,我们再次估计在 9 月应该能发布,这样我们能过个美好的国庆长假。可是到了 9 月份的时候,估计的时间点变成了新年前后。董事会上冯锋承诺,如果新年前还无法发布,就要服毒自尽(幸好后来没有人提起过这件事情)。最后,我们是在 2012 年 2 月 22 日发布的。

这个日子其实也不是刻意挑的,而是因为豌豆荚 2.0 各项指标终于在一周前都基本达标了。

回头一看,我们当时随意用积木搭成的小车,居然在这整整 10 个月的时间里一路高歌猛进,安装量从 100 万变成了 2500 万。这真是一件让人吃惊的事情。

不管怎么样,总算是发布了。

2011 年 3 月,我们开始进行豌豆荚 2.0 的设计工作。豌豆荚 2.0 要解决什么问题?

传统的理解需求的过程,有许多不同的方式。例如,直接进行用户访谈,发放调查问卷,购买市场研究报告,或者听听意见领袖们怎么说。

我们的方式,就是依赖直觉和经验。

这有两个前提条件,一是豌豆荚已经运营了一年,我们自信对用户需求的理解已经有了一定的积累;二是实际上在当时来看,已经不是不清楚用户需求的问题,而是用户的大量需求我们原有的产品和技术架构无法满足的问题。因此我们做的第一件事情,就是把我们脑海里面堆积如山的想做的事情整理出来。

第二件事情,豌豆荚的愿景在一年多的时间里也慢慢变得清晰。将这个愿景整理成思维导图,我们就拥有了一个几年内的路线图。豌豆荚 2.0 如何和这一愿景相匹配,也就是一件自然而然的事情了。

和各种各样的头脑风暴的过程一样,需求的收集是一个开放的过程。这里面会有各种各样的声音,但需要产品设计师来归纳和整理。

与此同时,工程师们也在做早期技术方案的探索。早期的探索过程就像上图所示意的一样。你需要不断地发散,又需要不断地拒绝掉不那么靠谱的想法,留下那些靠谱的,并且进行下一个阶段的发散。如此反复,你就在这发散与收敛的过程中取得了进展。

豌豆实验室使用 Google Docs 办公。在初步的想法确定下来以后,我们就开始使用 Google Docs 协作,不断把我们对产品的想法积累下来。在纸面上推演的时间花了一两个月的时间,我们维护了一个文档,一直在更新。这种时候,是不需要关心能不能做出来,也不需要赶时间的。

不是所有的沟通工作都适合用开会这种形式来解决。尤其是对产品的想法,很多时候可能就是躺在床上睡着之前的灵光一现,如何更有效地捕捉到这种灵光,比何高效地沟通更重要。

所以那段时间我们在 Google Docs 上维护了两个文档,一个是基础框架的需求,只要想到什么东西,我们就会添加进去。可能其它的同学过了几天甚至是几周的时间突然在这个基础上想到了什么新的想法,才会上去回复进去。Google Docs 的评论功能非常适合于进行这种异步的讨论。

另外一个是所有功能的列表。这个文档叫 One-Pager,本意是在一页内将所有的功能写进去,结果最后发现打印出来有 10 页长。

灵感一发不可收拾,我们写了很多文档,放在同一个目录里面。和一部分设计项目的过程不同,到这里为止,我们还没有动手画任何东西。不是不想画,而是强忍住了画出来的冲动。我们觉得,应该先从比较抽象和逻辑的层次,把产品的思路整理清楚。

这张图是我用来做规划的工作,在这里面列出了豌豆荚所有的页面和功能,确保不会出现大的遗漏。这同时也做为工作规模和进度的估计,看这张图,我们就能知道有多少工作已经完成,有多少工作还没有做。

设计工作往往是发散的,但经过之前的铺垫,我们已经整理出“再设计工作”的几条主线。其中之一,就是对信息架构的改善。类似这样的主题,我们在 Basecamp 中创建了不同的 To-Do 列表,方便头脑风暴要解决的问题,同时也一个个划掉,确保项目始终围绕着重设计要解决的问题来进行,不过分发散。

我们有时候引入大量的讨论,但又注意不和所有的人讨论。在豌豆实验室这种开放透明的工作环境中,如何「管理」好其他人的脑力是一个挑战。你希望其他人的观点、知识、经验是能对你的项目带来帮助,又不希望会对你的决策带来干扰,避免「集体决策」的结果。

Jesse James Garrett 在《用户体验的要素》 [PDF] 这张著名的图表中,将用户体验划分为几个不同的层次。随着设计的过程从抽象到具象,产品也一步步走向完整。

接下来的设计过程就是一个从抽象到具象的过程。

我们开始有手绘的线框图。

为了探索更好的信息架构,尝试了各种各样的方案。基本上是按照排列组合的方式,把各种可能的情况都试了一遍。

就和之前那张示意图一样,设计的过程就是不断发散尝试,同时也不断抛弃自己的尝试,挑选胜出者,再进行下一轮的发散和抛弃。

这种不断发散地尝试在什么时候可以停止呢?一直到出现一些自己满意的方案为止。什么叫一些?什么叫做自己满意呢?就是觉得没有什么可以改了。高质量的设计一定是有满墙的迭代草稿做为基础。第一稿就非常完美,有可能性,但非常罕见。

同时我们也开始了视觉设计的工作。这是不符合一般设计项目的流程的,但我们的时间不允许做完所有的交互设计,再进入视觉设计这一流程。

前文再续,说到我们一边画线框图,一边就请我们远在纽约的视觉设计师开始开展了视觉设计的工作。一方面是因为这样比较节省时间,另外一方面也和项目参与者的技能比较有关。我和刘亚平(豌豆荚的产品设计师)都不擅长视觉设计,但自认还是有能力将一个比较完善的视觉设计语言应用到已有的产品上的。

因此,在视觉设计的基本样式出现后,我们整个设计的过程基本上就是直接输出高保真的设计稿的过程。从没有草图到线框图到视觉设计稿的过程后,效率提高了很多,依赖已经确定的视觉风格,也可以保证不出现冲突,还有高度的一致性。

借助这个风格的工作模式,我们往往在一张图上会同时标注产品逻辑和呈现大量细节的视觉实现指南。通过这种方式,我们可以一步到位地和开发人员讲清楚我们需要的是什么。这是非常重要的,很多复杂的交互中,有一点点不清楚,要返工的成本可能就会非常高。这张图展示的是对通用搜索功能的设计,设计师需要考虑到拼音首字母、标点符号全角还是半角等等的细节。然而,即使做到这个程度,仍然出现了很多因沟通不清而出现返工的情况。

这是豌豆荚 2.0 左侧导航的部分设计稿,我们遍历了所有的状态,力图在产品定义中将所有情况都考虑到。

我们的经验是,不要拘泥于教科书上的流程——当然,你需要了解。在这个阶段,也要和所有人讨论,让他们告诉你各种各样的边缘情况。

整个设计过程我们进行了数百次尝试。实际数字应该要比这个多,因为我们都没有每做一次,就保存一次版本的习惯。

在确定了欢迎页面的主要任务是加强用户和自己手机之间的情感联系后,我们首先是收集了一些图片,来沟通我们希望这个页面传达什么情感。

然后在这个基础上进行了各种概念的探索。

比如,是不是在欢迎页面上显示通知、手机里面的图片、推荐应用等等:

只显示图片:

显示应用:

将手机的墙纸取出来,和欢迎页面结合到一起去?我们收集了一些常见的壁纸,进行了效果模拟:

在确定了几个比较明确的方向后——使用我们向用户推荐的应用,要结合用户在手机上设置的墙纸——我们进行了更多的探索:

这是最后的样子:

这期间,为了探索交互的效果,我们还开发了几个可交互的动画原型,供设计师们实际评估。豌豆荚 2.0 的 Web 框架也会这些效果的实现带来了便利。

前面说到,如果没有数量众多的迭代,不大可能有一个好的设计。豌豆荚 2.0 就是其中一个案例。

然后就是漫长的设计、开发、返工、再设计、再开发的过程。我们一直看着那张大图。

2011 年 8 月,我们发了第一个公测的版本,发电邮邀请了几万位热心用户参与测试。从这时候开始,我们用尽了各种定量和定性的办法来不断邀请用户参与,不断评估效果。从传统的可用性测试、到性能数据评估、到定量的问卷调查等等。到 2012 年 2 月我们的各项指标终于都满足条件,准备正式发布时,豌豆荚 2.0 已经积累了超过 100 万的测试用户。

回头来看,豌豆荚的愿景仍然有大部分没有实现。上面的这些设计,在发布后的半年多时间里也在不断进行调整,有不少设计已经又被我们认为更好的设计取代了。而且,我们的路线图里面还有更多我们认为可以再次改变整个产品体验的想法。我们现在有一个五位产品设计师组成的产品设计团队,但我们要做的事情还有很多。现在豌豆荚总安装量超过 6000 万,豌豆荚 2.0 的安装量超过 5000 万,但远远不是我们理想的全部。

如果你觉得我们的工作方式还合你的胃口,不妨考虑一下加入我们。有兴趣,可直接联系 junyu@wandoujia.comyaping@wandoujia.com

There’s an app for you

2012 年 4 月 19 日 by 5 Comments

去年 12 月,我结婚了。我的对象是朱大力

然后,她就去 Mountain View 出了三个月差,直到 4 月 1 日刚回来。

三个月两地相处的时间里,用 Google Voice 打电话,用 Google Chats 进行文字和视频聊天。还有,Line、Path、Kik 等各种应用都是我们保持联络的方式。不过,始终还是觉得有很多缺憾。比如,思念对方的时候,还是没有办法知道对方在做什么、想什么。

所以大概在二月份的时候,开始构思一个给情侣保持关系用的应用。二月底的时候我开始学习 Android 开发,然后利用周末的时间来开发。和所有的创业项目一样,这个项目的开发过程也很曲折和怀疑人生。比如说对一个从来没有自己动手做过 Android 开发的 Web Developer 来说,Android 开发的学习曲线还是相当陡峭,又比如做的过程发现原来去年就有一个叫 Between 的应用,然后 Pair 也发布了。这样促使我不断地打磨和精简这个想法。这样子下来,花了六七个周末的时间,终于完成了第一个版本。

这就是 Together

Together 的基本想法非常简单,就是两个人一起拍照片,一个属于两个人的照片墙。打开它,拍照,马上就会上传,女生拍的照片用红色表示,男生拍的照片用蓝色表示。就是这样。不需要点好多次按钮,也不需要在通讯录的几千个人里面去选择要分享给谁,不需要进行各种后期处理,没有多余的功能,没有赞,没有评论,也没有分享,也没有滤镜。拍了照片,对方就能看到,就是这么简单。

应用已在 Google Play 发布,目前仅支持 Galaxy Nexus (去年年底,我们互送了一黑一白的两台 Galaxy Nexus),并需要邀请。有兴趣试用而且双方都是使用 Galaxy Nexus 的同学,可以直接联系我;其它手机的同学,欢迎打开 www.together.im 注册等待。

今天是朱大力的生日,这个小小的应用做为生日礼物,送给你,希望你会喜欢。创业两年多以来没有少加班和熬夜,有你的支持才能走到今天,谢谢你。

同时,也感谢几位朋友在此项目开发过程中提供的帮助,包括李晶老师柳亚鑫同学分别在产品和技术上的指导。

也祝天下有情人终成眷属。

我的 Android 十大必备应用

2012 年 3 月 16 日 by 6 Comments

贵公司做了一个「Android 神人」的活动,当然我自己也兴冲冲参与了,推荐了十个应用。在这里 repost 一次,附上详尽一点的推荐理由。

NewsRob

NewsRob我是 Google Reader 重度用户。我在 Google Reader 上订阅了超过 600 个 feed,过去 30 天阅读了 9909 篇文章,通过它分享了 78 篇文章。Google Reader 对我非常重要。尽管和 Reeder 相比 NewsRob 就像是三岁小朋友的作品 ,但这也是我目前在 Android 上找到的最好的 Google Reader 客户端,甚至超越 Google 自己出品的官方版。完全不知道这是喜还是悲。说句公道话在有一点上 NewsRob 完胜 Reeder:能在后台同步。用 Reeder 的时候都要记得每次出门前点一下 sync,奇傻无比。

下载链接 »

Google Currents

Google Currents其实完全和 Flipboard 是两回事。我和 Google Reader 同时使用,用法略有不同。Google Reader 上我不会订更新量特别巨大的 feed,而且会保证把所有文章读完;其它的偶尔一读的内容来源,就会用 Google Currents 来读,包括 GizmodoThe VergeEngadget、爱范儿等站点的内容,大多数都是在 Google Currents 里面读完的。功能上有一点很棒,就是可在后台同步,但要分享东西出去很麻烦。另外,每次看到那个纠结的图标就会感到心里很纠结。

下载链接 »

Amazon Kindle

Amazon Kindle我发现我在 Kindle 里面读书的效率远远比读纸质书的效率高得多,很大程度上的因为我的所有设备——包括电脑、平板、手机——上都装有 Kindle 应用,当然包括 Kindle 本身。这样一来,不管何时何地,在任意一台设备读书读到一半随时扔下,捡起另外一台设备马上就能接着读。这种体验实在太爽了。唯一的限制就是……只有通过 Kindle 购买的书能享受这种体验——含辛茹苦,一个月攒的钱也买不了几本书啊。

下载链接 »

Path

Path最近的一次升级让 Path 的 Android 版和 iOS 版的差距稍微缩小了一些,比如,我终于能看到帖子的发布时间了……但明显的差距仍然存在的,比如,Android 上迄今为止没有滤镜功能,「夜不能寐」的土鳖翻译也让人欲罢不能。但这不重要,因为只有打开它才能看到一些其它地方看不到的东西,你也会愿意往它吐出更多真相。因为只有比较熟的朋友在上面,所以可以随意发挥,也可以看别人随意发挥。总得来说,这真是一个吐槽圣地,同时也让人很怀旧地勾起了对「SNS」这个词语最初含义的思念。

下载链接 »

街旁

街旁好朋友做的产品。坦率而言,对我来说,街旁与其说是一个社区,不如说是一个工具,一个可以用来同步到微博和校内的、带有滤镜功能和地点信息的发照片工具,偶尔也能靠签到骗到点小实惠。街旁的朋友们一定会在心里暗骂「这个不懂情调的死理科生」,但经常在上面能在上面深夜收获几个好朋友们的「赞」也很是惊喜,谢谢你们。

下载链接 »

微博

微博我用了好长时间的 Weico,还是受不了各种 bug,转回了官方客户端。不好用,很土,还有大广告,但你也找不到更好了的。对我来说,微博客户端是当好豌豆荚客服的必备工具。也是拉屎时候的必备。但就客户端而言,我还是更想念 Twitter 的那一众美丽优雅的客户端们。

下载链接 »

Toshl

Toshl不是和金蝶的同学们有仇,但每次听人夸奖「随×记」心中总会默想这哥们一定生下来就没用过什么好东西 (不懂英文的同学可豁免此诅咒)。用 Toshl 吧,你不用每次记账都在那一大堆下拉菜单中精挑细选,轻轻触碰 tag 就好。App 免费,当然你也可以像我一样每年支付 $19.9,心中油然产生「我让世界的设计更美好」的道德优越感。值得一提的是,每记一笔账都会听到一声清脆的钱响,仿佛在提醒你「是金子总会花光的」这一古训。

下载链接 »

Any.DO

Any.DOAndroid 用户没有 Clear 这么装逼的应用,只好用这个。Eric Schmidt 大爷投资的创业团队,可以和 Google Tasks 同步,还有「摇一摇」清空已完成任务这样富有东方风情的设计,你也能感到设计师想 metro 但又不感完全 metro 的苦心。有一点小小的不幸是我至今不知道如何让它能自动同步,再加上现在事情太多精神有点错乱,所以经常出现一件事情我在手机上勾掉三天后在电脑上又看到,于是又重复做了一遍这样的窘境。

下载链接 »

Evernote

Any.DO其实一点也不简单,但你也没有更好的选择… 不喜欢用纸笔,带电脑又分心,所以一般开会的时候用平板上的 Evernote 记笔记。但除了记纯文本笔记以外其它功能都没有用过,所以如果有人能做一个 1) 只能记纯文本笔记,不用格式、画画、语音什么的;2) 跨平台实时同步,不要 iOS only 什么的;3) 客户端,不要每次都要开浏览器什么的。我一定会使用的。可以命名为 Evernote Lite。

下载链接 »

最后第十条本来是「豌豆荚」,自家产品,我用来搜索下载应用和管理手机里面的内容。正式发出去的稿子里不知道为什么消失掉了,可能是出于要显得谦虚的考虑吧…

Chrome 的加号呢?

2012 年 3 月 12 日 by 11 Comments

Chrome 的老用户应该都有注意到一件事情,大概几个月前,「新建标签页」上面的那个加号,消失了。

我一直以为这是个 bug,直到几周前,1) 我发现 Chrome for Android 的平板版也没有这个加号;2) Kevin FoxGoogle+发帖吐槽,我才意识到,这不是 bug,这是 by design 的…

然后我的三观就崩溃了。

这确实是一件很难接受的事情,初看起来也很荒谬。但纯吐槽和看别人吐槽对自己是不会有长进的,花些时间理解一下这后面的设计动机更有意思。对于「UI 设计爱好者」来说,设计背后做决定的过程 (decision making process) 应该是一个让人更感兴趣的事情,就和影迷总爱看花絮一样。这也许也是为什么 37signalsSignal v.s. Noise 受欢迎的原因。

从这个角度来看 Kevin Fox 的吐槽贴,更有看点是下面的回复,因为有若干现在 Google 的 UX Designer / Researcher 跳出来解释了若干设计的动机,这里面就包括了 Chrome 的两位工程师和/或设计师,Peter KastingGlen Murphy 对 Chrome 这一改动的解释,

具体的解释大家可以自己点过去看。其实,只要保持开放的心态,花些时间应该是很容易理解去掉加号带来的新的隐喻的,只是确实习惯它需要一段时间。暂不说这个改动的好坏的话,我非常喜欢 Glen Murphy 的一番话,所以我决定翻译出来:

试着想像,如果 Chrome 的「new tab」按钮上从来没有那个加号,我们会不会有什么理由需要增加它?鉴于那个加号长得挺丑的,和界面的其它部分也不搭调,添加它的原因肯定是它改进了某个指标,或者得到了正面的用户反馈。迄今为止,我们还没有观察到这个加号的存在与否对用户行为有什么影响,Chrome 的新用户也没有觉得有什么问题(他们还没有习惯这个加号),增加这个加号看起来也不会帮他们更好地理解这个按钮的作用。看起来会在意这个加号的就是那些已经习惯它的存在的人,我们也意识到对他们来说这是很难受的,但总体上我们的经验告诉我们,大家会习惯这个改变的,而我们觉得这个改变是好的。

做为一个大产品,对改变的畏惧是我们最大的敌人。为了战胜这一畏惧,面对类似这样的改变时,我们常常要问自己,「如果我们现在是在重头设计一个浏览器,我们会怎么做?」或者「如果这个改变已经生效并且获得认同了,我们会改回今天的样子吗?」。我们在试图把 Chrome 雕琢成完美的浏览器,而有时候这意味着,为了长期的愿景,我们会进行一些痛苦的、出于一致性考虑的改变。我们希望尽可能减少对已有用户的影响,但这个世界上的大部分人还没有用过 Chrome,我们需要为他们创造可能存在的最好、最牛逼的浏览器。

始终不要忘记这个世界上的大部分人对你的产品来说都是新用户。即使是已经有上亿活跃用户的 Chrome。

我真喜欢这种野心和想法。