从强提醒说起——社交场景下的万有“隐力”

2018年的最后一天,微信推出了上线以来的第7个大版本:微信v7.0。在微信v7.0里,微信推出了三个大功能:即刻视频,好看和强提醒。分别代表了社交场景下的3个热点:流媒体、Timeline、即时通讯。作为一个即时通讯行业的从业者,看到“强提醒”这样的功能在微信上亮相,想和大家聊聊这背后的碰撞和演变。

打开新版微信,在你关心的联系人会话页面点击右上角,除了过去的置顶聊天和消息免打扰,新增了一个强提醒开关。打开开关,微信会将对方3小时内发送的第一条消息全屏提醒,并伴随着震动。无论你是打开了微信app。直到你点击“我知道了”。这样的设计,让人几乎无法错过这条消息的内容。

身边的许多朋友在第一时间体验了微信之后跟我讨论,说这样的交互形式,和之前微信尽量避免打扰的设计思路不同,“让我想起了被QQ‘窗口抖动’支配的恐惧。”有些朋友这样说。

从我自己的理解角度,社交产品的设计思路,往往是在“安静”,“即时”,“丰富”三元素之间平衡的过程。稍不注意,则会顾此失彼:关注即时和丰富而忽视“安静“的应用,往往会遇到打扰用户导致app卸载数据上升的问题。微信自诞生以来,每个版本的设计理念,的确给人“Less is more”的感觉。宁可牺牲信息的丰富性,也绝不增加用户的打扰负担。

社交产品三元素

但,微信强提醒和QQ抖屏,除了在交互上给人的强烈感外,几乎完全不一样。

“隐力”作用二三事

最早的QQ屏幕抖动,还是十多年前PC时代的桌面QQ。许多人会习惯挂着QQ,同时浏览网页、玩小游戏。当你发出的消息对方迟迟没有回复时,往往是因为对方没有注意右下角的闪烁。发送一条屏幕抖动,你的会话框会显示到最前,同时声音和屏幕开始抖动,强迫对方看到自己的消息。

所以在功能逻辑上,微信强提醒是主动设置强提醒,而QQ抖屏则是被动接受对方的强提醒。这背后,就不得不提人与人之间的社交关系了。

人是社会化的群居生物,俗话说“有人的地方就有江湖“,在人与人的社交行为当中,往往暗含着各种各样的”隐力“,它看不见摸不着,却无形中影响着人的社交行为:有的人隐力强大,有的人则相反。这就造成了在我们的社交行为中,除了有对等的社交关系外,往往还有不对等的社交关系。而社交应用,作为社交关系的互联网载体,也将这两种关系延申出来。

“隐力”顾名思义,是指隐藏在社交关系中的作用力。在不对等的社交关系中,强势方对弱势方的“隐力”更强,表现出的主导性会更明显。更多的会使用“抖屏”这样的强制提醒功能,确保对方接受自己的信息。

仔细回忆一下,是不是经常在社交网络上看到“客户爸爸”、“给大佬递茶”这样的表情包,这些本质上也是“隐力“不对等在社交应用上的体现。

那么问题来了,与现在很多人用QQ办公不同,早期的QQ更多服务于陌生网友、朋友同学这些对等社交关系下的IM场景,窗口抖动这么带有强制色彩,并体现了发送方“隐力”强于接收方特点的功能,是不是会和整体产品调性有出入呢?有些用户不想被动接收窗口抖动,会不会造成打扰?

其实许多人不知道,窗口抖动的接收是可以关闭的,以TIM(办公版QQ)桌面端为例,点开设置界面,就有“允许接收窗口抖动”的选项,点击取消后,就不会收到窗口抖动了。

窗口抖动是IM应用内强制提醒的一种尝试。显然对于它可能带来的弊端,开发设计团队也提供了Plan B,在十多年前那个强调信息丰富投递即时的年代,这样做也足够避免用户流失了。

与窗口抖动同时,还有另一个IM功能出现,叫做“已读回执”,已读回执诞生的背景,是早期IM消息投递到达率不高,为了确保消息到达,通过已读回执的形式,确保发送方知道接收方是否收到并打开了这条消息。随着IM技术愈发成熟,时至今日接入网易云信这样的IM云服务厂商,已经无需担心丢消息的现象,但这一功能依旧保存了下来。因为这一功能在办公场景下有了新的应用场景。并且衍生出了“群聊已读回执”

说起办公场景,就不得不说到“钉钉”这款产品。江湖传闻说,群已读回执、打卡、DING一下是钉钉用户最害怕的三个功能,作为办公IM应用,DING一下这个功能被设计的非常重:DING一下可以选择应用内、短信、电话的形式强制通知;接收方无需安装app,甚至无需开启移动数据就能接收;接收方接到电话,可以直接语音回复。

DING一下的应用场景,从催办流程,紧急找人到重要信息的传达,都体现了“隐力”作用:当领导传递重要指示时,DING一下,无论对方在做什么都能确保收到消息。而DING一下场景中,发送方的“隐力”显然更为强大,在不对等社交关系中,占据主动一方。这一点和微信强提醒恰恰相反。

随着移动互联网的普及,@TA功能也逐渐深入到社交场景当中。最开始是Twitter、FB、微博等Timeline产品,后来逐渐的BBS论坛、即时通讯app也都实现了这一功能。在QQ、微信等应用的群聊场景里,可以指定@对象为某个用户或某几个用户,对于群主还可以@全员,在微信里@全员的功能和发布群公告功能合二为一。

比起上面几种形式,@TA的交互更柔和:除了在联系人列表页的红色字体外,和普通的消息提醒逻辑并没有太大区别。这是因为@TA的定位是避免重要信息丢失在海量消息中:移动互联网时代的IM社交,每个人都有大量的群消息,许多群甚至做了免打扰处理,而@人功能可以确保重要信息能正常提醒,而又非完全强制的形式。这也体现了当前互联网社交生态圈里,“安静不打扰”的重要程度在不断上升。

设计思路的转变

以强制性强弱和设置方在社交关系中的“隐力”强弱,我们建立二维坐标系。可以看到,上面提到的四个IM强制提醒功能各不相同:DING一下和窗口抖动,显然设置方更为强势一些,强制性也非常强,@TA作为同类产品,强制性弱,发送方和接收方的“隐力”关系相对平等,而微信强提醒则完全处于另一个象限:设置方处于“隐力”关系弱势,强制性也非常强。

所幸的是,即便强提醒的产品设计给人一种“自虐”功能的印象,对于提醒尺度上,微信可以说是小心翼翼:设置的强提醒仅对设置后的第一条消息生效;3个小时后没有收到消息,强提醒自动取消,从功能上,并不会给设置方带来消息提醒打扰。

最后我整理了一下几种功能的详细对比。目前大部分app的即时通讯服务都会选择由网易云信等IM云服务商提供技术能力,所以在技术实现上,可以说没有太多后顾之忧。如果你的app也想在社交场景上玩些新套路,欢迎我们一起交流沟通。虽然我们很难改变世界,但世界的确因我们每个人的努力而改变!



想要阅读更多技术干货、行业洞察,欢迎关注网易云信博客

了解网易云信,来自网易核心架构的通信与视频云服务。

网易云信(NeteaseYunXin)是集网易18年IM以及音视频技术打造的PaaS服务产品,来自网易核心技术架构的通信与视频云服务,稳定易用且功能全面,致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API,即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

原文地址:https://www.cnblogs.com/wangyiyunxin/p/11158264.html

时间: 2024-10-10 20:08:56

从强提醒说起——社交场景下的万有“隐力”的相关文章

混合云场景下容器技术在新能源功率预测产品中的最佳实践

能源互联网是物联网和"互联网+"在能源行业深度融合的产物,是中国制造2025的重要组成部分,我们现在还处于能源互联网的早期阶段.绝大部分能源行业的应用都部署在私有局域网内,并且网络结构异常复杂,这是阻碍互联网技术在能源行业落地的最大挑战. 6月28日,金风科技数据平台架构师张利出席了Rancher Labs举办的Container Day 2018容器技术大会,并做了题为<混合云场景下容器技术在新能源功率预测产品中的最佳实践>的演讲. 金风科技是中国成立最早.自主研发能力最

Redis5.0:这些场景下使用,高效还降低成本!

华为云分布式缓存Redis,能应对很多典型的场景,比如很多大型电商网站.视频直播和游戏应用等,存在大规模数据访问,对数据查询效率要求高,且数据结构简单,不涉及太多关联查询.这种场景使用Redis,在速度上对传统磁盘数据库有很大优势,能够有效减少数据库磁盘IO,提高数据查询效率,减轻管理维护工作量,降低数据库存储成本. Redis对传统磁盘数据库是一个重要的补充,成为了互联网应用,尤其是支持高并发访问的互联网应用必不可少的基础服务之一.以下举几个典型样例:(电商网站)秒杀抢购电商网站的商品类目.推

分布式场景下Kafka消息顺序性的思考

如果业务中,对于kafka发送消息异步消费的场景,在业务上需要实现在消费时实现顺序消费, 利用kafka在partition内消息有序的特点,消息消费时的有序性. 1.在发送消息时,通过指定partition hash 2.consumer 消费消息时,需要使用亲缘性线程池进行消费,才能实现消息的基本有序.否则即使通过发送时指定partition,在消费端由于线程池的异步消费,消息之间的处理都是并发进行的,消息就会被打乱. 上面的方式基本可以实现消息的消费顺序性,除了在极端场景下,比如: 1.进

还没弄懂分布式场景下数据一致性问题?一文教你轻松解决!

文章纲要 此次分享的缘由 目前分布式事务问题是怎么解决的 行业中有什么解决方案 这些解决方案分别有什么优缺点 别人是怎么做的 我们可以怎么来做 此次分享的缘由 支付重构 考虑支付重构的时候,自然想到原本属于一个本地事务中的处理,现在要跨应用了要怎么处理.拿充值订单举个栗子吧,假设:原本订单模块和账户模块是放在一起的,现在需要做服务拆分,拆分成订单服务,账户服务.原本收到充值回调后,可以将修改订单状态和增加金币放在一个mysql事务中完成的,但是呢,因为服务拆分了,就面临着需要协调2个服务才能完成

百度技术沙龙 - 大数据场景下主题检索应用

第48期百度技术沙龙上的<大数据场景下主题检索应用>讲座介绍了很多训练大规模主题模型的技术细节.讲座回来后,我粗略整理了下讲座上涉及的主题模型和训练大规模模型相关的资料和文献. 1. 主题模型的发展历史 a. 布尔模型 Boolean model b. 向量空间模型 VSM (Vector space model) c. 潜在语义索引 LSI (Latent semantics index) - 首先作为一种降维技术, 对doc-word矩阵进行SVD分解 d. 概率潜在语义分析pLSA e.

缓存在高并发场景下的常见问题

缓存一致性问题 当数据时效性要求很高时,需要保证缓存中的数据与数据库中的保持一致,而且需要保证缓存节点和副本中的数据也保持一致,不能出现差异现象.这就比较依赖缓存的过期和更新策略.一般会在数据发生更改的时,主动更新缓存中的数据或者移除对应的缓存. 缓存并发问题 缓存过期后将尝试从后端数据库获取数据,这是一个看似合理的流程.但是,在高并发场景下,有可能多个请求并发的去从数据库获取数据,对后端数据库造成极大的冲击,甚至导致 “雪崩”现象.此外,当某个缓存key在被更新时,同时也可能被大量请求在获取,

多线程场景下延迟初始化的策略

1.什么是延迟初始化 延迟初始化(lazy initialization,即懒加载)是延迟到需要域的值时才将它初始化的行为.如果永远不需要这个值,这个域就永远不会被初始化.这种方法既静态域,也适用于实例域. 最好建议“除非绝对必要,否则就不要这么做”. 2.延迟初始化线程安全的一个策略:同步 延迟初始化的一个好处,是当域只在类的实例部分被访问,并且初始化这个域的开销很高,那就可能值得进行延迟初始化. 但是在大多数情况下,正常的初始化要优先于延迟初始化.因为在多线程的场景下,采用某种形式的同步是很

【Vue】浅谈Vue不同场景下组件间的数据交流

浅谈Vue不同场景下组件间的数据“交流” Vue的官方文档可以说是很详细了.在我看来,它和react等其他框架文档一样,讲述的方式的更多的是“方法论”,而不是“场景论”,这也就导致了:我们在阅读完文档许多遍后,写起代码还是不免感到有许多困惑,因为我们不知道其中一些知识点的运用场景.这就是我写这篇文章的目的,探讨不同场景下组件间的数据“交流”的Vue实现 父子组件间的数据交流 父子组件间的数据交流可分为两种: 1.父组件传递数据给子组件 2.子组件传递数据给父组件 父组件传递数据给子组件——pro

互联网业务场景下消息队列架构

消息队列作为一种基础的抽象数据结构,被广泛应用在各类编程与系统设计中. 同步VS异步 通信的一个基本问题是:发出去的消息什么时候需要被接收到?这个问题引出了两个基础概念:"同步通信"和"异步通信".根据理论抽象模型,同步通信和异步通信最本质的差别来自于时钟机制的有无.同步通信的双方需要一个校准的时钟,异步通信的双方不需要时钟.现实的情况是,没有完全校准的时钟,所以没有绝对的同步通信.同样,绝对异步通信意味着无法控制一个发出去的消息被接收到的时间点,无期限的等待一个消