应用启示录—呼唤内置应用搜索引擎的出现
iPhone和iPad的应用超过50万个,Android上的应用超过30万,其他平台上还有成千上万(参见
\n移动应用总量突破百万)。平均每个用户手机上的应用数量为65(来源:
\nFlurry)。相信各位看官的可能比这还要多。
甚至还有专门成立用解决“应用发现”问题的公司—由于供应商自己的应用商店所提供的应用搜索机制手段有限,这些公司就冒出来填补其空白。应用开发者当然受益匪浅,因为自己的作品只是在应用汪洋大海当中的沧海一粟,很难被发现。这些产品最后的结果是给消费者提供诸如此类的工具:“找出新的酷应用”,“找出朋友喜欢的应用”或者“找出做X事的最佳应用”。
这些努力,应用开发者感激,最终用户乐意,尽管如此,它们还是没有办法解决一个真正的问题:找出你已经安装进自己手机的应用。
一个有趣的事实是,在平均应用安装数量方面,非科学调查的结论与分析机构的精确数据大抵一致,65个。
但是,实际使用的究竟有多少呢?根据Flurry的数据,
\n每周消费者平均仅使用
\n15
\n个应用
\n。这意味着安装在手机上的应用大部分都只是偶尔使用。消遣的时候才会玩游戏,跟朋友吃饭的时候才会用到小费计算器或者分账器,开始节食的时候才会用到卡路里计数器,车库拍卖查找器,照片上传工具,还有那些孩子们都喜欢的游戏……要是再算上商业工具的话,还可以数得出多少来?
问题就在这里。
除非你的应用起的名字刚好合适,并针对搜索进行了优化,内置的应用搜索机制是严重缺乏的,起码iPhone和Android那两大平台是这样的,本文将会讨论这一问题。
举个例子,在我的iPhone上做个测试,在iPhone的Spotlight Search输入框上敲“deal(交易)”,你可以搜不到
\nGroupon或者
\nLivingSocial。Android的也不行—你得敲应用的名字。
不过,古怪的是,事情并非总是如此。输入“recipes(食谱)” 就会出现
\nEpicurious。但是Android上就不行。在iPhone上敲“deals”,会出
\nBiteHunter。在iPhone上输入“Shopping”就会得到
\nFastMall和
\nZoomingo,但是却没有
\nTarget或者
\nBest Buy。在Android上的测试类似,应用只能按名字搜索,而非功能。
怎么会发生这样的事?
在利用iOS内置搜索能力方面,似乎有的应用开发者比其他的开发者更加擅长。也就是说,用关键字填充自己的应用名字。(比如说,Epicurious的全名叫做“Epicurious Recipes & Shopping List”)
这是个问题,因为搜索是寻找应用的最快方式。毕竟,Android设计的初衷就是隐藏大部分的应用,只把你喜欢的几个放在屏幕上。与此同时,iOS则是用文件夹来处理应用过载问题的……丑陋的文件夹,极不优雅的处理方式。
这些解决方案与有效的搜索机制相比显得苍白无力。但是即便现在是以关键字为基础的搜索,由于搜索结果是按照字母排列的,在将来也不见得那么有用。
我的意思是说,真的,按字母排列搜索结果!想象一下,如果Google是这么排列web的搜索的结果的话!当然应用商店的生态系统规模很难跟web相提并论。但是它还在一直疯长,不断壮大。
与此同时,用户还将遭遇应用的另一个停止点—一道心理上的鸿沟,不仅仅是手机存储空间的限制,还由于自己的心智能力有限,没办法处理安装了500至1000个应用的手机。
因此这里我们提出一个疯狂的主意:让我们的设备拥有一个真正的搜索引擎,这个引擎的能力起码要跟应用商店的引擎一样强大,如果不是更好的话。应用应当经过关键字优化,由数十种信号进行排名和评价。内置应用搜索引擎应该知道你都安装了哪些应用,使用的频率如何,安装多久了,什么时候买的,排名情况如何,你对其的评价又如何,你的朋友有谁在用它,这款应用能够做什么,不能做什么。
在iPone上,Siri也许有朝一日会成为引擎—我们“再现”已安装应用的方式也许是通过开发者跟Siri的集成实现的。你问一个问题,然后Siri就打开相关应用。不过Siri乌托邦还有很长一段路要走—它现在还只是alpha版的产品。
与此同时,我们不应该下载每一个喜欢的应用,相反,我们应该提供一个快速访问这些应用的手段,不管其是否在我们的设备上即可。iCloud是实现这一点的一个很好的起步—你喜爱的应用可以存储在云端,并通过Spotlight Search浮出水面。而对于Google来说,这个搜索巨头当然可以做出更好引擎供我们搜索手机上的应用。
时不我待。现在我们的手机上的应用已经非常拥挤了,副作用已经开始出现。如果内置应用搜索还得不到改善,没有人会想要试一下你的新应用的,“非常感谢,但是我的应用已经够多了”。
若如此,那可真是一件相当悲哀的事情。
Via:
\nTC