Posted on

我对于微信小程序的看法

微信小程序是什么东西?

自从 1 月 9 号 0 点微信小程序正式上线后,“小程序”便成为风口上的猪,从百度指数我们就可以看到它在泛互联网圈的热度如大火般撩原。

我们看回微信官方对小程序的定义:小程序是一种新的开放能力,开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播,同时具有出色的使用体验。

要点在:

  • 开放能力
  • 快速
  • 微信内
  • 使用体验

关于小程序是否为“升级版的 HTML5 ”,对普通用户来说,可以这么理解未尝不可,抛开小程序内在的技术核心,用户体验到的是一个观感上运行得更快的类 App(利益于微信封装好的原生组件,同时第一波的小程序绝大部分使用了跟原生 App 类似的界面,或者使用了 WeUI 设计)

我为什么看好微信小程序

回到前面提及的要点:开放能力、微信内、快速、使用体验,关于小程序的利与弊各方都写得很多剖析的文章,在往前展望前,我们可以先往回看历史的路径。

作为前驱者,百度在 2013 年的百度世界大会上就提出了“轻应用”,之后 QQ 浏览器、UC 浏览器和 360 浏览器也推出了类似的轻应用平台。

LAPP (Light App) 即轻应用是一种无需下载、即搜即用的全功能 App,既有媲美甚至超越native app的用户体验,又具备webapp的可被检索与智能分发的特性,将有效解决优质应用和服务与移动用户需求对接的问题。 – 来自百度百科关于轻应用介绍

特别是号称有过亿用户的 UC 浏览器也无法推进这个形态的产品概念,无论是我们把它叫小程序、应用号还是轻应用,核心理念均是 App + LightApp,借助某个超级 App 的能力,实现给用户的“所见即所得”“所得即可用”,甚至到了张小龙的“即用即走”的状态,同时对于开发者来说一定是要降低开发成本。

微信小程序就是更换了一个 Runtime 的技术方案,我们看回 React Native 、Weex,这些在技术层面都更为成熟,但微信的小程序和之前的“轻应用”、通用技术解决方案又有很大程度上的不同。

解决了入口问题

以往的轻应用,得依赖于特定的“浏览器”,浏览器内的 App Store、搜索、或者通过插件的形式,而微信作为国民级的应用,在盘活“二维码”这种旧时代的互联网表现媒介的同时,在很大程度上也成为了“二维码”的代名词。目前互联网的实质是“内容+服务”,无论是直播、媒体、视频、还是一篇教你做宫爆鸡丁的下厨房的文章,都是内容形态,公众号已成为“内容”存在的暗黑森林,做为平台级现象,公众号已验证了微信力量,而微信希望二维码能连接线上线下的服务。

所以说,微信小程序不是技术产品,而一个“场景化”的解决方案。

什么是场景化?就是满足了用户预期的产品需求,例如在公车站等车时,扫码查看“车来了”小程序,即时了解公交车到了哪些站点。

又例如使用手机的场景已经是日常生活的常态。

微信的市占率+行之有效的线上/下入口(二维码) = 降低绝大部分人的获取成本

最大程度上保证了体验

为什么 Android 机器给很多人的感觉是使用得越久,就变得越卡,事实上也如此,回到官方要点,“开放能力”、“微信内”,这两点保证了在大部分设备中访问小程序的体验都类似,至少不会偏差太多。

这一点保证了小程序的使用“口碑”。

用户终于通过线下二维码,或者某个小程序商店的推荐,再或者某篇文章的介绍,访问了你的小程序(注意不是“添加”,也不是“关注”),得益于微信已预加载了小程序的框架,用户可以更快速得开始使用。

张小龙

很大程度上,张小龙的“创业故事”都在为微信所有产品背书,从 Foxmail 到 QQ 邮箱,再到接管了大部分网民日常生活的超级 App,从微信社交、朋友圈、再到微信公众号,张小龙完全经历了 Web 1.0 到 Web 2.0,再到 Weixin Web World。

开发者、厂商的关注和投入,才是小程序得以发展的关键,也许接下来开发岗位很快就会细分出一个“微信全栈开发者”。

要不要做小程序?

在考虑要不要做小程序,也许我们可以想想哪些场景不应该去考虑小程序,考虑到目前的使用场景及限制。

  • 内容产品
  • 平台型产品
  • 消息流通型产品

结论

我说的都是错的。

发表评论