文本的未来在最传统的媒介上玩出新花样

　　注：本文作者Jonathan Libov，于2014年加入 Union Square Ventures，同时也是前Appsfire产品经理。
　　天气不好时，我就会搭公交车去上班。尽管许多应用都可以在地图上直接显示公车的位置，但是当我知道我可以利用纽约的 MTA 服务，直接 Bus Time 发短信获取车的位置和到达时刻的时候，我还是忍不住想：＂感谢上帝，我终于不用为了等车再下一个应用了。＂
　　相比既定输入规则的图形界面，作为接口的文本对话正迎来一场解放，尽管不同的 App 会有不同的输入规定。但是无论是哪种，他们都有一些共性：我打的文字在右侧，其他人发的内容在左侧，而最下方的是输入栏。
　　当然，Google Now 和 Siri 代表了另一种替代 App 的选择。然而，我并不认为未来我们会和电脑以语言交流。虽然《A Space Odyssey》(太空漫游) 和《Her》都将这种它描绘成最不费力的交流方式，但是和点点鼠标、敲敲键盘，或是轻触图标启动图像界面比起来，说话需要更多认知和身体上的努力。想想看，有时候你宁愿和别人发一百条短信，而不是花几分钟打电话制定计划。这是因为尽管文字不是最方便的，但是这种方式却让人觉得最舒服。
　　我相信对于软件来说，舒适比便捷要重要的多，而文字就是一种让人舒服的媒介。用文字交流快速，有趣又很灵活，可以撒娇卖萌，也可以客观记叙，而且与用户界面和语言相比，有时文字读起来更流畅。
　　但是就 Bus Time 而言，这种交流仍然有改进的空间：机器的语言仍然没有那么自然，在查询了一个月同一辆车之后，它依然没有记住我乘坐的车号。事实上，这里就体现了应用和服务最基本的差别：服务只是输入输出的终端，而应用则应当保留每个阶段的状态。我希望有一天，服务也可以进化成 App 那样记录状态信息，在我登上车后和我继续对话：
　　另一个明显的问题是，这种交流需要用户像打命令行一样的精准：同样的例子，如果我打了＂23& 8ht 23M＂就不能识别。目前的自然语言处理技术还不足以很好地支撑以文本为主要交互手段的应用。
　　尽管自然语言处理技术还不够发达，但还是有可以改进的方法，并且这些方法已经被人使用了。
　　图形用户界面辅助聊天
　　Lark for iPhone 是一款和 HealthKit 平台兼容的虚拟健身教练，通过图形用户界面，你可以和 lark 自由对话。
　　在内容的设计上，Lark 也构思巧妙。自然的语气和不紧不慢的节奏不会让你觉得自己被敷衍了。
　　其实 iOS 内置的短信应用也有类似的智慧。iOS 8 更新的 QuickType 功能就有预测提示的功能（见下图），虽然 T9 和 Swype 早就有了。
　　具有Persona（用户角色）的应用
　　在西方市场，如果你想从你的 iPhone 上获取服务，你可以访问手机版的网页或者是下载一个 app。但是在中国的微信上，你可能只需要在订阅号里就可以查看，省去了下载 App 的必要。
　　还是回到我们之前讨论的 Bus Time 问题，建立 Persona 可能是一种更优雅的解决方案，比如告诉我 M23 专有的 PTSN 号，我以后就可以直接给那个号码发送信息。
　　最有可能成为＂西方微信＂的是 Facebook Messenger。他们最近还收购了一家语音辨识技术公司 Wit.ai，也许因为之前得罪了太多开发者。无论如何，用户现在都可以在 Messenger 中体验原本在 App 上才能体验的服务了。
　　与此同时，Path（据报道为苹果的收购对象）收购了 TalkTo，意图集成 TalkTo 中用户向商家询问价格、预定服务和显示地理位置等功能。Kik 和 Snapchat 也瞄准了同一领域。还有这周末出场的虚拟助手 Magic，完全依靠短信与用户交互。
　　如果这种 App-as-Personae 模型在西方流行，那么直接受到打击的就是 Google（搜索量会减少）和苹果（App Store 会受到影响）。尤其是卡片式设计走向成熟后，原本封装于 App 和网页的内容都可以轻轻松松地从聊天中获得。下面这个视频展示了 Wildcard SDK 如何将蓝色链接里的内容直接转换成快速的卡片式信息。
　　视频地址请戳这边，自行前去观摩~
　　还有今天刚出现在 Product Hunt 上的 Luka 也在卡片式上玩了一手好牌。
　　你也许会认为，苹果和 Google 一定已经预见到了这一点，所以他们有两条路，要不就扼杀 Facebook，让 Messenger 无法与其他服务合并，但这看起来并不现实。而另一个选择就是抢占先机。
　　对于 Google 和苹果来说，最容易想到的方法就是开放他们自己的 Hangouts 和 Messages。但是这样会打乱他们原本的架构，所以另一种可能的方法是对所有 OS 上文本都嵌入服务。
　　更深层的含义
　　之前我所阐述的例子在交互的模式上都是与用户不相关的。图形界面辅助的方式给与用户主动提出的问题明确的回应；而用户角色也只是让原本应该出现在 Springboard 上的信息出现在了联系人列表上。那会不会有一种更加流畅，偏向于交流的方式？让用户脱离 OS 定义的必需打开应用的规则，根据自己的需要和谈话内容驱动服务？
　　还真的有，ChatGrape 避免了打开额外的窗口或应用，你只需要输入＂#＂加上文件名就可以得到你要寻找的文件资料。
　　当然，这么做需要打开一个第三方应用，但是这种快速传送文档资料内数据的方式会极大提高了效率。
　　另外，Slack，作为一个纯文档爱好者，都不给你自行无聊地配置文件信息的权利，所有的过程都是通过和 slack 交谈完成的。
　　Slack 很好的整合了各个功能，简单地难以置信，比如说，你只要打＂/appear＂就可以启动 appear.in 进行视频聊天。
　　不难想到，同样的功能也可以拓展到手机上。事实上手机上确实实现了部分类似的功能：
　　假如 OS 也可以识别对话中的关键字：
　　上图中，OS 识别了＂talk this out＂，一旦用户点击它，就会向对方发起呼叫。用户就不需要再启动 Facetime 或者是进入通讯录去寻找那个＂Call on facetime＂的按钮了。
　　现在再发挥一下我们的想象力，假如 App 和服务也可以识别不同的关键字：时间，行为，名字，品牌等等。比如 OS 知道我是一个 Foursquare 用户，那我就可以直接向 Foursqure＂寻求建议＂：
　　假如这些回应可以直接出现在我的输入框里：
　　或者当我不在发送消息时，它也能针对我选中文字提供语义上关联的内容：
　　这么做最有趣的一点是，它将内容，从内容制造者本身转移到了 OS 和其他服务提供的延伸内容上，也许是上图这个被选中的人对这件事发表的观点。这种拓展就像语言本身一样，充满了无尽的可能。
　　对这场【开始】的总结
　　信息传递，对机器和我们来说是一种相同的交流方式。上面提到的任何一种方式都有可能对人机交流带来质的改变。然而目前，机器和我们的交互还是停留在 处理我们给与的没有关联的问题上：我们给它命令，我们要打开文件，我们点击超链接，点击图标。传递方式的改变，模拟自然交流的用户界面和内置的超链接会让 这种交互更加自然流利。
　　除此以外，信息传递的 AI 也将得益于我们的回馈。随着交流的积累，它们会更加完善。对于 GUI 来说，这样的优势并不明显。未来，这些基于文本的 AI 所能达到的高度会是图形界面所远不能及的。