冷静下来重新思考小程序:首发选手们表现如何?
小程序
作者: 玉珠贤
2017-02-12 12:35
[ 久闻导读 ] 我花了不少时间阅读小程序的开发设计文档,以及使用和体验了第一批问世的小程序,希望从中窥见小龙哥的一些观点,以及看看小程序未来是不是能够不仅仅止步于腾讯内部。

各位元宵节快乐。感叹下,2017年的小目标还没有开始实现,就已经默默过去了1/6。

春节期间,面对面红包在我的"鹅厂"朋友圈中火得一塌糊涂,但是似乎它对我家乡人民的影响力远远小于16年的摇一摇红包。尽管有小龙哥亲自上阵演示,然而面对面红包在这个春节的热闹还是止步于鹅厂内部。

在繁花似锦的微信派产品中,我对小程序尤为感兴趣。到今天,小程序已经正式开闸差不多1个月左右,或许正好是可以冷静下来再重新去思考小程序的最好时间。

我花了不少时间阅读小程序的开发设计文档,以及使用和体验了第一批问世的小程序,希望从中窥见小龙哥的一些观点,以及看看小程序未来是不是能够不仅仅止步于腾讯内部。

相信每个优秀的产品经理的梦想都是创造一个产品帝国,在自己的帝国内能够有完整的自闭环和生态。于是小龙哥创建了微信帝国,其主要的价值观是"连接一切"。

他还说很多程序员包括自己的梦想就是:

"除了自己去写一个程序,再去写一个能运行程序的程序"。

所以仔细分析和观察小程序,发现这就是现阶段一个凝聚了小龙哥"运行程序的程序"和微信"连接一切"梦想的集合体。但是从已经被开发出来的小程序来说,大部分的产品经理和开发者显然并没有参透小龙哥的苦心。

于是,笔者从1月9号首发上线的小程序中随机挑选了50+款小程序去认真进行了体验,并试图去思考它们在微信小程序体系下新增的用户价值是怎样的。然后,就有了你现在正在阅读的这篇文章。

本文大约会结合我的思考分以下3个方面来展开--

一、阐述微信小程序平台的开发、产品优势;

二、剖析首发阵容的小程序是否很好地利用到了这种优势来实现"能运行程序的程序"和"连接一切"的野心;

三、挑选出几个典型小程序,来思考是否有更好的产品表现形式,以及接下来产品经理可以怎么玩。

此外,本文也会基于开发者和产品经理的角度来谈一些我的观点。下面我逐次来说。

冷静下来重新思考小程序:首发选手们表现如何?

我在1月9日内测前就在滴滴内部得到了公司内部小程序的体验机会,当时的第一感觉是:这不就是一个加载速度快、体验更加接近原生的H5嘛?大家的期望未免也有点儿太高了。

但,我仔细研究下来过后,才发现远不如自己想象的简单。

小程序无论是从获取微信接口的能力还是体验上,比嵌入微信的h5网页都超出一个level。

1. 开发层

小程序开发框架的目标是通过尽可能简单、高效的方式让开发者可以在微信中开发具有原生 APP 体验的服务。这是小程序框架介绍中的第一句话,其实不止是开发框架,整个小程序的思路都是围绕它的。重点是,微信像是一个操作系统,结构化地提供了很多原生解决方案。

小程序框架上具有的四个特性为:响应的数据绑定、页面管理、基础组件、丰富的 API。

前两个属于较为底层的技术实现框架,不充分展开,简而言之就是通过微信自有的框架,让小程序天生具有页面切换无缝,数据响应速度更快的能力。

基础组件也只是一种技术实现形式,微信包装出来的组件在自有的框架下相信是兼容得最好的,并且大大的节省了开发者人力码代码的时间,至于有技术大牛一定要自己实现,就先收下我的膝盖不多说了。

丰富的API,在效果上可以说完胜微信公众号的接口。我们以"获取用户地理位置"这一需求为例在二者间进行一个简单的对比:

公众号

用户同意上报地理位置后,每次进入公众号会话时,都会在进入时上报地理位置,但离开会话后,接口不可继续被调用。

小程序

自动获取当前的地理位置、速度。当用户离开小程序后,原则上此接口无法调用;但当用户点击了"显示在聊天顶部"时,则此接口在用户离开后可继续调用。

可见在小程序下,微信通过某种方式让能力升级了。从单纯的地理位置,到"速度"这样的移动情况特征,以及不在当前页面时也能持续的获取。可以想象的是,小程序的应用场景将会得到极大的扩充。举个最简单的例子:

在微信共享实时位置的时候任何一方都不能离开会话窗口,否则将会退出位置共享(见下图),但是假如有一个共享实时位置的小程序被置顶"显示在聊天顶部",你就可以同时跟其他的朋友一边聊天一边共享实时位置了。

冷静下来重新思考小程序:首发选手们表现如何?

在设计规范上,微信使用了简洁、贴近于原生的样式,并且在加载、导航、反馈,甚至按钮的排布上都有统一的规范,所以市面可见的小程序,在交互形态上都能够保证最为基本的流畅和简洁。例如:典型的程序进入加载等待体验优于鱼龙混杂的h5体验。

冷静下来重新思考小程序:首发选手们表现如何?

基于以上的开发框架和设计原则,微信小程序与其说是小程序,更不如说是一个能够快速孵化、创造无数小程序的生态系统。也就是小龙哥所说的"能够运行程序的程序"。

冷静下来重新思考小程序:首发选手们表现如何?

张小龙在微信公开课上描述了这样一个场景:

在移动互联网之后会是什么样的一种形态?有可能是一种类似于眼镜这样的设备,它会成为我们主流的一个设备。当眼镜变得非常非常的智能化的时候,可能整个PC或者电脑的系统会藏在一个眼镜里面。

我更加希望的是眼镜里面不要再给我一些安装应用程序这样的过程,因为那个是很不自然、很不方便的,我更加希望我的眼镜看到哪里,相关的应用程序就到哪里。

在现在看来这是一个相当理想化的生活场景,依赖于硬件之间的相互打通,但是小程序这种精妙的设计将这个场景脱离硬件的升级,准确的还原出来了。

我们把手机的摄像头扫描的二维码的动作看成眼镜视线所及的过程,小程序无需下载快速的加载,即消灭了应用安装的过程,相当于"眼镜看到哪里,相关的应用程序就到哪里"。接下来要做的事情便是大量的开发者设计大量的小程序将它们的二维码印在所有物品上。小龙哥所描述的场景就鲜活的呈现了。

真正实现了即用即走,所见即所得,连接一切,这便是小龙哥脑海中的下一个互联网形态,他寄希望于"小程序"可以实现这些。

下面我们再来看看最先一批小程序的开发者们是怎么来对小龙哥想象中的这个世界进行响应的。

笔者先说自己观察过后的结论:大部分的小程序开发者是不合格的,缺乏应用场景的生搬硬套,仅仅把小程序当成了升级版的h5,生产出来的产品简直是食之无味、弃之可惜,甚至导致了用户在使用小程序的同时卸载自家产品的危机。

于是,在小程序出来后,不少产品都面临着"用户把原有APP卸载了"的尴尬。

比如,在小程序上线的当天晚上,我们的一个早期用户群众就有用户展开了议论:

冷静下来重新思考小程序:首发选手们表现如何?

1. 为什么首发阵容惨遭滑铁卢?

我在试用的50+个小程序中,挑选出了几个好坏不一的小程序为例,试着说明下为什么当前的小程序大多数都是不合格的。

根据笔者的观察,这些表现不佳的小程序基本可以分为两类,一类是纯线上服务,另一类是完全复制原生App的小程序。下面我们结合实际例子来分析一下为什么这两类的小程序注定难以出彩。

在线查询类、阅读类、记录类等纯线上服务

我觉得,这些实际上都不是特别适合做成小程序。从小程序开发规范中也可以发现,游戏、直播、虚拟物品购买等功能均未开放,由此可见端倪:至少第一个阶段的"小程序"天然不是为了支持纯线上功能的。

我们以一个叫做汇率e的小程序来举例吧。由于基于小龙哥脑洞中的场景,微信没有给小程序入口,在搜索获取上也做得非常的严格。所以获取它需要由发现-小程序入口,输入"汇率e"这个不是很大众的名字精准查找到。

此外,如果在微信中纯线上进入汇率e小程序,用户路径是很长的--用户需要先搜索找到小程序,再打开,再进入操作使用。但是如果在手机任何一个浏览器(百度首页)中输入"汇率"二字,均会自动会出现汇率查询功能异形卡片。

两者PK,在一年可能只用到一次的旅行前触发查询汇率的场景下,百度首页完胜小程序,轻量且易于触达。

虽然在小程序在界面上比搜索异形卡片用户友好(见下图),但是汇率e这个小程序给用户带来的新增价值几乎为零,同时有非常高的使用门槛,所以这个小程序注定是一个鸡肋。

冷静下来重新思考小程序:首发选手们表现如何?

但同样是"查询"类的小程序,类似飞常准查航班、滴滴公交查询等小程序虽然在线上可能很难有出路,但这一类的小程序却很容易结合线下场景。

举个例子,在韩国,大多数公交车站上方都有一个显示屏,实时显示下一班次的公交车什么时候到站。

相关文章

  • 验证码: 看不清?点击更换 看不清? 点击更换
  • 意见反馈
    意见反馈
    返回顶部