欢迎来到千学网!
您现在的位置:首页 > 实用文 > 其他范文

豆瓣网交互设计:解读单向关系和双向关系...

时间:2022-07-14 08:37:08 其他范文 收藏本文 下载本文

以下是小编给大家收集的豆瓣网交互设计:解读单向关系和双向关系...,本文共6篇,欢迎大家前来参阅。

豆瓣网交互设计:解读单向关系和双向关系...

篇1:豆瓣网交互设计:解读单向关系和双向关系...

近期关于对豆瓣将“朋友”双向关系,改变为“关注”单向关系,用户之间有一些争议,

豆瓣网交互设计:解读单向关系和双向关系...

。这里我想表述一下我对此的理解,想用一些nodes图来表达。(画得比较简单,没我想象能表达清楚,可能)

1,“双向”确认关系,变成“单向”关注,是变简单了还是变复杂了?

假设9个节点(网络中的9个人),分别建立双向和单向关系如图A和图B,我们用纯粹双向和纯粹单向来对比。

A:

A图

B:

B图

A和B对于9个节点,假设哪些节点“随机”建立的关系是完全一样的。很明显A图的双向关系,在“链接数”上要明显多于B图,A正好是B的2倍。

问题则是:在豆瓣这样的“以兴趣为导向的社区”,是不是两种图都是有效的?如果在完成“以兴趣为导向传递信息”这一层面上,两者都能达到效果,那么整个网络要达到A要比达到B复杂。除非,B完成不了“以兴趣为导向传递信息”,若有这个怀疑,可往下看。

2,“单向关系”利于“区隔”,而“双向关系”不利于“区隔”

假设,有一条信息从节点5开始传播,蓝色代表“info”会到达路径

A1:

A图中,该“info”几乎可到达所有节点,因为关系都是双向的,5周边节点都会接收到信息,若被“转发”,则传播到“6,7,8,9”的可能性很大,除非3节点截住此信息。

B2:

在B图中,5节点的信息只会被传播到“2,4,1”,不会再传到其他节点,因为没人继续关注“2,4,1”。

真正的网络关系会比A和B要复杂很多,但对比以上可看出,信息的传播,在双向关系里很容易传播到各个圈子里去。这一点对于SNS网站是有帮助的,他们需要促进互动。但在豆瓣这样一个”以兴趣聚集同好”的圈子里,它带来了人群难以“区隔”,带来大量无用信息,会伤害整个社区网络的扩展,

3,双向关系在网络中,对某些节点的直接干扰

还是A图和B图,大家有没有发现,3节点是链接数最多的,在A图中,4、5、6、7对3的关联,都需要3进行回应和确认建立;而实际上,3很可能是“信息原创者”or“权威者”,4、5、6、7在B中都是“单向关注”3,在B图中,3什么都不用做。

有人会说,这种关系确认并不是干扰,大家需要这种申请和确认。

在实名的SNS网络中,整个网络的关系确认建立在“我是否认识他”,有这个保证,确认的干扰并不大(虽然现在人人上,这种干扰也大了起来);在豆瓣这样的匿名生人网络,这种双向关系的建立,并没有建立在“我是否认识他”的基础上,基本上是很随意在加朋友,整个网络中干扰的程度就相当高。

4, 豆瓣里Feed流起的作用:通过people发现兴趣内容

单向关系网络更加方便“发现”信息,而不方便“search”信息(虽然目前搜索引擎主要在解决search问题)

我们熟悉“六度理论”,但实际上你要“search”到一个路径,通过6次就能认识“ ”并不容易,为什么呢?因为你不一定找到了“最短路径”,如下图:

节点9要找到节点5,最短路径是黑色部分,3次链接;但从节点9开始,到达一个节点,就需遍历一下该节点的链接,选取某个链接继续遍历,而不一定能通过最短路径到达。

但信息Push则不是,假设3关注5,7关注3,9关注7。 节点5发出的信息,即使会经过follow它的几个链接,只要能到达节点3,再通过3发出信息到达更多节点,其中有节点7;再通过节点7转发到节点9,则信息总会通过最短路径能push到最终节点处。

这就是豆瓣广播在起的作用。

在单向关系网络中,用Feed流能使得“兴趣内容”通过网络push到用户处;更好的是,这个网络是单向的,人群能够有所“区隔”,so“某一兴趣内容”能通过关系push到“喜欢这类信息”的用户处,用户本身也能够控制自己“follow”的节点来控制自己所接收到的feed信息流。

延伸一些:

1,上面的A图和B图没能更好表达实际网络中双向和单向关系可能有的情况;

2,为了更好阐述“双向和单向,简单还是复杂?”, 请大家想一想,如果整个互联网上的网页和网页之间,不是单向随意 “链接一个URL”来引用另一个网页,而是必须“交换链接”,整个互联网

篇2:再说“双向”好友。(谈豆瓣好友改版)交互设计

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

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

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

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

同时建议豆瓣正式把“实验版”弄出来,让每一个新功能经过专门的实验版让更多用户开放性的参与一下,有助于在正式上线的时候减少问题,有助于优化设计,更有助于减少部分老“活跃用户”的意见。

网友评论(26)

DeadFire- 08/02/02 5:45 PM

真难为白鸦了,我每天没啥事情忙,可是仍然没有时间去看豆瓣,更别说要对这个网站做这么细致的研究和深入分析了。

白鸦看样子应该很忙,可是仍然写了这篇文章,真是厉害厉害。得给大家透露透露时间管理的方法,

还是说写这些其实就是每天要做的工作?或者这个是专门应豆瓣网的请专门写的?

蓝皮- 08/02/02 5:51 PM

豆瓣这个调整用户感受相当不好,最重要是增加了用户成本。

我觉得豆瓣在意图复制现实中的朋友等级关系,可能接下来要有更大动作了。

打个比方吧,我和你现在互为友邻,但是要加你为朋友,我得揣测你对我们关系的看法。如果我加你,而你不加我,岂不是心理感受很不好。所以,我干脆还是不加好了。

这篇文章转到“我是用户”小组了:www.douban.com/group/topic/2584017/

白鸦- 08/02/02 5:52 PM

@DeadFire 我每天有16-18个小时在上网,阅读时间4,做“用户”的时间8,具体工作时间4。

不是豆瓣邀请的,我基本上不写“命题作文”,自己有感受了才会去写自己真实的感受。没有就不写。

十三香- 08/02/02 6:15 PM

我要是豆瓣的UE就好了,有这样的高手关注

有时间请光临www.poco.cn多提宝贵意见哦哦!

langmuir- 08/02/02 6:47 PM

惊叹于白鸦旺盛的精力。

豆瓣在UE方面很下工夫。

挥雨- 08/02/02 7:09 PM

好文章。分析得很好,我也不喜欢这次的改版,让人不知道朋友的定义是什么。

尤其最后还给出了可借鉴的建议:“建议豆瓣正式把“实验版”弄出来,让每一个新功能经过专门的实验版让更多用户开放性的参与一下,有助于在正式上线的时候减少问题有有助于优化设计,更有助于减少部分老“活跃用户”的意见”

jesea- 08/02/02 7:51 PM

facebook的好友设计是一个典范,以我个人经历,不管是在技术/功能逻辑/实现逻辑上,都做的非常好,minifeed和notify按不同功能分开。分别告诉用户完成了什么,其它还有什么需要去完成,其中notify中可以是好友邀请(类似于谁成为了你的fans)。

而目前douban在原来关注的基础上再加入好友功能这一设定明显是典型的模仿facebook的作法,并不是模仿就不可取,而是douban的系统在最初并不是这么设计的,现在在原来关注功能的基础上再加入双向好友这一功能,显得非常的生硬,个人感觉与其这样改,还不如改进原来的关注功能,做个双向关注如何?这样也不会导致已经习惯原来系统功能的用户在出现新的好友功能后不知何去何从!~

一句话,douban的这一功能设计是一大败笔!~

jesea- 08/02/02 8:09 PM

PS1:对于任何增加用户操作量的功能都要三思而后行,包括目前douban这次好友改版,以及白鸦提出的”保持原有’我的友邻’不变,在里面增加一个’我的朋友’”.

PS3:白鸦博客评论提交很慢,所以有时提交会以为没响应,点两次“确定发表”…建议提交时可以disable button

Ami- 08/02/03 10:09 AM

作为一个每天都去豆瓣的用户,我觉得豆瓣无疑是在牺牲我们的感受为迎合更多的新用户。

但同时我也怀疑,这样子的豆瓣新用户也能上手么?

草根网- 08/02/03 10:13 AM

好文,收藏至20ju.com

白鸦- 08/02/03 10:47 AM

Keso在他的豆瓣广播里这样说:好像点击“加为朋友”按钮的比例,要远远多于点击“关注此人”的比例。在我这里,大概是5:1的比例。是不是加为朋友这种说法显得更亲近,更磊落,而关注此人好像有点偷偷摸摸?

我回复:@keso 我觉得原因是:关注你的人一般都是希望成为你好友的人,所以他们会去点“加为朋友”。虽然他们也能同时再点关注你,但往往更多人在这个时候做的是“单选” 而不是“全选”。 … 如果假设豆瓣的用户20%是“领袖”,80%是“平民”的话,“关注”实际上更多是在为“领袖”服务的,领袖才需要将友邻分成三六九等,而平民一般不需要 (他们需要“分组”,等不是“等级”)。

则鸣- 08/02/03 11:23 AM

恩,今天上豆瓣发现多了个“加为朋友”的功能按钮,觉得挺陌生,原来是改动啊~

zheng- 08/02/03 11:35 AM

关键在于,豆瓣是object导向的SNS,不是类似Facebook导向的,所以双向的确认很滑稽,当然了,除非豆瓣在为未来的转型准备。

Flickr其实的方案其实对于豆瓣很好的,但是有个问题,flickr中有些需要给朋友、有些需要给家人,而在豆瓣上,是不需要的。。。

viviangel- 08/02/03 11:45 AM

会拉远网络ID之间的距离。

nickyhu- 08/02/03 12:42 PM

无疑,这是为以后的更多功能铺路。不完成这个,后面功能没法推啊。

所以用户体验其次,产品形态更加重要。

bbbush- 08/02/03 1:38 PM

好友和关注不是一回事,正常人会关注好友关注的东西,却不会关注关注对象的好友或者关注对象。我觉得还可以说是友谊和隐私的区分:好友就是要让渡一部分隐私。在 LiveJournal 上可以把好友分类,douban 是对 LJ 的延伸。

» links for -02-04 卡尔胃弱: 卡尔胃弱又懦弱- 08/02/04 10:26 AM

[…] 白鸦 » 再说“双向”好友。(谈豆瓣好友改版) (tags: 产品 豆瓣) […]

lecause- 08/02/04 6:35 PM

白鸦老师提出的解决方法其实就是flickr嘛……

我认为一个社区建立之初的好友关系不能做太大的改版,否则真的很麻烦。twitter的friends->followings就是一个例子,虽然底层没动,但是光改一个名字也够人受的

leee- 08/02/08 7:00 PM

白鸭老大能不能联系上帆哥,让他帮我域名abada.cn续费,款汇到农行了

我的豆瓣好友解决方案 - 九翼青鸟 - 九翼青鸟的二进制世界——专注于电子商务与用户体验研究- 08/02/12 10:37 AM

[…] 然后白鸦又写下了洋洋洒洒的千字长文《再说双向好友》。 […]

九翼青鸟- 08/02/12 10:39 AM

洋洋洒洒千字长文。个人却觉得没这么复杂。

请见《我的豆瓣好友解决方案》

d9wing.com/89

欢迎来批!

九翼青鸟- 08/02/12 10:40 AM

20楼的评论为误发,麻烦连同本条评论一同删除。

不好意思。

醉中仙- 08/02/13 2:15 PM

好友的事情,各W站理不一致,^大了。

最好好事者,搞一什麽强制实牧耍MD。

redfall- 08/02/15 3:19 PM

好久没去豆瓣了,刚才去转了圈发现改了很多,添加了很多功能,感觉以前好用些,

现在是尝试的去点击,惴惴不安的体验过程很不爽!

引用几句话给豆瓣:

“用户的注意力是有限的资源。

添加的任何一项功能都将有可能是用户找到另外一项功能的绊脚石。

如果必须添加一些功能,试图替换掉另外一项类似的功能。

经常需要为了一些功能的易用性牺牲另外一些功能。”

图书城- 08/02/29 9:15 AM

很多人对豆瓣最近的改版向sns的转换有自己的看法,其实我觉得这是豆瓣发展路上的必经之路,豆瓣由一个纯书评网站发展为现在国内首屈一指的社区网站,而且拿到了数百万的投资,如果仅靠卖书的那点提成,在收入上很难形成快速的增长。还有,我向你推荐一个新的书评网站:图书城(www.TuShuCheng.com)。图书城是专业的图书搜索和比价网站,还结合了各大网站的书评内容。有些类似豆瓣,但在图书方面更加专业化,页面更快速简洁,希望大家去看看,也可以注册一下试着建立你的读书档案:)

大森林的blog » Blog Archive » 设计“好友“- 08/03/01 11:23 AM

[…] 白鸦借豆瓣改版又写了一篇blog:《再说“双向”好友。(谈豆瓣好友改版)》。借豆瓣的好友问题再一次的强调双向好友不符合人们的现实生活规律。 […]

来自:uicom.net/blog/?p=713

篇3:豆瓣光箱设计交互设计

在Think about usability (1)一文中看到作者提出一个关于豆瓣光箱设计的观点,作者Leechael给出了两张图片

上图是豆瓣现有的设计

下图是作者提出的改进建议

作者Leechael在其文章中这样说到:

第二幅图中的目标是不是比第一幅图中的效果更明显、体验也更好?在不仅是有一个条目的页面中,针对一个特定条目进行操作,光箱效果(lightbox)明显不是一个很好的选择,

我特地拿别人的文章来讲,很自然的我是要发出不一致的声音,

我的观点是豆瓣目前的设计是更好的,当然可以再更好一些,而第二张图片所演示的设计,虽然不错,但在体验上实际并不那么“乌托邦”。

建议提出者Leechael的立足观点是“针对一个特定条目进行操作”的设计,固然从静止的截图看确实如此,但如果从用户完整的操作点击过程来看却不是了。“光箱”从静止状态下是看不出对哪一个指定条目的操作,但用户在操作过程中知道自己刚刚点了什么,“光箱”设计让用户更加专注于当前与接下来的操作,反之这个新提出的建议则可能会让用户在接下来的设计中更容易分心。

交互体验设计之难,就在于交互是个动词,体验设计处理的应该是一个动作,而不是一个静止的平面。交互体验设计之美,也在此处。

本文出自:nihaozzb.cn/635829

篇4:可用性和用户体验的关系交互设计

原文:Usability and user experience 作者:Richard Caddick

译者:耿人杰 译文来自:gengrenjie.com/archives/571

引言:现如今,关于可用性和用户体验的内容铺天盖地,但这两者到底是什么关系呢?通过这篇译文你可以有所感悟。

———————————— 全文的分割线 —————————————

DJ 和 Bonny展开了一场以“品牌的用户体验”为主题的对话。这场对话也引发我们去探讨可用性(usability)和用户体验(user experience)的差别。从我的角度看,这两者同样重要。

正如DJ提到的,很多在相同领域的客户都面临相同的可用性问题。我们很幸运的曾经和几个在相同领域的公司合作,因此我们针对两者的区别有一些想法可谈。

我对两者的定义是…

首先让我们看看国际标准化组织(ISO)是如何来给可用性下定义的。在ISO9421里提到,某一事物的可用性应当可以以效力(effectiveness)、效率(efficiency)和满意度(satisfaction)三个维度来进行衡量。

效力(effectiveness)是指用户是否可以完成任务。

效率(efficiency)是指用户完成任务的快慢(这点在web和某些非关键应用上的重要性略低)

满意度(satisfaction)是衡量用户是否很享受完成任务的过程(最有趣的可能是具有高满意度将影响用户对效力和效率的看法)

那什么是用户体验呢?

用户体验是关于用户和品牌间的一个更大的概念,

所以不只是一个是否可用的问题,而是如何让用户更简单的理解、参与其中并与品牌展开对话的问题。

这个问题真是太大了!这要求每个人,包括从管理层到一线员工(包括设计师、开发人员、文案人员和经理)都用相同的方式思考并实施。

你不需要见解(eyes),你需要的是愿景(vision)

这是问题的关键。如果缺乏一个针对你想创建的用户体验的非凡愿景,你很难建立伟大的用户体验。

看看那些伟大的品牌:Apple、Innocent Drinks、Nike、Howies。如果你与这些品牌的任何员工交谈,他们都能和你分享他们公司的愿景以及这些愿景意味着什么。

这些对你的网站/移动应用/业务简报(newsletter)/应用有什么影响?

尝试去思考这些内容,并把它比作你的同事,而不是一个对象。

作为一个你想让他谈论品牌的同事,你将如何使他们加入到你的用户中来。

事实上,他们所拥有的网站将是品牌表现的一部分。所以,网站看上去如何、他们说了些什么、他们对于抱怨如何反馈都是品牌对外表现的一部分。

所有的这些对于创建伟大了用户体验都非常重要,确保这些事情一切正常是必须做到的。

反过来看看那些在相同领域的品牌,就很容易看出他们有着相同的愿望但却试图着拥有不同的用户体验。

篇5:“好友”的设计应该单向,还是双向

白鸦很早就写过一篇文章,《常见功能之“好友”设计》,探讨交互网站中几乎必配的 “好友”功能,文章中,白鸦的观点是:“张三认为李...

白鸦很早就写过一篇文章,《常见功能之“好友”设计》,探讨交互网站中几乎必配的 “好友”功能。文章中,白鸦的观点是:“张三认为李四是他的好友,那么李四就是他的好友。。。。。。所以,张三如果加李四为好友无须李四同意”;因此白鸦说:“我基本不赞同99%的“需要对方验证才能添加对方为好友”的做法”。

下面就是我对这个问题的看法。而为讨论方便计,我把白鸦设计的“好友”模式简述为“单向”;而需要被加好友确认的模式,可以算是“双向”的。“单向”好友的案例有 ;“双向”好友的案例有新浪博客.

在讨论“好友”模式的单、双向问题之前,我特别赞同白鸦文章中,一位网友的观点:BS(web)模式下的“好友”功能其实不重要。对于非专业的交友网站,或者网站主要业务不是建立在“好友”关系之上――对这样的绝大多数网站来说,“好友”设计的重要性,远不如输入编辑器。编辑器是几乎人人要用,而好友功能,站方设计n多,其实用户都不会用的,用户会直接用qq或msn建立并维护自己的好友。这里我也多说一句,一些产品人员喜欢对设计“好友”下过多精力,考虑良多,做的花哨;但真的还不如花时间琢磨如何让编辑器更完善。比如就以搜狐博客来说,他的好友功能纸条功能,我从来不用;但每次我用word把文档复制进搜狐博客后,它的编辑器的换行都多了一行,使得段落间距凭空增大,页面非常不好看。

不过,虽然web模式下的好友不重要,但对于一些网站,比如蚂蚁网,因为某些特殊原因,虽然不是交友网站,但好友设计也非常重要。所以在考虑蚂蚁网的时候,我把好友的问题梳理了一下。

先说单向好友模式到底有什么好?两个字:“轻盈”。这两个字解释起来就是一篇长文,所以我只谈一下其内在逻辑:单向好友的模式是符合web模式下,用户交友特点的――除了我上面说的两类特殊网站,其他网站的用户压根不在乎web模式下交友;所以干脆站方就做一个“轻”的应用:大家随便加好友,你爱加谁是谁。打个比喻,这其实和贴吧类似:反正大家就是上去扯淡,干脆也不注册了,大家随便扯。

再说单向交友模式有两个问题:

第一,对某些高端用户来说,会可能产生不太爽的感受。比如,“张三如果加李四为好友无须李四同意”,那么,李四如果看到自己出现在张三的好友列表,会隐约不爽――我认识你嘛?凭什么我就成了你的好友?但这个问题其实是小问题,更甚至,这个问题其实对某些网站站方来说是好事。因为站方潜在的鼓励大多数的草根用户“拉大旗做虎皮”――记得那个典故吗,“我的朋友胡适之”。:)也就是说,像新浪“名人博客”,其实恰恰需要使用“单向好友”,而不是现在的“双向好友”――草根用户如果有“我的好友徐静蕾”,虚荣心大大满足;而徐静蕾看到了虽然腻味,但是她看草根博客的概率极低;且激励徐静蕾继续写博的动机肯定能让她忍受这点小腻味.

第二,单向好友功能,其本质是一种“订阅”关系,所以如果以“好友”之名,有点名不符实,

这算是一个真实的麻烦。有的网站,比如豆瓣换成了“友邻”。我认为这样稍微换个说法,要比直接用“好友”好点。

所以到这里,我还是基本同意白鸦的观点;但我有个补充,“对于非专业的交友网站,或者网站主要业务不是建立在“好友”关系之上”;那么,确实可以99%的好友关系是“单向”的――因为对他们来说,“好友”压根不重要;那就不妨“轻盈”地处理它。

那么,为什么需要“双向好友”模式呢?我刚才说了,“单向好友”模式其本质是“订阅”,而不是真正的“好友”――只有“双向好友”模式才能真正开始“好友”之间的互动,否则两个人的关系只能是“订阅”关系。

我以蚂蚁网的设计来说。比如,我们做的一个功能,“向好友推荐”。蚂蚁网如果是“单向交友”模式,“张三如果加李四为好友无须李四同意”,那么,李四的“向好友推荐”应该向谁呢?是向自己并不认识的“张三”,还是向自己加的同样未经对方同意的好友?前者,对于李四来说,没有动机;后者,对于李四来说,他是在发垃圾信息――以此例说明,如果你有一项业务是要建立在好友关系之上的互动,那么你可能只有用“双向交友”模式。而作为对比,豆瓣采取“单向”模式的“友邻”,就没有这种好友之间的主动互动。

单向模式“轻盈”,但只是订阅,不能建立好友之间真正互动;双向模式能建立好友互动,但笨拙。那么,我一个站上,能否把这两种模式同时都使用,让用户自由选择呢?――我认为,这样做产品的思路,是有问题的:表面上,你提供了一个全面解决方案,但更大的问题出来了:你站方准备引导用户使用哪种服务?本来100个人,要么用单向,要么用双向,都能玩起来;但现在你潜在诱导让50人用单向,50人用双向,两种模式都玩不起来。

那么能否优化一下呢?比如,当“张三”加李四好友后,张三就完成了对李四的订阅(单向);同时李四收到需要确认消息“你同意张三加你为好友吗?”。李四如果“同意”,则张三和李四建立双向好友;李四如果不同意,也不撤销张三对李四的订阅――这个方案比上一个方案优化了一点,因为它弱化了两条线的引导,还是只强调了单向好友这一条线;但又有了双向补充。不过,我认为这样的优化方案依旧不可取,因为这个方案还是会需要用户在内心建立两个模型:

1,真正的好友(双向);2订阅关系的好友(单向)。我认为,这样会为用户增加困扰,得不偿失。

总结一下:

1,web模式下的好友关系,不是想象中那么重要,多数情况下,单向好友足够

2,使用“双向模式”的条件是网站的关键业务,需要建立在好友关系之上

3,要么单向,要么双向,不要试图同时单、双,那是小聪明,会增加用户困扰

篇6:白居易与元稹关系解读

俗话说“文人相轻”,但在唐代文坛上,却有两个文人给后人留下了文人相亲的佳话。他们是白居易和元稹。两人的友谊,是在共患难中建立起来的。

相识

白居易和元稹自贞元中(公元802年左右)结识,因为这一年他们同登科第,一起被分配到秘书省当校书郎(“同年同拜校书郎,触处潜行烂漫狂”),成了同事。然后他们两人就“一见钟情”,由此开始了至死不渝的“恋情”。

他们当校书郎时,流连于花前月下,有诗为证:“花下鞍马游,雪中杯酒欢”、“月夜与花时,少逢杯酒乐”,而且竟然是“春风日高睡,秋月夜深看”,这个,这个,读出“春宵苦短日高起,从此君王不早朝”的味道了没?而一旦白居易被调到长安城郊当县尉时,元稹就痛苦地写诗道:“昔作芸香侣,三载不暂离。逮兹忽相失,旦夕梦魂思。崔嵬骊山顶,宫树遥参差。只得两相望,不得长相随……官家事拘束,安得携手期。愿为云与雨,会合天之垂。”

类似的亲密之句不胜枚举,如元稹诗《三月二十四日宿曾峰馆,夜对桐花,寄乐天》中有:“夜久春恨多,风清暗香薄。是夕远思君,思君瘦如削”等句,白居易见到这诗后,也情意绵绵地回道:“昨夜云四散,千里同月色。晓来梦见君,应是君相忆。梦中握君手,问君意何如……”还有这首,《待漏入阁书事,奉赠元九学士阁老》中,竟然写道:“诗仙归洞里,酒病滞人间。好去鸳鸾侣,冲天便不还”。

相思

元和四年(公元809年),白居易回京升为左拾遗,但元稹当年却任职为监察御史,经常要四处办案。这一年,又是一个春光明媚的三月,在长安的白居易与弟弟白行简及好友李杓直等人,游玩了大雁塔下的慈恩寺后,就一起饮酒叙谈。

席间,白居易题诗一首于壁上:“花时同醉破春愁,醉折花枝作酒筹。忽忆故人天际去,计程今日到梁州。”

而后来,元稹恰好是到了梁州(今陕西褒城),写诗道:“梦君同绕曲江头,也向慈恩院院游。亭吏呼人排去马,所惊身在古梁州。”

晚唐郑谷诗中就这样说:“酴醿香梦怯春寒,翠掩重门燕子闲。敲断玉钗红烛冷,计程应说到常山。”这就是妻子挂念丈夫的事情了,《红楼梦》第十三回中写“话说凤姐儿自贾琏送黛玉往扬州去后,心中实在无趣…… 这日夜间,正和平儿灯下拥炉倦绣,早命浓薰绣被,二人睡下,屈指算行程该到何处”,此处甲戌本脂批就道:“所谓‘计程今日到梁州’是也。”

相伴

元稹和白居易,他们真正是一对患难见真情的“伴侣”。

当元稹母亲去世,归乡守丧“丁忧”时,过得十分艰苦,《遣悲怀》中说爱妻韦丛跟了他后,是“野蔬充膳甘长藿,落叶添薪仰古槐”,这情景也不完全是艺术夸张。这时,是白居易大力资助他,帮他度过了那段艰难的日子。

之后,当白居易也因为母亲去世,在乡村守丧时,元稹慷慨送他二十万钱,让丧母后又失去幼女的白居易得到不少安慰:“三寄衣食资,数盈二十万。岂是贪衣食,感君心缱绻”。

元稹的爱妻韦丛去世后,曾写下三首著名的《遣悲怀》,此事尽人皆知,就不多提了,而令人奇怪的是,白居易竟然以韦丛的口吻写了首《答谢家最小偏怜女》,其中写:

嫁得梁鸿六七年,耽书爱酒日高眠。雨荒春圃唯生草,雪压朝厨未有烟。

身病忧来缘女少,家贫忘却为夫贤。谁知厚俸今无分,枉向秋风吹纸钱。

后来,先是元稹因冲撞了宦官,被贬出京城,后来又贬到通州(四川达县),他愁病缠身,常常忧心自己会病死在异乡。元稹曾写信给白居易诉苦道:“通之地……大有虎、豹、蛇、虺之患,小有蟆蚋、浮尘、蜘蛛、蛒蜂之类,皆能钻啮肌肤,使人疮痏。夏多阴霪,秋为痢疟,地无医巫,药石万里,病者有百死一生之虑。”

“黄泉便是通州郡,渐入深泥渐到州”,元稹自料必死,于是将自己的诗稿整理了一番,辑为二十卷,托附给白居易。元稹凄凄惨惨地踏上遥远的行程。他形容自己是:“饥摇困尾丧家狗,热暴枯鳞失水鱼”。

然而,没过多久,白居易也被贬去江州,元稹得到消息,惊得从久病床榻上坐起身来:“残灯无焰影幢幢,此夕闻君谪九江。垂死病中惊坐起,暗风吹雨入寒窗”。可谓情真意切意难平!

你做诗来我相随

白居易首先提倡《新乐府》诗体,而元稹就马上和了十九首。味道也极为相似,时称为“元和体”。我们知道白居易的诗风是通俗浅易,老妪能懂的那种。而元稹的风格也大体相似,当然反对他们的就讥为“元俗白轻”。他们之间的默契度,实在是太高了。

当年此日花前醉,今日花前病里销。独倚破帘闲怅望,可怜虚度好春朝。

如果隐去名字,这怎么像是两个大男人之间的感情呢!想象当年花前月下的欢醉之乐,如今却孤身一人带病观花,愁倚门帘,怅然远望,独自喟叹,辜负了这“良辰美景奈何天”,

这么看,元、白之间的感情,还真不是那么正常。

至死不渝

虽然元稹对待崔莺莺是始乱终弃,又害得一代名妓薛涛得了相思病,但他对白居易却是深情不渝。元白两人的感情,可谓是白头到老了。

后来,俩人的官位可谓是青云直上,都成为金章紫绶的三品大员(在唐代,成为三品大员,几乎就是人臣中的顶峰),但元稹不为当时的朝臣所容,后来外放到越州当刺史,白居易于是也跟着要求出京,到了相邻的杭州做官。

两人的治所相近,又都是当地一把手,可以“假公济私”,用传递公文的驿使来互通“情书”,但这两个头白如雪的老头还是很珍惜相聚的日子,有一次,元稹来杭州探访,聚了三日有余,临别时,元稹依依不舍地说:,

莫言邻境易经过,彼此分符欲奈何。垂老相逢渐难别,白头期限各无多。

“垂老相逢渐难别,白头期限各无多”,看来,尽管时光不断地飞逝,元白的感情却一直没有改变,甚至是岁久弥深,对彼此的依恋,越来越重了。元稹和白居易最后一次见面,是在洛阳,当时元稹从越州回京师时,特地去探访闲居东都的白居易,临别时,写下这样两首诗:

君应怪我留连久,我欲与君辞别难。白头徒侣渐稀少,明日恐君无此欢。

自识君来三度别,这回白尽老髭须。恋君不去君须会,知得后回相见无。

吟罢这两诗,二人执手良久,才怅然分别,然而,这却是元、白的最后一次相见。不久,白居易就得到了元稹在武昌任所突发急病而死的噩耗。他回味这两首诗,越读越觉得,这就是元稹提前写给他的临别赠言啊!这难道是冥冥中的天意,魂魄中的先知吗?

情定三生?

元稹死后,白居易痛不欲生,在给好友的祭文中写道:“呜呼微之!始以诗交,终以诗诀,弦笔两绝,其今日乎?呜呼微之!三界之间,谁不生死,四海之内,谁无交朋?然以我尔之身,为终天之别,既往者已矣,未死者如何?……与公缘会,岂是偶然?多生以来,几离几合,既有今别,宁无后期?公虽不归,我应继往,安有形去而影在,皮亡而毛存者乎?”

晚年的白居易,奉佛行善,将很多钱财都捐给了佛寺,他的动机和祈愿是什么呢,他写的《修香山寺记》中说得很明白:“呜呼!乘此功德,安知他劫不与微之结后缘于兹土乎?因此行愿,安知他生不与微之复同游于兹寺乎?”看到了吗,求佛积善,无非是想和元稹(微之),再结后生之缘。

那元稹有没有结再生缘的念头呢?也有诗为证,元稹的《寄乐天》中早就说过:“无身尚拟魂相就,身在那无梦往还。直到他生亦相觅,不能空记树中环。”

这俩人都好到什么份上了?早就盟定三生了。假如他们俩真是一男一女,那真是一段非常完美的爱情佳话!

arp双向和单向欺骗原理解析

关系代词教学设计

关系的意思和造句

销售部和市场部的关系

公平与效率关系的科学解读

什么是文学创作过程中的主客体双向建构关系?

张三丰和太极拳有关系吗?

工资关系和行政介绍信是什么

四年级《三角形三边关系》教学设计

技术全球化和技术本土化:冲突中的合作--两种技术空间进路的交互关系分析

《豆瓣网交互设计:解读单向关系和双向关系...(通用6篇).doc》
将本文的Word文档下载到电脑,方便收藏和打印
推荐度:
点击下载文档

文档为doc格式

点击下载本文文档