对一列微信小程序比赛作品的想法

一堆事情没做,又厚着脸皮来写好久没有写过的博客了。今年真是神奇,参加了个小程序比赛,莫名其妙地进了地区选拔赛,虽然成绩并不理想(自费旅游),但也算是领略学习优秀大学生风采了。趁着比赛完想不到要干啥,北京的天也没黑,就斗胆来评论一下前十好了。

我来参加这个比赛的时候,想法是觉得,既然是小程序比赛,选题总该是适合小程序的,才能代表小程序的先进方向。一些 PWA 甚至网页就已经足够实现功能、又没结合微信小程序特点的作品,我总觉得蛮尴尬的。可能并不是每个人都会这么去执着平台依赖这个国内不大关注的问题的吧。答辩的时候并没想到要提小程序与 PWA 区别的思考,结果还剩了几分钟时间,后来发现一整天没人提 PWA 相关,想想还是挺遗憾。

先进一下前情提要。这轮选拔赛的前十都是有奖金的,其中前二可以晋级进入全国决赛。这个名次是现场公布的,不知道最后会不会公示。下面就按名次说好了,我也是这几天才第一次接触到这些小程序;如果没有特别说明,可以直接在微信里搜到这些小程序。

1 > 参观清华

顾名思义,这是一个游客预约参观清华的小程序(哈?清华要预约?走南门不就好了?)。现场演示的三位清华队员闲下来的时候话题挺丰富,从奖金扣不扣税聊到游戏。答辩则讲了从问题出现到实施到新闻报道的过程,实际上整个是一个大系统,不止有面对个人的小程序,还有面对管理者的网页(答疑部分提到清华保卫处还想要个管理端的小程序??你们当响应式网页是吃干饭的?),以及入口的人脸识别闸机。

前端部分讲了说一个界面迭代了多少次什么的,听下来我发现评委挺吃这一套,之前还觉得自己拿出成品就可以了的,中间的故事没必要讲。感觉他们别的技术很先进的,什么人脸识别算法优化啦,GraphQL 啦(啥?小程序还能这么玩?),负载均衡啦(可能清华这个体量的确需要),Go 的后端啦,身份证号可逆不可逆加密同时存储啦(这个真的业界良心,不敢想不敢想),可能这就是清华吧。

但是你问我小程序给这个项目带来了什么价值,我觉得并不多,可能无非是可以节省一些短信通道费用(它们做了一个临时关闭参观的通知推送的功能),然后简化了账号体系。问题是它也没有做账号体系的必要啊,预约功能都需要身份证实名验证,进校还需要再刷一次身份证,那你用身份证号做账号体系不就好了。我粗略看了一下小程序首页,总觉得这前端的逻辑哪里不对劲,只能说中规中矩,而且报名的部分完全是网页就可以解决的,硬用小程序来解决,还只能用小程序,哎(Update: 刚发现有个小程序叫参观北大,人家点预约,拿走用户信息之后就进了 WebView,也就是说人家是支持个人网页端预约的)。还有一个导览的功能,就是一张简单的地图,加上(多次强调不经过校长办公室的)路线提示、景点介绍,其实很常规。

这个项目为什么在这个比赛里拿第一,我还是没搞懂。不过建议还是有的,现场有老师建议说热力图“可以做,不难做”,我倒觉得顺着这个方向发展下去,导览做细致一些,做成常驻前台的一个功能(这种功能也值得用小程序做),顺便采集一下用户位置,低成本热力图就有了,有戏。而且我也不是很懂为什么一定要在过闸的时候扫一次身份证,要是能直接二维码和人脸识别过闸多好啊。

2 > 听说无忧

这个是北大的研究生队伍,一上来先讲队伍两个人非常牛,不知道在评委心里有没有加分。做的这个英语打卡、跟读产品呢,说是解决了跟读之后没有人点评的痛点,也实现了一个商业变现的渠道。老师提问的时候也提到竞品的问题,他们回答得也蛮清晰,看起来他们还是挺熟悉这个市场的,毕竟之前也运营了那么多粉丝。可能是我眼红了吧,不过仔细一想又懂技术又懂英语和运营,还是很强的。

小程序为他们带来的价值可能是低的获客成本和维持黏性的成本吧,毕竟可能他们压根没想过网页也可以录音(不过纯粹只有网站,黏性是真的不行),而 App 又太重。他们的组织之前也应该是基于微信公众号和微信群来做的,继续停留在微信这个生态里,小程序可能的确是最好的选择。虽然听起来像是一个高起点的作品(没有白手起家的那种感觉),不过这个生态的一致性可能是他们拿到高分的原因之一吧。

突然想起来,当时他们在现场提供的电脑上演示,演示视频遇到了没有声音的突发情况,男主讲人救场救得挺辛苦的,感觉有点超出常规,不知道是不是被当作加分点了。

3 > 有通知

我心目中认为应该晋级的作品和队伍,然而并没有。光是现场答辩的效果就非常好。幻灯片风格统一,动效都是逐个逐个元素做的,换页的时候元素还有动效(现在我还是想不明白是拿什么做的,可能是我没有见识过的 Office 365 或者 Keynote 吧),非常流畅。讲得也非常流畅,内容也完整,产品前期调研拍的视频能找那么多学校的老师和同学真的好强。演示拿的 iPhone 投屏幕,演示用例跟比赛赛况的结合设计得很棒。现场表达出的对微信等互联网产品的设计理解也很深刻。不过不是很明白为啥要花好几张幻灯片讲队伍之前做过的小程序项目啥的,虽然讲得很快,但总觉得这种跟产品关系并不大的内容完全没必要展开。可能是真的对自己的队伍充满信心吧。

对产品的打磨算是非常细致了,顾名思义,是一个用来做群通知的小程序,其实这类小程序还挺多的。光是打开它的群分享的页面来看,UI 做得还是挺好的,功能也完整,从其它网络应用搬来的态度功能做得也很神奇,该有的已读啥的也都有。再深入的页面我也没细看,不过想必是好的吧,有需要的朋友完全可以用上这个小程序。

要提建议的话,首先他们没有用微信自带的导航栏,而是自己设计了一个顶栏,而且内容上似乎也跟微信自己的没什么差别,难道是纯粹为了高保真地实现 UI 设计稿吗?后面发现他们是在上面放了一个自定义的刷新按钮(我之前也有需要放按钮的需求,最后懒得做全屏适配,就做成两行的双顶栏了),刷新居然还不用微信自带的下拉刷新的吗?然后还有什么返回首页的按钮,估计是新版微信拿掉了导航栏的回首页按钮之后,强行给补回去的吧,可能会更符合用户预期?然后新手引导这块感觉还是有改进的空间,从首页进去,一种空空荡荡的感觉,写着“没有通知哎 快去新建一个吧”,点来点去,不登陆好像也没看到新建按钮,似乎期望着用户能主动去点登录一样。可能这就是他们说的“不打扰用户”体验的一个极端效果吧。然后突然才发现通知内容的 text 部分没做 selectable,真的感觉很不好(Update: 后面在测微享便签的时候发现可能是误伤,小程序的 Android 长按功能经常失灵,这也是为什么我不认为在小程序里放内容是个好主意的原因之一;但这个在测试的时候我马上试了自己的小程序是可以正常选中的)。

不过看这个需求最后实现成这个样子,我感觉还是挺纠结的。虽然小程序的模板消息推送格式并不好看,但作为唯一的推送方法,作为开发者,不得不用。另外小程序为了防止骚扰用户做了推送限制,使得开发者必须用“骗用户点击,捡小程序落下的 formID”的方法来保证推送成功率,也是一种无奈之举。有通知的设计效果还是非常优雅的,不过靠的是建立一套自己的内容体系,让用户多进来看通知、并对通知做归类,点击的过程自然会有 formID 了。现场他们也提到这个自建一套体系的问题了,不过看来真的是无奈之举吧。

顺便,自建内容体系最大的问题,就是需要做内容审核机制,虽然最近小程序也刚刚提供了相关的自动审查 API,但做了内容存储,总归是要有人工介入的成本的。这样的审核机制的维持要求,也往往是这类应用容易烂尾的原因之一。

其实国内出现的这种通知怪现象,根本原因还是微信聊天克制地不做阅读状态,使得基于微信聊天的通知体系变得很杂乱。收到请回复可能还是一种兼容性足够强的办法吧。在国外一些依靠标准邮件、日历协议的地方,根本没有这种问题。不管大家在哪家公司的平台上,通知靠邮件,“收到请回复”靠邮件里自带的 ics 邀请的接受操作,而一接受邀请,相关的信息就自动插入到个人的日历上了。包括什么找一个能开会的时间这种事情,成熟的做法是每个人都有一个公开日历,想开会直接找这几个人的日历做一个并集就知道该挑什么时间了。

而想去改善微信体系下的这种困境,可能真的只能靠小程序的能力了。但这类问题,解铃还须系铃人,相信微信官方来实现一些功能,效果会好得多。类似群收款,这个功能要是变成小程序,那很多功能还真是实现不了。这队伍还想跟微信团队交流某些能力要如何开放啥的呢,也不知道最终能不能交流上。不过,小程序早日实现多端兼容,电脑聊天的时候别哑火,兼容性才能达到“完整”的程度,我才会愿意用上这类小程序。

写了这么多,还是挺欣赏这支队伍的,不过可能是后会无期了。今天最开心的事情可能就是比赛完路过,无意被他们两个找了之后用他们的手机帮拍了他们的合照,嘻嘻。

4 > 蜜蜂图书共享平台

整个演示给人一种走错片场的感觉,本来应该去创新创业大赛的,包括什么五类群体的互利模式、已经发展了上百个自营点啥的,听起来似乎从创业的角度还是挺成功的。老师们倒是挺关心他们小程序之外的一些产品规则的设计,包括共享书架能放多少书、整层书架都打开了是不是能把所有书都拿走之类的问题。不是很懂为什么他们能在这个比赛拿到这么高名次的。

而具体到这个小程序上,感觉除了内置 input 扫图书条码的功能之外,别的都完全可以用网页实现,不是很懂小程序给他们带来了什么独特的价值。而今晚我打开这个小程序的时候,换了两个网络环境都提示“获取数据失败,请检查网络配置!”。对不起,我是真的没看懂。

5 > 在线借书平台

这个就更厉害了,比赛期间实现了一整套的借书和图书管理流程,并实现了跨图书馆查询余量的功能,还预留了馆员 Android 客户端和 Web 端等等,原因是认为目前高校的图书馆管理系统不够完善,没有联通。答疑的时候一位队员还用“破”、“废”形容了某些图书馆系统。也不想想很多高校都花的是纳税人的钱,这种系统的用户体验可是挺花钱的呢。说到跨图书馆的数据联通,我还特意看了一下这支队伍来自北京工业大学,拜托,您校图书馆可是在 BALIS 这个北京独有的馆际互借系统里的。你们说有做过调研,说现在图书馆数据不联动,我这个不怎么看书的人都知道 BALIS,当时老师好像也都没提到,只能说 BALIS 的宣传真的做得太惨了。

有位老师评价说 UI 做得很用心,我回头看了下,可能是用的 WeUI 标准界面比较多吧。之前发现他们居然有做所有控件的 :active 状态反馈,还以为真的是自己改进了 UI,后来发现都是 WeUI 做的,我这个徒手加完所有控件 :active 样式的前端可就放心了,至少前十(Update: 说大话了,还是前五吧)没有比我更强迫症的了。最后名次这么高,可能是系统工作量和完成度比较高吧。我依然不理解这个选题,您真的选这个题,就可以开公司接大项目了啊,何必局限于把网页就能做好的事情放在小程序里。

Update: 昨天写这段的时候忘了,他们工程化方面介绍得挺详细的,API 标准构建的 Swagger、自动测试的 Postman、错误捕获的 fundebug 啥的似乎都用上了,这么说来还是好强啊。

6 > 小世界步数旅行(搜不到)

因为这个小程序并没有公开版,所以有可能记错。比赛里 20 个被挑选的作品,有好几个是基于微信运动数据做的创新,基本上是期望于用小程序里的内容激励用户多运动。而这个小程序则是基于一个城市场景的概念,步数越多,能看到的城市画面就越多,还能收一些城市相关的虚拟纪念品。主要的鸡腿冰淇淋要给美工,看演示真的挺漂亮的。

现场评委提了说用户激励还不足够、缺少社交转发元素等等,不过我觉得这些都是小问题,队伍自己也说这小程序有点旅行青蛙的感觉,小清新的风格只要保持住,好好运营一下,发展潜力还是很大的。只是说,我突然在想,这个选题能坚持多久。

7 > 软微会议室预约

感觉重点和痛点真的不在小程序上,而是一个信息化改造项目。展示的时候就特别明显,说什么以前审批表一大叠、老师签名跟学生碰头很难、所以要做流程信息化改造,做 App 又太重,拜托你做一个网页系统不就好了,小程序除了节省短信费还有什么绝对优势吗。

可能有一个加分点吧,北京大学软件与微电子学院处在一个独立的校区,他们正在做基于腾讯微校的整体信息化改造,所以小程序 + 教育,尤其是加上微校的体系就很有趣了。他们也介绍了这个结合的方式,微校在微信卡包里有一张校园卡,点开之后有一个网页,显示绑定了校园卡账号的小程序码。朋友原来你解决的问题是微校入口太深吗?我突然无话可说了。

具体的前端因为没有权限,并看不到全部,当时没仔细看也没啥印象,不过听起来这种申请界面都需要迭代的样子。

8 > 微享便签

同样是选题很神奇,不就是笔记吗?我为什么要在手机上用小程序记笔记,而不是用专业的 Evernote 之类的跨平台软件呢?数据能导出来吗?

好吧,不这么苛刻了,其实你体验做得好的话可能还是会有人用的嘛,才不会管什么数据导出的问题。粗略看了一下前端,文字图片录音便签都有,不过他们作为第一个上台讲的,老师们也说缺少便签整理搜索功能啥的,我看 UI 也有种奇怪的拼凑感。只有微信分享功能的话,除了可以长文字分享不干扰以外,我为啥要用这个便签呢?而且自建内容平台同样的问题,内容审核啊,哎。

9 > 航读书

一位老师说,“听你们前面介绍说在这个时代下阅读有怎样怎样的问题和痛点还挺期待的,结果你们小程序只有一个阅读进度和读书笔记的功能”,这么说好像还真的有这种落差感。当然除了这两功能,推荐热门书籍、数据挖掘什么的发展自然也是有的。指导老师还特地强调的确是受(我屏蔽的)出版社委托做的项目。仔细一想,这东西一定要用小程序做吗?PWA 多好啊,只是没法(在国内)推送模板消息请(gan)你(jin)回(la)来(huo)看(yong)书(hu)而已。可能放在小程序里用户的确能想到它吧。

10 > 运动么

好些人说这位是一支队伍一个人 carry 全场的北大大佬。这个小程序是一个同校信息交换平台,主要就是拼团凑全场一起运动之类的,而且看起来运营了一段时间了,好像用户也挺多的样子了。但是,但是,我看演示幻灯片的时候为什么看到了好多次“高校社团活动平台”。后面的答疑我也没仔细听,但好像大家就这么过去了。您上线的小程序版本不是运动平台吗?社团“运动么”,我有点害怕北大了。

以及,真的一定需要小程序吗?跟小程序结合的点在哪里啊?主要我发现了一个 HTML5 版的列表页面了。

一点结语

吐槽了这么多,没想到一晚上就过去了,后面那十个作品我就懒得写了。我其实蛮纠结的点是,这比赛里作品跟小程序特性的结合并不是一个明确的评分点。可能用户对小程序的感知并不明显,你用什么技术他们也不管,当然是怎么方便怎么来,好用才是真的好。这是一个小程序应用开发赛,可能应该淡化与小程序没有直接关系的 Web 系统的关注度,此外真的可能要考虑一下小程序的创新因素吧。虽然好的角度真的挺难找的。

再次说明,以上只代表我个人意见,对事不对人。最后还是要感谢主办单位和各位组织老师和评委老师,第一届也不容易,的确也有很多好想法、好作品被激发了出来。我之前也没指望还能进到这个层级的比赛的,也算是蹭了饭、看到了更大的更有趣的世界。这半年的感受,多接触一些不同,要多想,内心才会丰富一些。以及,可能又要改行了吧,谁知道呢。

在点提交按钮之前重新过了一遍全文,嗯,我一定要狠狠地这么吐槽一次自己的作品。

“对一列微信小程序比赛作品的想法”的4个回复

  1. 在那个场合谈PWA的话,真的不是砸场子吗←_←现实情况是,“每个用户都有微信”这条假设是合理的,不会用浏览器的用户反而更多。小程序最有价值的一点是入口吧,这个年代不可能指望用户手动去浏览器地址栏里输入网址。编二维码自然可以,但用户看到二维码,第一反应还是用微信来扫。

    账号体系这一条其实很重要。“参观北大”每次操作(预约的增、删、改、查)都要通过手机短信发放验证码,体验恐怕并不好。用身份证号怎么做账号体系呢,让用户自己再设置一个密码吗,体验恐怕并不好。保卫处管理后台这边也是一样的道理,如果让用户在手机屏幕上输入强密码,体验恐怕并不好,延长cookies有效期则又会增加安全风险。

    小程序和 WebApp 的关系到底是怎样,其实我也没有想明白。不知博主是否愿意继续探讨。

    1. 的确正如您所说,小程序跟 PWA 相比用户学习成本低很多,加上另外一些微信独有的优势(当时总结了个统一平台、分享友好、用户接口一致之类的)。所以比较一下两种选型,最后得出小程序是在大陆互联网环境下的一个好选择,我觉得这个思路还是可以有的。其实 PWA 是 Progressive 的,正常来说在微信的 WebView 里用其实体验也不差,在另外一些入口需求不是那么重要的场景里,不上小程序是足够的,还能增加一些技术中立。个人认为像参观类的对外应用,Top N 的大学对国际用户还是要友好的,要是只能通过微信做预约,国际友人注册个微信还是挺麻烦的。

      账号体系的话,比如参观类的应用来说,这是一个低频需求,预约完成之后最多修改一下预约,用户并不会主动去寻求什么别的服务了,回头客的比例也很小,而且就只是一个预约而已不是什么关乎财产的事情(可能只有恶意取消给别人空出预约名额这种风险而已),网络操作的身份验证要求并不高,所以账号体系可以做得很轻。可以论证一下除了 wx_id [+ 证件号] 之外只拿证件号 + 联系方式做验证,来修改预约信息靠不靠谱(不过说起来并做不到 2FA),当然要做验证码、频率限制之类的风控。我还接触过一些政务类的预约应用,采用的是微信通知发“取消预约密码”的形式,其实也是一种办法。实际上这几个预约的小程序我都没有在里面走过流程(上个月即便预约到了,N 天后也不在北京了),所以只是一种猜测,并不知道实际的实现是怎样。至于说强因素验证什么的,国际上通用的 2FA 之类的方案似乎挺成熟的,+ 微信一下也能适用,基本上还是要基于设备 session 做管理吧。

      最后,祝贺,祝好。欢迎回复继续交流。

发表评论

电子邮件地址不会被公开。 必填项已用*标注