上一篇
下一篇
[转摘]常见功能设计之 “小组”
作者:asky 日期:2007-08-06
提示：（本作文写了四个小时，建议长时间没有上厕所的朋友先去趟厕所再回来看..）
“小组”是每个社区型网站聚集人气提高粘度的重要手段，是社区型网站的咽喉；如果说好友是用户在网站上的一维关联的话，那么小组应该是用户在网站上的二维关联；社区产品在挖掘用户商业价值开始定位用户属性角度时，他参与的小组也许要重要与他的好友。
麦田曾推算出豆瓣小组的流量占据了全站流量的70%以上，我毫不怀疑这个结论的。（虽然阿北曾在愚人节的时候一正视听）
基本可以说”所有产品的小组都是呈长尾分布的”，无论人数、活跃度、内容数量等等；
头部的构成决定了产品的性质和方向，尾部却是该产品真正的价值所在。
“小组”的功能点大致可以分为几个部分：创建小组、加入小组、参与和展示
创建小组
1、对于百度贴吧而言，它要打造一个大众的巨无霸式的产品，任何一个关键词都是一个话题(小组)，所以他的产品设计基本上没有严格的所有”创建小组”的概念，它是这样的： （假如，你进入了一个尚未”创建”的柴静观察吧）
您好，您是第一个到达这里的人，柴静观察吧尚未建立！
欢迎您在此留言，发表对柴静观察的看法，并与今后来到这里的朋友们分享交流。
不得不说，这短短两句话的魅力是无可估量的。换一种不合适的说法也许马上就会使创建率至少降低一个两位数的百分点。
这里给我的感觉是：”这是一块肥沃的尚未开发的土地，锄头和铁锹已经在这里了，你很轻松就可以’创建’它”；让用户感觉自己已经到达了一块肥沃的目的地、一块即将被自己开发的土地，让用户感觉自己’发现了新大陆’，而不是在做别人都不去做的事情；而且紧接着在下面列出了发言的内容..
这个创建的方式，值得所有做开放式论坛的人学习和研究。
在某次讨论中有人曾说“不对创建加任何门槛会使小组的讨论和内容过于分散，不利于社区的发展和管理”，我反对了这样的说法。
我说：”用户会用脚选择加入那个小组的，无须产品管理者牵着鼻子走；百度在这里不需要设置门槛，如果在这里加了门槛的设置，实际上是试图把长尾的尾部移植到头部去。这是一种自以为然的做法，事实上是不可能做到的，因为尾巴永远是存在的，而且尾巴存在的价值甚至会大于头部。虽然这些尾巴”看似”是多于的”。
当然，我也同时认为：如果有一种完整的算法能够在这里告诉我”类似相关的吧”可能会更好些，比如根据关键词的相关度和某些算法在右侧列出：”柴静”、”新闻调查”等非常相关的贴吧，也许会是用户很需要的。
“我们应该适度的引导用户去他们更需要的地方，但无须牵着用户的鼻子走”。
2、Google论坛是前身是新闻组，典型的Google论坛是一个”小众的大众产品”：论坛内部的人是相对小众和集中的，但对于论坛这个产品的需求又是一个很大众的。
百度贴吧的创建者实际上是垦荒者 并非真正的拥有者，而Google论坛的创建者则是该论坛的拥有者，他创建的是”我的论坛”，而且从论坛本身的产品设计来说 它具有一个”常规论坛”所需要的几乎所有功能；和百度贴吧不同，Google论坛需要更加精准和过滤后的内容，这也要求他头部和尾部的差距相对会小很多。
Google论坛的”小众”定位决定了他在”创建“时需要用户填写一些精简后的内容和选项，是门槛也是一种天然的过滤。
不过，Google论坛在创建时的那些”选择访问级别”的解释实在是太啰嗦了，这样的”小作文”式的注释其实反倒增加了用户的理解难度。
3、豆瓣小组的定位比较中规中矩。所以他的创建过程也比较中规中矩，名称、介绍、标签是创建时的所有选项。
不过他在关于groupname的处理上比Google论坛做的要更加细腻和精到：
Google论坛在创建时需要用户自己填写一个groupname（也就是这个即将创建的论坛的固定目录名，如UCDChina的论坛目录名是”groups.google.com/group/UCDChina”），因为目录名是唯一的，所以如果目录名被占用需要重新输入一个新的。
这样的做法有两个不好：
1> 无形中增加了用户的创建成本，而且这个并非是必须的成本(虽然我们产品设计者认为有一个独有的好记的目录名对于论坛创建者和参与者都更加方便，但并不一定论坛创建者和参与者就一定觉得这样方便，更不一定非得需要这个’方便’)；
2> 无形中让有限的目录资源被浪费。（事实上某些长尾尾部接近无效的论坛并不很需要这个目录名）
豆瓣的做法是：在创建小组的时候不给创建者输入groupname的权限，默认给的groupname是该小组的数字ID编号；在创建後的”小组管理”里才可以申请groupname。这样：”需要groupname的人能达到自己的需求，不需要groupname的人不被强行要求(甚至有可能会因为目录名而被拒之门外)，某些注册小组后将其闲置的用户也很少会去浪费这个资源”。
Flickr在个人用户的目录处理上也是这样的。这种处理方式值得大部分开放目录名的产品学习。
关于”创建小组”的补充：
很多社区网站在创建小组或者在进行小组管理时就要求填写小组的”类别” 和选择(或上传)小组的”形像图片”，但我目前还没有看到有那个网站想到把二者结合起来的。
实际上选择类别很多时候是会惹发创建者不耐烦的，其实可以把”选择类别”和”选择形像图片”结合起来：当用户选择”计算机”类别时默认给他一个”计算机”的形象图片(当然，他也可以选择不用这个图片)，如果可能，当他先选择形象图片时也可以默认给他一个相对应的类别；
这里默认的形象图片是按照不同类别设计的，这样即增加了用户选择类别的乐趣和积极性又更好的避免了”用户经常只使用前面几个形象图片”。
加入小组
1、首先加入小组的权限设置是必须的，因为不同的小组对于此有着不同的需求。
2、当某个小组设置了”用户必须提交申请并通过管理员审核后才能加入”时，在这个小组管理的上就多了一个”验证管理”的任务点。
当UCDFeed的博客圈，在有人请求加入时，服务商Feedsky会发给我一个邮件告诉我：”诺曼.李希望加入您在Feedsky创建的”UCDFeed”这个圈子，他提交的Feed为http://feed.feedsky.com/lxxx,请点击这里进行审核。”
这种做法是最常见的做法，对我来说也是很好的做法。虽然我不能在这里就马上处理了，当它缓解了多个管理员的”管理层”内部问题。（虽然Feedsky现在只有一个管理员，但它将来势必需要多个）
3、如上例，按照小组的功能设计来说，这个”验证管理”的任务点本应该是在”小组”内有一个”待处理”的模块。
但往往产品设计者为了”让管理员更加方便的管理”而在”多了一个功能需求”时忙乱了手脚，他们不是在想办法”如何在这个设计的基础上满足多了一个功能的需求”而是”再去做一个设计来满足多了一个功能的需求”。
比如，QQ群的加入验证管理。（以下是我半年前弃用QQ群时看到的情况，现在也许有所改进。）
“UCDChina”QQ群有4个管理员，用户必须提交申请并通过管理员审核后才能加入。当诺曼.李请求加入该QQ群时，4个管理员同时收到要求处理请求的信息，他们都可以做出处理。
第一种情况：只要有任何一个管理员在第N个顺序中处理为”允许加入”，那么无论是在他前面处理的人还是在他后面处理的人做出的处理都是无效的，请求加入者诺曼.李会收到N个验证处理的信息，4个管理员都不知道自己的处理也许没有生效。
第二种情况：4个管理员都没有通过诺曼.李的加入请求，请求加入者诺曼.李会收到4个”被拒绝”的信息通知，4个管理员都不知道自己的处理也许没有生效。
第三种情况：xxx
可以看出，QQ在这里处理上的原则是”只要有管理员让加入者通过，那么他就通过了”，这是一种为了提高产品使用率的做法。 但这样做某种程度上损害了加入者和管理者双方面的体验。（加入者可能会收到N个处理结果，管理者不知道自己的处理是否有用）
4、Feedsky的圈子也存在一个不小的问题：
当我处理诺曼.李的申请点了”通过”后，系统告诉我：”诺曼.李已经加入了三个圈子，到达上限”之类的话，我无法把他加入进来。
这个时候我非常想告诉他：”哥们，你加入的圈子太多了我现在加不进来你，你给别的圈子退了吧”，可Feedsky没有给我提供这个功能。。
要不在诺曼.李申请加入圈子的时候就不让他申请三个以上，要不就给我提供这种通知的功能，要不xxx，反正别让我这样干着急最后只能把别人拒绝掉，而且他还不知道被我拒绝了…
5、豆瓣的小组是可以随便加入的、豆瓣的小组发言只有组内成员才能发言。
很多人说豆瓣这样做”很逗”：设置了只有组内成员才能发言，却又让用户随便加入，而且还在书评的下面给了一个”>加入这个小组”方便链接。自相矛盾。
还不如像百度贴吧一样直接在下面就给一个输入框让用户马上就可以发言。然后，发言的同时就算是加入小组了。
我反倒很欣赏这种做法，百度贴吧可以那样做，但豆瓣的产品定位相对”高”一些无须和百度贴吧一样做。豆瓣的这种做法可以过滤很大一部分的无价值的”垃圾发言”。
当一个无聊的用户看到某个书评以后，想发一个”顶”、”楼主NB”、”好帖”之类的话，发现自己必须”加入”，可能就会放弃了；当一个实在有话要说的用户想要发言时，他们不太在乎（或者说可忍受）这个”点一下就加入”的成本。
很多时候”点一下”也是一次有效的过滤。。
6、某些社区网站在加入时必须写一个”推荐人”(必须是小组内现有成员)的ID也很有意思。
参与和展示
1、放在首页的榜单一定是一个不真实的榜单。
那些把”最多点击的小组”、”最多成员的小组”、”最多回复的小组”放在首页上列出来的做法很不可取；
不过。豆瓣的”15分钟”名组的做法算是不错，某些网站的”一周内上升最快”也不错，某些按照多种综合算法算出来的榜也可以。
总之：如果你要在网站首页列一个榜单的话，应该一定考虑好你的算法。
2、当小组的内容不是通过互动得到，而是通过机器或者其他方式自动得到时，小组的活跃度和真正的价值就会随之降低。
比如，麦田同志做蚂蚁社区的时候因为自己没有内容，又不想流氓过来内容，于是就采用了一种半流氓的方法：让用户输入自己的BLOG地址然后派爬虫去把用户的内容都爬过来。
最后我们发现蚂蚁社区成了一个BLOG内容聚合的地方，互动的信息和留言回复很少；而且很大一部分用户还是会回去作者BLOG的源地址讨论。（在蚂蚁社区上回复的人大部分不是麦田的托儿就是一些比较初级的用户）
再比如，SINA前一段搞了一个非常有才的”双发“拔苗助长了一把。（所谓双发，就是blog作者在自己的blog上发一篇文章的同时会自动在sina的论坛上也发了一个一样的帖子）
结果…
3、sohu的博客群、sina的博客圈现在都已经成了内容分类集合的地方，基本上都已背离当初设想能够集中和促进互动的目的。
认为”一个博客圈就是一个大论坛”的想法有着很多的不现实，而且人的分类和内容的分类其实并不能完全对等。白鸦会写产品设计的博客 也会写生活的博客 还会写体育的博客、有时候还写写管理和人文的… 把白鸦和他的文章同时都分到设计类也许是有问题的。
4、以上2、3这些做法看不到成效还有一个重要的原因：玩论坛的人和玩博客的人其实并非是一类人，而且他们之间的互通和重合并没有理论设想的那么大；同一个用户在论坛上想做的事情和在博客上想做的事情也有着很大的区别。（这个结论有很多论据，在此不便列举。）
5、用户的参与感在小组的产品设计中非常重要，众多的小组在产品设计中并没有考虑新人或者参观者的感受，往往当我进入某个小组时感觉”他们都在玩自己的没人理我，我像一个外人”。
6、组内收藏、本组之星、相近的组等等小功能都是小组中一些极有意义的做法。
在社区中挖掘人与人的关系、圈子与圈子的关系、人与某个产品(商品)的关系、圈子与某个产品的关系的钱途不可估量…
最后，
不同的网站对于”小组”的定位和需求不同，不同的产品对于”小组”的设计需求也会有着很大的差异；
关于”小组”能写的实在太多太多，此篇只为引题，白鸦在此接受所有关于”小组”的产品设计探讨和指正，视得到的问题决定是否接着写更多关于”小组”的续篇…..
我一直没有想清楚一个问题：MSN的好友分组、多人会话、MSN群之间的本质区别和关联以及产品价值是什么，如何很好的阐述？
有兴趣的朋友可以一起探讨这个话题…
“小组”是每个社区型网站聚集人气提高粘度的重要手段，是社区型网站的咽喉；如果说好友是用户在网站上的一维关联的话，那么小组应该是用户在网站上的二维关联；社区产品在挖掘用户商业价值开始定位用户属性角度时，他参与的小组也许要重要与他的好友。
麦田曾推算出豆瓣小组的流量占据了全站流量的70%以上，我毫不怀疑这个结论的。（虽然阿北曾在愚人节的时候一正视听）
基本可以说”所有产品的小组都是呈长尾分布的”，无论人数、活跃度、内容数量等等；
头部的构成决定了产品的性质和方向，尾部却是该产品真正的价值所在。
“小组”的功能点大致可以分为几个部分：创建小组、加入小组、参与和展示
创建小组
1、对于百度贴吧而言，它要打造一个大众的巨无霸式的产品，任何一个关键词都是一个话题(小组)，所以他的产品设计基本上没有严格的所有”创建小组”的概念，它是这样的： （假如，你进入了一个尚未”创建”的柴静观察吧）
您好，您是第一个到达这里的人，柴静观察吧尚未建立！
欢迎您在此留言，发表对柴静观察的看法，并与今后来到这里的朋友们分享交流。
不得不说，这短短两句话的魅力是无可估量的。换一种不合适的说法也许马上就会使创建率至少降低一个两位数的百分点。
这里给我的感觉是：”这是一块肥沃的尚未开发的土地，锄头和铁锹已经在这里了，你很轻松就可以’创建’它”；让用户感觉自己已经到达了一块肥沃的目的地、一块即将被自己开发的土地，让用户感觉自己’发现了新大陆’，而不是在做别人都不去做的事情；而且紧接着在下面列出了发言的内容..
这个创建的方式，值得所有做开放式论坛的人学习和研究。
在某次讨论中有人曾说“不对创建加任何门槛会使小组的讨论和内容过于分散，不利于社区的发展和管理”，我反对了这样的说法。
我说：”用户会用脚选择加入那个小组的，无须产品管理者牵着鼻子走；百度在这里不需要设置门槛，如果在这里加了门槛的设置，实际上是试图把长尾的尾部移植到头部去。这是一种自以为然的做法，事实上是不可能做到的，因为尾巴永远是存在的，而且尾巴存在的价值甚至会大于头部。虽然这些尾巴”看似”是多于的”。
当然，我也同时认为：如果有一种完整的算法能够在这里告诉我”类似相关的吧”可能会更好些，比如根据关键词的相关度和某些算法在右侧列出：”柴静”、”新闻调查”等非常相关的贴吧，也许会是用户很需要的。
“我们应该适度的引导用户去他们更需要的地方，但无须牵着用户的鼻子走”。
2、Google论坛是前身是新闻组，典型的Google论坛是一个”小众的大众产品”：论坛内部的人是相对小众和集中的，但对于论坛这个产品的需求又是一个很大众的。
百度贴吧的创建者实际上是垦荒者 并非真正的拥有者，而Google论坛的创建者则是该论坛的拥有者，他创建的是”我的论坛”，而且从论坛本身的产品设计来说 它具有一个”常规论坛”所需要的几乎所有功能；和百度贴吧不同，Google论坛需要更加精准和过滤后的内容，这也要求他头部和尾部的差距相对会小很多。
Google论坛的”小众”定位决定了他在”创建“时需要用户填写一些精简后的内容和选项，是门槛也是一种天然的过滤。
不过，Google论坛在创建时的那些”选择访问级别”的解释实在是太啰嗦了，这样的”小作文”式的注释其实反倒增加了用户的理解难度。
3、豆瓣小组的定位比较中规中矩。所以他的创建过程也比较中规中矩，名称、介绍、标签是创建时的所有选项。
不过他在关于groupname的处理上比Google论坛做的要更加细腻和精到：
Google论坛在创建时需要用户自己填写一个groupname（也就是这个即将创建的论坛的固定目录名，如UCDChina的论坛目录名是”groups.google.com/group/UCDChina”），因为目录名是唯一的，所以如果目录名被占用需要重新输入一个新的。
这样的做法有两个不好：
1> 无形中增加了用户的创建成本，而且这个并非是必须的成本(虽然我们产品设计者认为有一个独有的好记的目录名对于论坛创建者和参与者都更加方便，但并不一定论坛创建者和参与者就一定觉得这样方便，更不一定非得需要这个’方便’)；
2> 无形中让有限的目录资源被浪费。（事实上某些长尾尾部接近无效的论坛并不很需要这个目录名）
豆瓣的做法是：在创建小组的时候不给创建者输入groupname的权限，默认给的groupname是该小组的数字ID编号；在创建後的”小组管理”里才可以申请groupname。这样：”需要groupname的人能达到自己的需求，不需要groupname的人不被强行要求(甚至有可能会因为目录名而被拒之门外)，某些注册小组后将其闲置的用户也很少会去浪费这个资源”。
Flickr在个人用户的目录处理上也是这样的。这种处理方式值得大部分开放目录名的产品学习。
关于”创建小组”的补充：
很多社区网站在创建小组或者在进行小组管理时就要求填写小组的”类别” 和选择(或上传)小组的”形像图片”，但我目前还没有看到有那个网站想到把二者结合起来的。
实际上选择类别很多时候是会惹发创建者不耐烦的，其实可以把”选择类别”和”选择形像图片”结合起来：当用户选择”计算机”类别时默认给他一个”计算机”的形象图片(当然，他也可以选择不用这个图片)，如果可能，当他先选择形象图片时也可以默认给他一个相对应的类别；
这里默认的形象图片是按照不同类别设计的，这样即增加了用户选择类别的乐趣和积极性又更好的避免了”用户经常只使用前面几个形象图片”。
加入小组
1、首先加入小组的权限设置是必须的，因为不同的小组对于此有着不同的需求。
2、当某个小组设置了”用户必须提交申请并通过管理员审核后才能加入”时，在这个小组管理的上就多了一个”验证管理”的任务点。
当UCDFeed的博客圈，在有人请求加入时，服务商Feedsky会发给我一个邮件告诉我：”诺曼.李希望加入您在Feedsky创建的”UCDFeed”这个圈子，他提交的Feed为http://feed.feedsky.com/lxxx,请点击这里进行审核。”
这种做法是最常见的做法，对我来说也是很好的做法。虽然我不能在这里就马上处理了，当它缓解了多个管理员的”管理层”内部问题。（虽然Feedsky现在只有一个管理员，但它将来势必需要多个）
3、如上例，按照小组的功能设计来说，这个”验证管理”的任务点本应该是在”小组”内有一个”待处理”的模块。
但往往产品设计者为了”让管理员更加方便的管理”而在”多了一个功能需求”时忙乱了手脚，他们不是在想办法”如何在这个设计的基础上满足多了一个功能的需求”而是”再去做一个设计来满足多了一个功能的需求”。
比如，QQ群的加入验证管理。（以下是我半年前弃用QQ群时看到的情况，现在也许有所改进。）
“UCDChina”QQ群有4个管理员，用户必须提交申请并通过管理员审核后才能加入。当诺曼.李请求加入该QQ群时，4个管理员同时收到要求处理请求的信息，他们都可以做出处理。
第一种情况：只要有任何一个管理员在第N个顺序中处理为”允许加入”，那么无论是在他前面处理的人还是在他后面处理的人做出的处理都是无效的，请求加入者诺曼.李会收到N个验证处理的信息，4个管理员都不知道自己的处理也许没有生效。
第二种情况：4个管理员都没有通过诺曼.李的加入请求，请求加入者诺曼.李会收到4个”被拒绝”的信息通知，4个管理员都不知道自己的处理也许没有生效。
第三种情况：xxx
可以看出，QQ在这里处理上的原则是”只要有管理员让加入者通过，那么他就通过了”，这是一种为了提高产品使用率的做法。 但这样做某种程度上损害了加入者和管理者双方面的体验。（加入者可能会收到N个处理结果，管理者不知道自己的处理是否有用）
4、Feedsky的圈子也存在一个不小的问题：
当我处理诺曼.李的申请点了”通过”后，系统告诉我：”诺曼.李已经加入了三个圈子，到达上限”之类的话，我无法把他加入进来。
这个时候我非常想告诉他：”哥们，你加入的圈子太多了我现在加不进来你，你给别的圈子退了吧”，可Feedsky没有给我提供这个功能。。
要不在诺曼.李申请加入圈子的时候就不让他申请三个以上，要不就给我提供这种通知的功能，要不xxx，反正别让我这样干着急最后只能把别人拒绝掉，而且他还不知道被我拒绝了…
5、豆瓣的小组是可以随便加入的、豆瓣的小组发言只有组内成员才能发言。
很多人说豆瓣这样做”很逗”：设置了只有组内成员才能发言，却又让用户随便加入，而且还在书评的下面给了一个”>加入这个小组”方便链接。自相矛盾。
还不如像百度贴吧一样直接在下面就给一个输入框让用户马上就可以发言。然后，发言的同时就算是加入小组了。
我反倒很欣赏这种做法，百度贴吧可以那样做，但豆瓣的产品定位相对”高”一些无须和百度贴吧一样做。豆瓣的这种做法可以过滤很大一部分的无价值的”垃圾发言”。
当一个无聊的用户看到某个书评以后，想发一个”顶”、”楼主NB”、”好帖”之类的话，发现自己必须”加入”，可能就会放弃了；当一个实在有话要说的用户想要发言时，他们不太在乎（或者说可忍受）这个”点一下就加入”的成本。
很多时候”点一下”也是一次有效的过滤。。
6、某些社区网站在加入时必须写一个”推荐人”(必须是小组内现有成员)的ID也很有意思。
参与和展示
1、放在首页的榜单一定是一个不真实的榜单。
那些把”最多点击的小组”、”最多成员的小组”、”最多回复的小组”放在首页上列出来的做法很不可取；
不过。豆瓣的”15分钟”名组的做法算是不错，某些网站的”一周内上升最快”也不错，某些按照多种综合算法算出来的榜也可以。
总之：如果你要在网站首页列一个榜单的话，应该一定考虑好你的算法。
2、当小组的内容不是通过互动得到，而是通过机器或者其他方式自动得到时，小组的活跃度和真正的价值就会随之降低。
比如，麦田同志做蚂蚁社区的时候因为自己没有内容，又不想流氓过来内容，于是就采用了一种半流氓的方法：让用户输入自己的BLOG地址然后派爬虫去把用户的内容都爬过来。
最后我们发现蚂蚁社区成了一个BLOG内容聚合的地方，互动的信息和留言回复很少；而且很大一部分用户还是会回去作者BLOG的源地址讨论。（在蚂蚁社区上回复的人大部分不是麦田的托儿就是一些比较初级的用户）
再比如，SINA前一段搞了一个非常有才的”双发“拔苗助长了一把。（所谓双发，就是blog作者在自己的blog上发一篇文章的同时会自动在sina的论坛上也发了一个一样的帖子）
结果…
3、sohu的博客群、sina的博客圈现在都已经成了内容分类集合的地方，基本上都已背离当初设想能够集中和促进互动的目的。
认为”一个博客圈就是一个大论坛”的想法有着很多的不现实，而且人的分类和内容的分类其实并不能完全对等。白鸦会写产品设计的博客 也会写生活的博客 还会写体育的博客、有时候还写写管理和人文的… 把白鸦和他的文章同时都分到设计类也许是有问题的。
4、以上2、3这些做法看不到成效还有一个重要的原因：玩论坛的人和玩博客的人其实并非是一类人，而且他们之间的互通和重合并没有理论设想的那么大；同一个用户在论坛上想做的事情和在博客上想做的事情也有着很大的区别。（这个结论有很多论据，在此不便列举。）
5、用户的参与感在小组的产品设计中非常重要，众多的小组在产品设计中并没有考虑新人或者参观者的感受，往往当我进入某个小组时感觉”他们都在玩自己的没人理我，我像一个外人”。
6、组内收藏、本组之星、相近的组等等小功能都是小组中一些极有意义的做法。
在社区中挖掘人与人的关系、圈子与圈子的关系、人与某个产品(商品)的关系、圈子与某个产品的关系的钱途不可估量…
最后，
不同的网站对于”小组”的定位和需求不同，不同的产品对于”小组”的设计需求也会有着很大的差异；
关于”小组”能写的实在太多太多，此篇只为引题，白鸦在此接受所有关于”小组”的产品设计探讨和指正，视得到的问题决定是否接着写更多关于”小组”的续篇…..
我一直没有想清楚一个问题：MSN的好友分组、多人会话、MSN群之间的本质区别和关联以及产品价值是什么，如何很好的阐述？
有兴趣的朋友可以一起探讨这个话题…
文章来自: 
引用通告: 
Tags: 评论: 0 | 引用: 0 | 查看次数: 4259
发表评论
你没有权限发表评论！
