面向微信的WebApp产品观
自从入行以来,本人的产品经理工作一直以移动端网站为主,也就是大家常说的WebApp。接触的时间久了,对WebApp这种产品形态产生了较多的认识和感悟,在这里分享给大家。希望给在这个方向上有工作需要的同学,带来一些帮助。
WebApp与NativeApp的对比
这已经是老生常谈了,网上的分析文章一搜一大堆,我相信只要是合格的移动产品经理,对这个问题都能回答的八九不离十。所以关于WebApp与NativeApp,我只想谈其中一点,也就是它们之间差距最大的地方:NativeApp需要下载安装,而WebApp不需要。
最开始我以为这是WebApp的优势所在,后来发现自己真的是too young too simple。原来这世上,你在某些方面的优势,会成为埋藏在另一个地方的祸根。NativeApp初次使用的门槛高,但一旦下载,产品就能在用户的手机桌面获得一个稳定的入口,只要不卸载,用户和产品就有可能产生持续的连接,这是WebApp所办不到的。在实际的工作中我发现,通过手机浏览器把网站保存在桌面这个功能,90%的用户要么不会,要么不习惯。
WebApp虽然在便捷性上胜出,但在入口这件最重要的事情上却输的彻底。过去业界一直在谈论WebApp与NativeApp之争谁胜谁负,现在看来毫无疑问是NativeApp压倒了WebApp,手机浏览器也不再是移动互联网中最重要的入口。而且智能手机时代发展到现在,用户的使用习惯基本已经建立,个人认为WebApp再翻盘的机会也不大。
为什么还要做WebApp
Web端和客户端是互联网的两种最典型的产品形态,PC时代Web端更强盛,智能手机时代则是客户端更主流。在不同历史时期会出现一强一弱的格局,但谁也没有能力把另一方打垮、消灭,反而会相互融合,产生新的产品形态(Hybrid APP)。
所以,哪怕不是目前的主流,WebApp依然有它的生存空间,也能活的很好。这也是我目前依然从事WebApp产品工作的意义。那么,哪些领域和场景是适合WebApp发展的呢?我的经验是:轻体验、轻入口、重传播、重转化。
怎么理解呢?就是指那些对产品体验要求没那么高,不在意用户是否每天固定访问(相对而言),重视单个页面的传播率和转化率的领域。比如媒体、微商、官网、营销活动等等。
另外,很多互联网公司产品都是横跨多个平台的,虽然从战略意义上讲,手机web端往往只能排第三,要么PC端第一,要么APP第一。但谁不敢忽视手机web端给其他平台产品带来的传播和引流作用。
面向微信的移动网站设计
写到这里,其实一个结论已经呼之欲出:社交网络是满足WebApp特性最好不过的生长土壤。社交网络用户基数大,传播效应强,内容时效性短,天生就适合WebApp的使用场景,所以我们在微信中越来越多地看到别人分享的网站链接,以及各种花哨炫酷的H5网页活动。
相信很多细心的产品同学应该能留意到,同一款产品,在微信上和手机浏览器上会是不一样的两个版本。那么,为什么要面向微信单独设计一个产品版本?基于微信的WebApp和基于手机浏览器的WebApp有哪些差异?这也是我这篇文章要重点向大家说明的内容。
微信是目前国内移动互联网最具核心地位的一款APP,也是最大的移动流量入口。它是如此的重要,以至于创业者完全有必要单独设计出一个版本,来迎合微信的产品特性,或者说是,适应微信生态里的游戏规则。在微信内使用WebApp,实际上就是用微信内置的浏览器来打开网页,它与其他浏览器上的WebApp,有以下几个方面的不同:
1.注册登录
浏览器上的WebApp只能通过邮箱或手机号注册登录,没办法像PC站点或NativeApp那样使用第三方账号登录,相关的接口迟迟没有放开。但微信内网页可以通过授权,获得用户的微信ID、头像、名称等,从而达到免注册登录的效果。这一操作极大地降低了用户进一步使用产品功能的门槛,给WebApp获取注册用户带来方便。所以在设计微信内WebApp的注册登录时,必须要把微信登录这一因素考虑进去。
2.导航设计
NativeApp通常会采用底部一级导航,顶部二级导航的信息架构,这样做的好处是让一、二级导航在上有很好的区隔,同时底部一级导航更方便用户点击。但对于WebApp而言,浏览器窗口本身就占据了屏幕不少的空间,再把导航固定显示的话,内容展示的区域就更小了。比如淘宝WebApp在iPhone5s上就会是这样的效果:
尤其是浏览器底部操作栏,跟WebApp的一级导航放在一起,感觉非常别扭,所以WebApp采取这种导航结构的并不多见。但在应用在微信内的WebApp就不一样,它的设计可以趋同于NativeApp,因为微信内置的浏览器底部没有固定显示的工具栏,同时,把底部导航设计得和微信APP一致,会让用户以为并没有脱离微信,从而产生熟悉感和安全感。
所以我们可以经常看到,点击某些公众号的底部菜单,明明已经跳转到某个外部WebApp上了,但感觉上还是像停留在公众号里面。
3.头部设计
对于一个网站来说,头部设计是要花很大精力的,它代表了一个产品给人的第一印象。特别是网站logo,老板可能会纠结好长时间。微信内WebApp在这一点上就又不一样了,因为微信自带了一个头部,同时还会显示当前的网页名称。所以,一般的网站在微信内会出现两个头部,一个是微信的,一个是自己的,显得冗余并浪费空间。比如唯品会:
我们再来看看京东是怎么做的:
京东很巧妙地把原本属于头部的品牌logo、搜索框放在了banner图上,同时加大了banner的高度。这样既避免了双头部的美观问题,又让banner图更大更有冲击力。果然还是儿子最懂爹的心事啊。
用于微信的WebApp,采用无头部设计会在视觉上感觉更清爽。参考案例:
4.分享
从浏览器打开的WebApp,是没办法把某个页面分享到微信的。所以几乎每个NativeApp都会在内容页提供分享按钮,但在对应的WebApp上,很少有这个按钮,这也就意味着浏览器内的WebApp缺失传播功能。这一点在微信上得到了弥补,微信网页通常会提供分享操作,但这个操作并不是真的把该网页分享出去,而是出现一个弹出层提示:点击微信右上方的分享按钮。
这种曲线救国的分享方式,想必大家已经司空见惯了吧。千言万语化成一句话,都是微信给逼的啊。。
WebApp在微信和手机浏览器上的不同表现形式,很多都是Web端和客户端之间的通信不顺畅造成的,这其中既有技术层面的原因,也有公司或产品从商业利益出发,主动设置的障碍。技术上的问题,到最后肯定都不是问题。但人为的因素,就很难说了。毕竟在互联网的江湖里,什么样的竞争手段都出现过,而封锁与封杀,只是其中之一罢了。
有关微信WebApp设计的差异,就先分析归纳到这里。以上我所说的,当然不是事情的全部,等我产生新的灵感之后,再分享给大家吧。
作者:李翔 微信号:haoyuebinghe,电商产品经理 以梦喂马 便得自由
本文由 @haoyuebinghe 原创发布于人人都是产品经理 ,未经许可,禁止转载。
学习了.
我不赞成笔者的观点,集成web app的形式,不需要再打开固定的浏览器作为入口;在轻交互的模式下,web app更能进行快速的迭代更新,优势明显;当然缺点也明显,交互形式跟不上是暂时无法解决的;
文字很多的名词用得也不太专业 ➡
其实我不赞成笔者的观点,你是从用户的角度出发来考虑,但是webapp解决了很多问题,很多工具场景根本不需要用到nativeapp来实现,一个浏览器就可以了,你说的问题也会随着技术的发展迎刃而解.
顶
赞!