是的，我们在开发一款“会话式综合信息助理”，叫...（2）

前面说了给大事情“会话式综合信息助理”起名字的事情。这里具体说说想要让这个东东干些什么。

2、需求

其实描述性的名字就是需求：即“会话式综合信息助理”。

2.1 “会话式”强调了这个应用的交互体验是会话式的

“会话式”强调了这个应用的交互体验是会话式的。本节将从会话的载体，交互机制，交互操作等方面加以展开。

2.1.1 会话的载体

从会话的载体看，老土认为首先要能够支持图文交互，而不是语音交互。这一方面固然是因为语音识别的技术门槛比较高（如果基于百度和科大讯飞提供的SDK开发也没有那么难），但更主要是因为老土觉得在日常应用中“默默输入一段文字”比“对着手机说一句话”要更随意，更不尴尬，虽然“对着手机说一句话”要显得更有bigger。

老罗在2014年发布锤子手机的时候曾经提到过一个观点“......语音识别技术如果好用，一定要解决几个问题：第一，解决心理问题，让它用起来不丢人，不尴尬....”。

目前图文交互方式的用户熟悉度极高，微信等应用已经完成了用户教育，同时在使用图文交互的时候，用户的心里负担极小。因此我们选择的是“基于图文的交互式”。当然如果已经可以支持图文交互，日后如果要扩展支持语音交互也就是工作量而已（只要不是自己搞语音识别，工作量就不算大）。

语音交互引起的尴尬

2.1.2 交互机制

用户常用的交互机制有获取（get）和推送（push）之分。其中“获取”指的是用户主动发起一次会话，而应用则被动响应会话。“推送”则是用户被动的接收来自应用的消息。在本应用中，对这两种交互方式都要加以支持。

“获取”的交互方式最适用于信息查询类的应用，用户可以主动的发起各种类型的查询。但老土希望这里的查询不是简单的将用户的查询请求转发到对应的服务商的接口处，而后将服务商的反馈转发给用户，而是要做一些后继的处理，以优化用户体验。就以搜索引擎查询为例，用户发起搜索后，不要简单的将搜索引擎的响应内容转发给用户，而要提供后继处理，在处理后显示给用户，如：用户可以选择是否查看搜索引擎中的广告，可以选择一下查看前面2页或是3页的搜索结果，可以选择对搜索结果进行分析和处理，让搜索结果更加直观等。

“推送”的交互方式则更主要应用在“通知”类的应用场景中。老土一直假想一个应用场景就是，在“云端”有位“田螺姑娘”，她默默的将个人的各种繁琐的事宜一并搞定，比如：过滤不想接听的电话（这里“不想接听的电话”不仅包括各种垃圾电话，还包括来“催债”的人的电话等）；又比如：安排个人的日程。老土一直觉得在电影中“成功人士”的助理向其汇报后面的时间安排显得非常牛x。这类日程安排的事情完全可以依赖云端的“田螺姑娘”，并在事前给出提醒。如果做的更好，则不但要给出提醒，还可以帮忙准备下一步工作的相关材料。这前述场景中，都需要应用有将信息主动推送给用户的机制。

田螺姑娘本就是完美的个人助理呀...

2.1.3 交互操作

关于交互操作，老土要强调的是“控制”和“开放”。这两点看似矛盾，但在具体的场景中可以很好的加以整合。

先说控制。

A. 要能够支持多种常见的交互过程，但不强调无限制的灵活。具体举例如下：

不论用户输入“天气”、“天气预报”、“北京天气”、“北京天气预报”都可以触发天气查询，并不会支持对“北京的天儿咋样呀”的响应。

B. 要控制用户的“输入灵活性”，从而简化对用户输入的处理复杂度。具体举例如下：

当用户输入“天气”、“天气预报”的时候，应用响应“请问您要查哪个城市呢？”，同时在用户的输入框变成了城市选取区，而不是一成不变的输入框。

再说开放。这里开放主要指的是响应信息的形式要具备开放性，可以包容多种信息形式和交互方式。具体举例如下：

当用户查询新闻的时候，应用可以以“卡片”的形式直接给出新闻的图文摘要。用户可以通过在卡片上的操作完成其他功能，如：赞、评论、查看详情（点击新闻后，弹出新页面，显示新闻详情）。
当用户查询天气的时候，可以通过在水平维度上放置多张卡片，显示多个城市的天气（如：记录用户最近查询过的5个城市）。用户可以水平滚动卡片，查看其他城市的天气。
当用户查询新闻的时候，可以通过在水平维度上放置多张卡片，显示多条新闻。用户可以水平滚动卡片，查看其他新闻。

从水平和垂直两个维度提供导航的灵活性