讨论组和群,要区分开来吗?

多人聊天究竟需不需要区分讨论组和群?和作者一起思考一下~最近在做APP里的消息模块,在调研多人聊天这个场景时,发现QQ移动端已经在概念上不区分讨论组和群了,统称为群聊,只是在创建方式上分为:选人创建和按分类创建。而选人创建对应的是传统意义上的讨论组,按分类创建对应的是传统意义上的群。

多人聊天究竟需不需要区分讨论组和群?和作者一起思考一下~

讨论组和群,要区分开来吗?

最近在做APP里的消息模块,在调研多人聊天这个场景时,发现QQ移动端已经在概念上不区分讨论组和群了,统称为群聊,只是在创建方式上分为:选人创建和按分类创建。而选人创建对应的是传统意义上的讨论组,按分类创建对应的是传统意义上的群。

这就引发了我的一个思考,多人聊天是否有区分讨论组和群的需求呢?

要想清楚这个问题,我觉得首先得想清楚另个问题:讨论组和群的区别在哪里?

一、讨论组和群的区别在哪里?

1. 创建场景

讨论组的创建场景主要是基于熟人间的事件和关系驱动的,比如工作中遇到某个问题需要客户端、服务器、产品一起碰下的,会拉上相关的几个人,创建一个讨论组,快速沟通解决这件事;或者大学几个室友,一个宿舍才4个人,方便起见,拉上一个几个人的讨论组,平时用来同步些宿舍的事情,上课点名的情况之类的信息。

群聊的创建场景主要是基于兴趣、关系、利益驱动的,比如游戏交流群(基于兴趣)、同学同事群(基于关系)、考研考试群(基于交流能带来的实质利益驱动)。

由于创建场景的不同,会带来这两种形态的其他的属性不同:私密性、时效性、管理性

2. 私密性

私密性主要体现在这几个功能层面上:是否允许被陌生人搜索到并申请加群、分享出去的二维码是否时间有效性。

讨论组由于创建场景更基于熟人关系和事件驱动,导致其私密性更高,在此讨论组的用户形成的社交网络效应更强。所以可以看到,QQ之前的讨论组是没有ID的,是无法被搜索到的,且讨论组的二维码分享出去后是有七天有效期的。

群的创建场景由于本身更多是奔着更泛的交流的目的而产生的,其对私密性的态度更开放,群默认是可以被陌生人根据群号搜索到,并可以申请加入,其分享出去的二维码也无时效性,是永久有效的。

3. 时效性

时效性的意思是,这个多人聊天的使用时效。

讨论组由于其创建场景的很大一部分是基于事件的,而事件通常是有时效性的,比如,今天线上的登录出了bug,所以拉了个相关的开发测试产品同学的讨论组,那么这个问题解决了后,这个讨论组基本就成为了一个死掉的讨论组。

而群的创建场景使其时效性不受太多限制,大家不会突然同时对某个兴趣不感兴趣了而导致这个群死掉,当然群也有可能会变成沉默的群,但是这就属于社群活跃的范畴了,这里就不多做讨论。

时效性其实在功能层面上的区别不大,讨论组和群没有哪个功能会因为时效性的问题而设置的不一样,但是我们依旧要意识到这是两者的其中一种不同。

4. 管理性

管理性主要体现在这几个功能层面上:是否需要管理员、群主权利的范围(一般包括设置加群方式,设置查找方式,踢人,禁言,添加管理员,解散群)

讨论组由于其创建场景,导致其内部成员氛围会更趋向于扁平,大家的交流会更平等,而由于基本都是熟人,也比较少会出现需要被禁言的情景。

群的管理由于加群的人数更多,且陌生人占比居多,在没有熟人压力的情况下,大家的行为处事方式更加洒脱不可控,又加上具有公开性,需要随时处理陌生人加群的请求。

相比下来,群对于管理员和群主权利的丰富度的需求是高于讨论组的。

二、有没有必要让用户记住讨论组和群是两个概念?

上面思考了下讨论组和群的区别,那么现在应该问问自己,对于用户来说,他们在意这个多人会话是叫讨论组还是群吗?

我认为是不在意的。

对于用户来说,不论这个多人会话是叫讨论组还是群,他们的目的都是为了创建一个可以多个人同时聊天的空间。至于这个空间叫什么,重要吗?就像用户说,我需要一个能把这根绳子弄断的东西,用户在意你的不是你给他的工具叫小剪刀还是叫大剪刀还是叫菜刀,他在意的是这个工具能不能满足他弄断绳子的需求。当然如果你发现用户要弄断的是很细的绳,你能做到优先推荐他使用小剪刀的话是最好的。

那么在创建多人会话的时候,如果让用户使用到最合适的“刀”呢?

我认为是给用户提供有明确目的导向的多种创建群的方式即可,当用户创建群的时候明确知道需要拉哪几个用户进群的时候,可以选择选人创建群。当用户对群内的用户暂时没有明确的目的性时,但对群所想围绕的主题很确定的时候,可以选择按分类创建群。

而对于上面其他的私密性、时效性、管理性影响到的功能层面,完全可以通过依据创建方式的不同给予不同的默认值。例如:选人创建的群由于私密性更高,默认不允许被搜索。

三、总结

思考完上面两个问题后,我认为是没必要特地将创建好的多人会话特地区分成两种概念的,区分后反而会增加用户的认知成本,但可以依据实际情况提供多种创建方式。

如果APP内产生多人聊天的场景几乎只有基于事件和关系驱动的,那么我想只需要支持拉人创建的方式足以。如果APP内产生多人聊天的场景两者都有,最好提供两种创建方式。如果APP内产生多人聊天的场景几乎都是基于兴趣、关系、利益的,那么提供按分类创建即可。

 

本文由 @张㛃 授权发布于运营喵。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议

本文为@运营喵原创,运营喵专栏作者。

(0)
运营喵的头像运营喵官方
上一篇 2018-10-07 09:10
下一篇 2018-10-07 09:15

发表回复

登录后才能评论
公众号
公众号
返回顶部
运营喵VIP会员,畅学全部课程,点击查看 >