微信的入口梦应由HTML5承载

HTML,ASP,JSP,PHP    2013-01-10 09:19  

  一款智能手机上的应用,它到底能变得有多复杂、多重,可以承载多少功能?

  试图让一款“超级应用”成为强势移动平台上的唯一入口,本身就是不太现实的。且不管苹果、Google和微软会对你做些什么,而是本身如果一款产品过“重”的话,当你在智能手机上需要划动多个界面才能找到某些功能和应用的话,会带来哪些用户体验上的负效应?除非谁能告诉我,在智能手机上,有哪款产品是靠“复杂”而并非“简洁”获得用户喜欢的。

  文后即有一则评论:“有了flipboard之后我就把所有的媒体类app给卸了,如果微信能够让我摆脱图标海洋的话我很乐意让它再膨胀点,移动端的屏幕就应该简洁点,对么?”

  这跟iOS引入“报刊杂志”和“Passbook”的想法一致——不见得原生应用就不“需要划动多个界面才能找到某些功能和应用”。

  之前TechCrunch公布了第三方统计的Facebook移动用户数据,发现使用Camera、Poke等脱离主程序之外应用的占比很少。TC编辑吐槽说,“现在Facebook独立出来的应用越来越多,就不怕用户有一天把它们塞进一个名叫Facebook的文件夹里,然后除了主应用,别的碰都不碰么?”

  我觉得与其让用户忍受一款复杂臃肿但又不得不用的核心应用,拆分非核心功能,“创建另一个与微信关系密切的独立工具或工具群”,确实更符合我等自定义控的胃口,但将会是超级不可行的。

  讲一个非常特殊的例子,就是人人网。Facebook将messenger独立出来,人人有样学样,居然把悄悄话这个该站最主要的功能之一独立出来,做了一个“私信”的应用。这个改动是如此的失败,以至于他们只好改回来,宣布“挑战微信”的破产。

   拆分还是合并? 

  微信到底能不能承载那么多东西?一个多元化的服务在做App时,它的功能是不是应该完全拆开?这都不是你我说了算的,我们要从前人的尝试中找答案。

  首先看一家公司拆分多个app的。最典型的是谷歌和豆瓣,这两者要拆分的原因不太一样:谷歌是各个服务之间的差异太大,而且不适合用web app形式加载高级功能,比如地图这样的应用,只能独立出来做。豆瓣则是从整个站点规划的角度,想把点评、音乐、同城和社区完全分开,因此即使实际上做成一个app也没啥不行的,它还是要出一堆App。

  同样是网站的核心功能,豆瓣就能彼此独立,人人网就不行,这还是由产品基因决定的,不能一概而论。

  然后看一家公司只有一个app的。抛开微信不说,手机QQ客户端内通过web app方式可以访问腾讯各类业务,即使这些业务都有各自的客户端,但在QQ依然可以通过做成图标状的快捷方式一站式访问。点击并不需要太多步骤,只需要点两次(切换到应用tab,点击相应图标)。

  还有就是想做HTML5应用商店的各种浏览器。在一个浏览器内打开各种服务,这是浏览器的题中应有之义,国内各家浏览器在如何吸引用户访问HTML5版应用替换原生客户端方面是下了很大功夫的,包括首页网址导航从wap版转到H5版,采用闪动的提示数字吸引用户点击,等等。只要用户网速够快,运行效率和原生应用的差距还是在缩小的。

   Web App不会让微信变“重” 

  我们还是说回微信。上面的讨论其实明确了一点,就是如果把应用当成浏览器,这个应用就完全有可能成为移动平台上的唯一入口,一切只要它成功的教育了用户——还有网速足够承载HTML5应用。所以微信在大号上不断开放API,鼓励大号跳转到它们各自的移动网页版页面,这是将希望寄托在未来WebApp和原生应用表现差不多的可能性上,而这个可能性将有很大可能实现。

  如果微信应用商店的最终页只是一个浏览器框架,那么对微信本身来说,它一点都不会“重”,不需要这些功能的用户也不会受到太大影响。

  我想,在使用HTML5的前提下,能在微信上实现的功能,也能轻松迁移到浏览器应用商店,甚至打个包伪装成原生应用都行,因此不管对腾讯还是对开发者而言,都不是太大的负累。如果通过这种方式,存在引爆新的使用习惯的可能性,那为什么不去做呢?

在线留言

我要留言