微信号:yurii-says

介绍:我是这么以为的,当然你也可以那么以为

再谈小程序和微信

2017-01-12 08:18 余晟


2013年摄于德国。



元旦之前我写了篇《换个角度看微信小程序》,强调对微信小程序来说,重要的不是功能的强大,而是对场景的深度适配,之后确实收到不少肯定的留言。现在微信小程序已经正式发布,已经上线的微信小程序也不可胜数。不过考虑到数据反馈,以及微信官方今天推荐的小程序全都是线下的情况,我之前的判断是对的。现在,我结合这几天和朋友们的讨论,把这个话题谈得再深入一点。

我们到底需要什么样的小程序(应用)?在谈具体功能之前,我们不妨借用一个二维坐标系,来给所有的程序做个分类。坐标系如下图,纵向是应用的使用频度,横向是应用的功能完备程度(或者技术成本)。


目前应用开发者最关注的无疑是第1象限:功能要足够复杂足够完备,既然要做到功能的复杂和完备,投入的成本自然足够高,那么一定要找使用频率足够高的场合,即便本来频率不够高,也要努力去拉高。

对第2象限而言,使用频率足够高,自然会吸引了不少关注,又因为功能简单,所以通常的选择就是用HTML5之类的技术来实现。

第3象限,因为使用频率低,功能又很简单,往往会被大家有意放弃或者忽略。

第4象限就比较微妙了。它需要完备的功能——可能是账号、支付、风控等等,专门为它开发应用的代价自然很高。然而不幸的是,它的使用频率又足够低,看起来收益并不能抵消成本。在传统的IT世界里,这个问题确实没有好的解决办法。

但是第4象限的各个应用,它们的场景可能千变万化,需要的能力却不可能千变万化,无非集中在账号、支付、通知等少数方面,以及还需要有足够的稳定性、安全性、负载能力,如果有功能完备的平台把这些现成的能力输出到第4象限,让普通人可以用很低的成本来组装出需要的应用,整个局面就会大为改观。

仔细观察微信官方第一批推荐的小程序,大部分都是落在第4象限:旅行、唱K、医院挂号、加油付费、违章处理等等,发生频率不高,然而你让旅行社、KTV、医院、加油站、交警队去做个功能完备的App,难度高而且不划算,但是如果有App,效率显然会大大提升。所以我们不难猜测,微信希望出现的,并不是少数功能强大、打遍天下的小程序,而是以自己的能力去覆盖各种使用频率高但开发成本高(“不划算”)的场景,至于覆盖它的到底是哪个小程序,这不重要。

写到这里我还想扯远一点。我觉得微信固然是热门话题,但很多讨论也只是热闹而已,真正意义其实不大。

  • 如果我不提醒,你还记得微信5.0推出了“街景”功能吗?那时候为这个功能鼓与呼,预言这是重大变化的文章也大量涌现,结果呢?

  • 如果我不提醒,你还记得是微信5.4强化了搜索功能吗?那时候很多人大呼“微信要在移动互联网上取代百度了”,结果呢?

  • 如果我不提醒,你还记得是微信折叠订阅号、推出服务号的更改吗?同样很多人大呼“订阅号要大打折扣,服务号要大行其道了”,结果呢?

历史已经反复证明,每当微信推出一项新功能的时候,总会受到特别多的关注,出来特别多的分析和预言。但这些变化本身或许并不能承载那么重大的意义,只是微信在某个方向上的尝试。只是随着时间的流逝,成功的尝试被记住被强化——哪怕是公众号成为占统治地位的内容平台这种意外的成功,不那么成功的尝试被淡忘被弱化——比如服务号就没有做起来嘛。当然,最后剩下的是“一路成功”的神话。

另一方面,喧嚣之下,微信真正在努力做的一些事情,反而没有什么人注意,虽然有那么多人号称在研究微信的产品。

做一个社交系统,很多人都会觉得用户有ID这事是天经地义的。但是,有多少人知道自己的“微信ID”?就我的观察,一大半的人都不知道自己的微信ID,甚至意识不到自己有个“微信ID”。大家的微信名称只是昵称——通常来说设计系统的人不喜欢用昵称,因为它重复率很高而且容易变化。

在我记忆里,有一段时间是会明显强化“微信ID”的,后来则慢慢弱化了这个概念,也并没有给用户造成可感知的不便。那么有人想过为什么要这么做吗?有人留意过微信是怎么做的吗?我可以提示一个小细节:微信名片是不能“接力”传播的,只能在一度熟人之间传播,这是为什么呢?

 
余晟以为 更多文章 数字时代如何保护个人隐私 从软件设计角度看O2O商机 工作那么枯燥,如何摆脱单循环模式 换个角度看微信小程序 努力,让这个世界更美好一点
猜您喜欢 Python Docker,IT技术变革的导火线! 当无人汽车遇上横穿马路的动物 集成电路设计的流程和分工 如何从HR的角度来面试技术工程师?