UML软件工程组织

 

 

再说“双向”好友。(谈豆瓣好友改版)
 
2008-02-26 作者:白鸦 来源:ucdchina.com
 

豆瓣在“友邻”里增加了“我的朋友”功能,体验后感受到如下问题:

1、在“广播”和“豆邮”之后,豆瓣首页的右侧又多了一个“类信件”的模块 ── “需要你处理的请求”。使我的“信件来源”过于分散。

2、“别人‘关注’了我”,会用豆邮通知我,豆邮是在主导航上的。可别人“加我为好友”这个“更重要点的事”却只是在首页安排一句话的通知。

3、原本一个“友邻”的概念拆分成了“好友”和“关注”,我重新理解的成本至少是3:“友邻被拆分了”,“什么是关注”,“什么是朋友,如何成为朋友”。

4、“朋友”和“关注”逻辑上看来是一个不错的规划,但这个“不错”是对新用户来说,对老用户并不一定合适。
这个问题类似于:有些人盖楼的时候先盖一两层,以后更有钱了再在上面加盖几层,加盖的过程可能会影响到原来的楼房,评估“加盖”方案是否合理的标准是:“对原有两层楼的影响有多大,影响的时间有多长”。

5、很多人和我已经是“互为友邻”的人了,现在这么一改我们还得再经过一次双方确认才能成为“朋友”,后果就是几乎所有的老用户都得重新倒腾一遍自己的友邻。就像正在饭馆吃饭的时候,老板说“我们觉得这个单间不好,你们现在到另外一个房间去吃”,于是所有人都屁颠屁颠端着碗筷和盘子换个房间吃饭…

6、是不是让别人看到我的某些信息”,确实应该由发出去信息的人说了算(不只是“广播隐私设置”,也可以是“能否看我的好友列表”等)。但,“是不是要收到某些信息”,应该由收信息的人说了算。靠让发信息的人把友邻分级然后设置要什么人看到什么信息,只解决了“隐私”问题,并没有解决“干扰”的问题。

其实最大的问题根源应该来自于豆瓣在强调的“双向好友”。

1、我个人认为豆瓣的好友添加过程和绝大多数好友添加过程一样:根本不需要“双向确认”。

虽然豆瓣很需要“双向好友关系”来拉动社区的体系,但现在已经有了一种“关注”的弱关系,某种程度上使得“双向”变成了一种相互麻烦确认的一种形式。

有些用户并没有区分“朋友”和“订阅”的需求,而且大部分人在决定“什么人该放在什么类别里”的时候界限很难划清(信息分类向来是设计中最难的问题,更何况是按照“别人”的规划来分类,而且还只有两个类。 ),非得生硬的把“朋友”和“关注”区分开,不过只是设计者的一厢情愿。

2、之前写过关于好友的看法,引发了麦田魏武挥的讨论,我又重点说过“双向”还是“单向”的观点。“双向”本来就是一个不符合正常思维逻辑的事情。

3、我一直认为:“双向”只是一个“统计结果”,而不是一个过程,更不一定是“双方”都认为的结论(我认为柴静是我的朋友。她就是。就算她认为不是,我照样认为是)。

4、(不要说facebook的好友就是“双向”。facebook不一定就是对。而且facebook对于隐私的要求特别高,豆瓣并没有那么高。)

也许豆瓣认为“友邻中会有不少人‘不一定是认识的’,可能只是为了关注他/她的评论或是推荐,但也需要加他为‘友邻’”,所以在这次改进中特意比较强调“朋友”和“关注”的不同关系。 我觉得这实在没有必要。

1、只需要给用户提供一种功能让他们可以方便的将“认识的好友”和“只需要关注”的人分开即可,没有必要非得问用户“他是你的朋友还是只需要关注的?”(现在的设计确实有些“非得问用户”的感觉。)

2、对于产品的设计者来说“朋友”和“关注”的概念区分清楚,对于概念区分后的好处也很明白。 但对于用户来说并不一定“有”这个概念和意识,一般只有尝试过“痛苦”(很多好友导致杂乱)的人才有。而尝试过痛苦的人根本不需要我们如此强调,他一样会去用。

比如,以前我参与的某个社区的好友有默认的几个分组(朋友、同事、家人、默认),后来数据显示用户一开始并不按照我们想像的去给自己的好友分组,甚至直接把我们给他的组删除了。

同样,flickr默认把好友分好了组,但实际上用他那个组的人并不多一样(这个没有数据证明,只是观察判断所得)。
3、很多时候加一个人是因为我“喜欢他”。比如,我在豆瓣上发现“柴静”,于是我会去点那个我最希望的──“加为朋友”,而柴静并不认识我,收到“我加她为朋友的请求”便去看了我的资料,对我有点兴趣想“关注”我,可按照豆瓣现在的设计逻辑她会去点“忽略(加为朋友的请求)”。。

矛盾来了:对我来说,“就算柴静不加我为“朋友”,那我“关注”也行,可以一般情况下我点了“加为朋友”就会很欣喜而忽略去点“关注”,(因为这个时候是很有信心会被她‘加为朋友’的)”;对于柴静来说,她忽略了我但想关注我,她必须再专门去我的页面点“关注”。

可见,把“加为朋友”和“关注此人”放在一起的后果可能是:一部分的“关注”会变得麻烦或者不去使用,一定程度上降低了“整体数量”。(起码“加为朋友的请求”处理那里,可以加一个“只关注此人”的按钮)

4、 “关注的人”和“朋友”是两套东西,但老用户是把原来的友邻改成朋友,如果他们后悔了需要再改成只是关注,目前没有好的解决办法,只能删除朋友,然后再去关注一下。

如果我设计这个功能改进的话:

1、保持原有“我的友邻”不变,在里面增加一个“我的朋友”。 而且这个增加只是在“我的友邻”列表的上面加一个“分组”,不会做到主导航上去,等于“增加了一个友邻的高级分组”。
要给用户的感觉是1+1:你原来有一间房子,我现在在旁边又给你盖了一间,你可以选择把部分人放进去然后制定不同的“政策”。

现在豆瓣的做法感觉是1/2:你有一间房子,我把他拆分成了两小间,默认把你原来房子里面的人都放进去了其中比价“低级”的那一间了。(用户会觉得“你侵犯了我”,把我的房子给拆分了)

2、好友的添加过程不考虑“双向”,但在好友列表里用一种不是十分明显的办法告诉用户“你这个好友是不是也加你为好友了”。系统在“推荐机制”算法时提高“互为友邻”的权重。

3、针对于“我的朋友”和“我的友邻”,用户可以自由设置“是否显示他们的各种广播”和“是否让他们看到我的各种信息”。简单说就是:“我想不想听你说话”和“我让不让你听到我说的话”,这样即解决了隐私问题,又解决了信息干扰的问题。 现在豆瓣只解决了隐私问题。

4、用户添加好友的时候依然只有一个按钮“加为友邻”,然后弹出选择“分组”。添加后的通知依然保持不变。

豆瓣在几千人的时候其实是在自己给自己设计产品,需要什么就加什么,(设计)架构上似乎并没有什么大的规划。但现在是在给百万人设计产品,设计人员甚至已经不能称为典型用户了,必须克服两个最大的困难:

1、依然“为自己设计”,强行把自己的逻辑和习惯套给所有用户,不考虑是否合适也不经过“简化和编译”;

2、不是在现有架构的基础上进行优化然后做扩展和调整,而是重新开始规划产品架构(往往重新做一个比改一个容易,但重新做了以后可能也要面临着去改…),过多的打翻老用户的已有习惯。

每一层新楼都得建在现有的“楼顶”上。基数越大,“改版”的风险成本就越大,时间越长系统越繁杂,往往也越“难用”。

豆瓣最近的升级和改动很多,每一次改动都会带来很多老用户的不适应,也会带来新的设计问题。 但愿豆瓣能够更好的平衡系统设计、新用户发展、老用户习惯等各方面问题。

同时建议豆瓣正式把“实验版”弄出来,让每一个新功能经过专门的实验版让更多用户开放性的参与一下。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号