搜索是网站也好,app 也好,最常见的需求之一。也是看起来最简单,实则很复杂的元素之一。

确定需求

做搜索之前,首先要问问自己:我们真的需要搜索吗?

搜索的优点和缺点

优点

发挥其独特的辅助导航功能,让用户在导航系统没法找到想要的东西的时候快速找到想要的。我们之所以在互联网上做设计,最主要的目的之一就是让人们便捷的找到他们想找到的信息。

那么什么情况下,最适合搜索引擎发挥他的功能呢?

  • 大量数据。
  • 数据不统一。比如由多部门维护的网站,数据格式不统一,架构也不一样,导航已无能为力。
  • 数据具有动态性碎片性,无法逐一归纳到导航系统里。比如微博。

另一方面,搜索是极有用处的用研工具。它有助于你制定标签,制作受控词表,以及改进搜索本身的设计。

缺点

开发搜索引擎需要成本。如果时间很短,这可能影响其他导航的设计。
比之其他导航,搜索本身需要用户付出的成本可能更高。一般来说要打字,或者说话,更坑的是,用户需要思考出来他到底应该输入什么关键词,换言之,要想用户使用搜索,用户必须要有明确的目标。

当决定是否做搜索时,除了上面所述的优缺点,用户习惯也是考虑的因素之一。当搜索框在互联网上随处可见时,用户可能期望你的产品里也有搜索。当你没有时,他可能会感到你的产品有所残缺。如果你不想给用户留下这种印象,就要做好导航系统,把用户的注意力吸引到其他地方去,让他们忘记搜索这回事。

如果已经决定做搜索了,就继续下面的过程吧。

触发器

关于搜索的触发器,相对而言已经非常标准。一个搜索框+搜索按钮的“标配”已经深入人心。图形标签“放大镜”也已经成为了标准。

常见的变化有两种:

  • 隐藏输入框,默认只显示放大镜。这取决于页面的空间限制以及搜索的重要程度。
  • 搜索会有一个单独的页面。这通常是在搜索针对全局,并且和当前页联系不紧密,以及搜索页需要承载更多需求(比如推荐等)有关。

对于搜索框本身,适当的提示文字很重要。提示文字可以引导用户的思路,让他们去搜索“你想让他们搜索的内容”;同时,提示文字也可以引导用户尽量输入便于程序处理的关键词,而不是更加复杂的自然语言。

如果你的输入框支持一些高级特性,比如布尔运算符等。可以考虑通过额外的帮助或者提示来引导用户。比如小的帮助图标等。

无论如何,表单检查是必要的。避免发送一个空字符串给后端浪费搜索资源,同时检查关键词是否符合搜索引擎的其他技术要求。

**触发器出现的时机同样重要。**一般来说,全局导航或者区域导航常常伴随着搜索触发器的设置。但是,当用户遇到挫折时,恰当的提供搜索也是一个不错的选择。比如用户导航到了一个为空的页面,就可以适当的提供搜索,让搜索发挥好其辅助导航的作用。

搜索区域

既然要搜索,那么避不开的一个问题是在哪里搜。固然,用户没有这个意识,一般认为就是从全站找,但是我们却不得不面临这样的问题:从全站找可能数量过多,或找出一些只是关键字凑巧碰上但是其实完全不相干的内容,而只找某一部分的话,到底在哪一部分找,以及万一没找不到怎么办?

这时候首先要决定:我们到底要不要让用户来决定搜索区域呢?

如果让用户决定:

  • 因为增加了交互成本,所以需要用户使用搜索的动力很强,否则可能不搜了;
  • 需要用户具有一定的专业性,非常清楚自己要在哪一部分搜索;

如果满足这些条件,用户可以以尽量少的搜索次数找到他想要的内容。对于用户本人,增加了一点确定区域的成本,减少了多次搜索的成本;对于我们来说,降低了搜索的次数,减少了服务器压力。

显然,用户决定的条件很苛刻。更多情况下,大概还是需要系统来决定。但是有时候不可避免的需要获取用户对于搜索区域的定义。那么最好安排在第一次搜索之后,提供给用户一些筛选项,比如分类、时间、语言、用户类别等。这时候,用户已经看到了结果,他可以再行判断结果中是否包含他想要的结果,如果太多了,或者没找到,他可以再使用这些筛选项定义搜索区域进行重复搜索。此时的用户更容易接受对于搜索区域的定义。

那么默认情况下对于搜索区域的定义首先要和界面相结合。搜索和全局导航安排在一起,那他给人的感觉就是搜索全站的,那么我们就应该把它做成搜索全站的。如果是某一个子模块的,比如说一个放在帮助中心首页的搜索,那显然,他就应该只搜索帮助中心,而不是搜索全站。

搜索区域的定义还可以和关键词的语义相结合。当然,这涉及到对关键词自然语言分析的问题。在技术允许的情况下,我们应该考虑如何识别关键词中定义搜索区域的元素。比如“近三天的新闻”。

用户决定搜索区域需要的触发器多种多样,各种表单、菜单不再赘述,而系统判断搜索区域实际上已经属于搜索规则的一部分了。下篇讨论搜索规则,以及信息架构中的元数据、受控词表相关内容。