Archived entries for 产品

由产品开发方委托评估,并授权发表。原载于《程序员》杂志2010年第12期。
本文禁止转载。

产品名称:Microsoft Academic Search 微软学术搜索

首先声明:

评估者并不属于学术搜索产品的针对用户群体,很少使用此类型的工具。

对该产品的受众群体的人口统计学特征、使用偏好、使用情境和相关经验并无深入了解,在评估本产品时也无法对针对用户群进行使用观察。所以本文的评估标准根据的是通用模式和经验用法,评估建议也仅属于启发式评估。

测试环境:

测试设备:PC (windows7)、Mac(os X)、iPad、iPhone 4
浏览器版本:Firefox3.6 , Safari 5.0

整体概括:

产品的整体界面设计专业、简洁、统一、具有吸引力。整体页面气质符合学术用户群体对权威、正式、朴素、冷静的情感需要。
内容上,较之其他的通用学术搜索引擎,本产品包含了大量二级内容页,本质是一个信息数据库。格式规范统一,内容及时准确,多人参与共享,具有极强的优势。

布局合理紧凑,区块划分明晰,层次井然。

入口和导航都十分清晰、易于使用,标签简洁,文字通俗阅读,控件使用规范,符合习惯用法,用户在界面上探索和尝试时没有认知负担,试错的代价很小。

使用流程直观清楚,层次明确,网站整体保持了一致性和标准。个人首次使用能顺利一般性目标和任务,除了call for paper calendar,没有遭遇理解和使用上的困难。

交互过程简单直接,响应快速,用户能立刻从行为看到动作结果,及时获得对其查询和提交信息的反馈。

程序可靠,访问速度很快,使用过程中未遭遇报错和载入迟缓。但大段文本的搜索速度很慢。

兼容性良好,部分功能需要额外安装控件sliverlight ,手持设备无法支持此部分功能。未为手持设备准备适合其的移动版本。

信息图标部分能够增强体验过程的价值,但个人认为交互性不强,易用性上也有一些问题。

不支持多语言。

字体过小,对视力不好的用户不友好。没有对残疾用户提供特定的帮助。

内容点详述:

整体界面设计:

首页:

首页采用居中布局,入口明确,层次明晰。拥有令人舒适的配色。LOGO的设计非常出色。
同时采用TAB(卡片堆)模式展示了产品所包含内容,提示了用户查询方向。

  • 但个人认为作为Tab模式,对当前选中状态(水平线上向上的小箭头)的标示不够醒目。Active tab control 选中的标签 与Pane内容器 之间的对应关系指示不够明确

布局:

信息展示采用了非常清晰的编组策略,用户可以快速掌握信息的组织和结构,从容地进行浏览。,

视觉流:

焦点清晰,分布合理,无干扰,符合F型浏览模式,与扫描关键字为目的的用户浏览需求相匹配。

导航:

面包屑层级结构、二级导航的设计很漂亮,递进关系和当前状态指示都很明确。

提示性和辅助操作:

高级搜索和帮助信息都通过Tooltip实现,不离开当前操作界面,无需返回,用户无需记忆和比较,是非常好的设计。

字体:

正文部分字体偏小。从事学术研究的受众中,有很大一部分的年龄较大,过小的字体对他们是很重的阅读负担。Line-height 也偏小。

  • 可以增加正文部分字号。或者让用户可以直接在阅读界面选择字号大小,并记住用户的选择。

搜索结果的显示:

一组搜索结果中包括 Title、Citations、Author、Summary、Conference、Journal 6个信息元素。但只有Title 与其他信息类别间存在明显对比。其它都使用了同样的字号、配色、格式。视觉上会将这部分的信息视为一体,而中止分拣其中的内容。不便于快速扫描中的用户捕捉所需的关键字。

对比google scholar 的搜索结果,可以发现google一共使用了4种颜色来区分不同类型的信息元素。对于一个额外关注出版信息的用户,在快速扫描的时候关注绿色的字就可以。虽然google的设计在视觉上看起来原始粗糙,但在对于快速浏览则体验要好很多。

  • 建议采用其他颜色或格式来区分不同类型的信息
  • 建议标题和正文使用具有对比效果的两种字体。

关键字的标粗与标红:

标红和标粗都是搜索页面常用的策略,都可以起到突出关键字作用。
Academic采用的是关键字标粗。

  • 但个人认为标粗会导致关键字和所在正文之间的对比过于强烈,形成多个分散视觉焦点,会做中断用户的扫描浏览过程。在一句话中如果出现几个格式过于突出的词,很有可能造成用户无法顺利阅读整句话。

关键字标红可以起到同样的效果,但干扰会小一些。见附图中google的处理

这个作者信息介绍页面也有同样的问题,不同类别的信息元素采用完全相同的格式,密度又高,用户想检索到所需的信息是很困难的。

  • 这里同样存在着字号太小,line-height过窄的问题。

容错:

将关键字拼写错误后测试,academic的策略是

  • 在错误拼写有搜索结果的情况下,列出错误拼写的结果
  • 在错误拼写无搜索结果的情况下,提示正确拼写,不提供搜索结果。

还可以有另一种处理策略:

  • 在错误拼写有搜索结果的情况下,提示正确的拼写,列出正确拼写的前几条结果,同时列出错误拼写的结果。
  • 在错误拼写无搜索结果的情况下,提示正确的拼写,列出正确拼写的搜索结果前几条结果,同时提醒用户找不到错误拼写的结果。
  • 个人觉得后一种的处理更恰当一些。减少用户为错误付出代价。任务流也不会因为出错而完全终止。
  • 同时academic的对拼写错误的提示也不够醒目,实际上用户大量时候不阅读提示,对于完全空白的搜索结果会有不知所措的感觉。

高级搜索:

academic的高级搜索功能非常出色。
较之google scholar,需要跳转到另一个页面进行高级设置的方式(非常鸡肋的方式,导致高级搜索成为许多搜索功能的摆设)要好很多。
不会中断动作,不会离开当前页面,不会结束任务流。同时使用可视化的控件来帮助用户使用和学习语法,减少输入操作。兼具开放性。同时兼顾高级用户和初级用户。这种 可视化控件+语法标签 的模式现在也的确很风行。

按钮的设计:

Academic 中的对站外链接采用的icon 使用的IE浏览器的图标。

  • 个人感觉使用IE的icon不是很恰当。不仅是因为用户对IE浏览器的icon 存在固有认识,它既不代表html格式,也不代表web,也不代表link。
  • 外链的通用图标是 。也强调格式的时候也可以使用

这个IE icon 的download 同样令人感到混淆。是要下载IE浏览器吗?

  • 建议在下载的时候根据格式来标记icon,如 pdf, ppt, doc,html 等。
  • Edit 的按钮存在样式不统一的情况。

表单:

因为是在正式的系统上测试,所以没有过多地对参与编辑功能进行测试,对多用户参与编辑系统的的审查和版本机制,以及预防编辑冲突及锁定、输入过滤等没有评价。

提交和cancel 的按钮设计采用了同样的样式。用户在使用的时候需要经过分辨决策的过程。

  • 建议采用不同的样式,将submit 按钮突出, Cancel 按钮样式弱化,降低用户丢失操作的可能性。如

排序:

在搜索结果页面和列表页面中,没有提供排序功能。

  • 在这个存在大量数字变量的列表中,排除效率问题考虑,为用户提供排序的控制权是有意义的。

分页:

分页设计 1 没有首页和尾页。2 未提示总页数。

  • Web上分页的设计是一个已经比较成熟的模式,下面是一个比较成熟的设计:尾页和总页数合为一体,用户在任意页数都可以返回首页。

Visual explorer:

visual explorer作为对作者合作关系的可视化,个人感觉是一个没有做透的产品。能够给用户传达的信息比较有限。没有把整体视图和具体的数据值有效地做结合。

从图中的情况可见,在这种信息图表中要查看和操作具体数值是比较困难的,具体数值的显示位置难以寻觅,字体太小,点击也有一定的难度。
由于不知道这类信息图标在学术用户群的使用情境和使用意义。下面仅提出一个建设性意见:

  • 可以在visual explorer的空白处 用一个固定区域来显示详细数值信息。 当鼠标点击某个face或者line 时,用户可在固定区域查看更清晰,更便于阅读和点击的详细数值。

Call forpaper calendar:

Call for paper calendar 是我在使用过程中唯一遇到困难的模块。

  • 缺乏图例。 Deadline 和 会议日程时间 采用了两种在日历上标识的方法,但没有图例说明。
  • 如果同一天有2个以上的会议,Deadline的图例在Calendar上会有重叠。可以尝试采用小圆点等其他图例来解决这个问题。
  • 用户在首次访问这个页面时没有得到引导和帮助
  • Calendar和list的对应关系做得不好。当用户点击 某段会议日程,下面list中对应的行没有任何响应。
  • List 的 表头支持排序,但却没有给用户提示。建议在鼠标划过表头的时候 hover状态显示 排序箭头。
  • 有大量复选框的lise,但不支持全选和反选功能。
  • List 上不支持文本复制

译者:西乔 来源:Smashing Magazine 作者:Jacob Gube

Module Tabs(也称选项卡,后文中简称Tab,以便更符合中国设计师的日常叫法) 是一个常见的交互元素——将不同的内容重叠放置在某一布局区块内,重叠的内容区里的每次只有其中一层是可见的。用户通过鼠标点击或移到内容区所对应的标签上,来请求显示该层内容区。

(译注:本文中指的是狭义的Tab,指在界面的某一版块区域内所应用的Tab设计。实际上,绝大多数网站导航也是Tab的一种应用。)

web界面的设计趋势是缩短页面屏长,降低信息的显示密度,但同时又不能牺牲可视的信息量。在这种趋势下,Tab 这种交互元素成为了一个越来越普遍的应用。例如在Blog界面的设计中,人们在侧边栏使用Tab模式来显示 ”最新更新|最热更新“ 的文章列表以引导用户快速跳转到文章内容页,这种模式令页面结构紧凑同时在视觉上不那么喧宾夺主。

本文将讨论基于web页面或其它web应用中如何设计Tab,同时分享一些产品设计原则、真实的应用案例、教程以及一些能帮助你直接实现Tab应用的免费脚本。

分析Tab元素的构成

为了统一叫法以便于进行讨论,我们先花时间来认识一下Tab元素的每个构成部分。

An illustration of the anatomy of module tabs - see the following description to learn about the anatomy.

  • 标签:用户控制切换内容区的操作区域。
  • 标签和内容区在视觉上看起来应该是一个整体。
  • 标签上的文字应该简洁、无歧义并能准确描述出它所对应的内容区的信息特征。
  • 标签有选中和未选中两种状态,每次只能有一个标签是选中状态,在页面刚载入时,默认第一个标签是选中状态。
  • 内容区:Tab元素中重叠的区块。用于显示信息内容。
  • 内容区和标签一一对应,
  • 当前显示的内容区对应选中状态的标签,当前隐藏的内容区对应未选中状态的标签。
  • 用户应当能很轻易地通过控制标签来切换对应的内容区。
  • 默认被选中的内容区应该在页面载入后立即显示。

一 。什么情况下应用Tab设计

当交互设计师希望节省页面空间;紧凑布局;且需要组合的几种信息之间具有关联性时,可以选择Tab应用。

信息之间具有某种关联特征

构成一个整体的每个元素之间都应该具有逻辑上的关联性。所以出现在同一个tab元素中的几种信息自己应该具有关联特征,这样用户才能将整个Tab区域视为一个整体。例如在Blog中很常见的信息组合:“ 最新更新 | 最热文章 | 评论最多 ” 。

下图是网站Webdesigner Depot的侧边栏上的Tab元素:“全部文章 | 最受欢迎 | 最新更新”

Webdesigner depot module tabs.

信息之间不应该存在对比或并行的关系

Tab元素中,同一时刻,只能显示一层内容区。当用户需要对位于不同内容区上的信息进行对比,或者这几种信息同时显示会更便于用户阅读时,就不应该使用Tab。否则会导致用户为了比对所需的信息,而不停在标签之间进行切换。

下面这个案例中,BGPatterns (一个在线制作背景图案的网站)tab就用得不是地方。当用户想设计或修改他所制作的背景图案时,必须反复在几个标签之间进行切换。Tab在这里妨碍了用户的操作。如果在页面上同时显示这4个内容区上的信息,可用性和友好度会更高。

BGPatterns misuse of module tabs.

另一个反面案例:网站 Best Web Gallery 在它侧边栏上所放置的Tab,标签分别是 ”特别推荐“(包含了一些网站所有者认为值得注意的链接)和 “最新评论”。 这两组信息之间并没有逻辑联系,用户会很疑惑为什么这两者要放在一起呢。所以这个Tab中的两组信息最好分开放置。

Best Web Gallery not using related content for module tabs.

每个内容区应该有一个简短明确的标题。

Tab元素的标签区宽度是有限的,所以标签区的文字应该简洁扼要,具有代表性,长度控制在1~3个英文单词。用精炼的方式展示信息,除了保持设计样式不变形外,还可以让用户更快速地处理文字信息,用以预测隐藏区域上所包含的内容。

Tab应该用于展现精炼的内容。

Tab本意用于展现标准化和易于理解的信息。基于此,Tab应该只用于显示信息摘要和内容要点,例如列表,数据图表,或1~2段简短的文字这种形式。

二 。Tab的可用性原则及优化方法

这一章节 我们将讨论一些关于Tab的可用性设计原则,以及如何使这种交互元素变得更友好和有效。

选中的标签应该高亮显示。

选中状态的标签应该设计得显眼,让用户容易区分当前显示的内容区是对应哪个标签。通用做法是 为未选中状态使用统一的背景色,为出于选中状态的标签上使用高亮的背景色。

保持标签只在一行内显示

Tab的标签通常是水平方向排列的(当然如果你愿意,也可以设计成垂直方向排列的),标签如果分布在多行上会导致用户在使用中产生疑惑。

这是由于在水平方向上多行分布标签,隐含一种等级关系,可能让用户误以为第二行是第一行的子级。

标签需要分布在多行上时,也就意味着标签的数量过多或者标签上文字太长。而这些都是需要被精简的。

Single row counter example - having two rows implies that tab controls have a hierarcial relationship.

内容区之间的切换 应该没有延迟。

使用Tab来控制内容切换的特性之一是快速和互动。为此,应该在html代码里提前内嵌所有内容区的代码,并通过CSS/Javascript来隐藏未被选中内容区,而不是等用户切换到某个标签后再去远程请载入信息。

避免在标签切换的时候去载入页面,使用AJAX从远程读数据来生成动态菜单也是一个办法,但这对使用语音阅读器的用户(译注:Screen-Reader:为视力障碍的用户准备,可以语音读出页面上的信息。)是不友好的,因为语音阅读器不支持DOM模型。

(译注:有4种方法载入隐藏区的内容代码:

  • html 一次性载入:这种方法原始且安全,但是存在数据太多或太复杂导致页面解析缓慢,从而导致整个页面打开速度变慢,这是不可忍受的。
  • frame: 将隐藏区的代码作为一个frame载入,frame的好处是可以新建进程,和页面中的图片同时下载。不同的浏览器可以运行一定数量的进程并行,比如IE可以同时允许4个。这样对整体页面的打开速度影响小。另外,frame可以进入浏览器缓存,在多个页面共用同一个Tab元素时,frame是一个好选择。
  • iframe:iframe和frame类似,继承了frame的优点,此外它还可以作为一个容器随意嵌入页面。google adsense使用了iframe来实现了局部代码的载入。。
  • Ajax:响应用户操作或响应某个触发条件,由JS在后台向服务器发出请求,载入隐藏区的代码。我认为除了交互和需要响应动态生成的内容外,没必要ajax技术。)

在标签上使用简短和有逻辑的文字。

标签应该设计得尽可能窄,以便在一行内容纳尽可能多的标签。

在标签区使用简单的描述或内容关键字,可以帮助用户在扫描页面时快速找到他们想要的内容。所以使用概括准确符合逻辑的文字来描述内容区是非常重要的,选用这些文字应该经过深思熟虑。

下面这个在网站CBS.com上的案例,是一个难用的Tab。标签上没有任何说明性文字,用户无法预测未显示的内容区里到底有什么。

C B S dot com do not use descriptive tab control text making it hard to anticipate what content is.

而在 Navigant Consulting 的网站上,使用数字来暗示数据是有序的。但仍然没有表达出内容区里包含什么。这种设计容易产生歧义导致用户产生不必要的困惑。

Navigant Consulting uses numbers for tab control text.

不要在内容区内使用滚动条

在Tab的内容区里使用滚动条会增加用户负担:用户在要查找信息在哪个内容区里时,不仅需要切换标签,还需要加上移动滚动条的操作。

内容区里容纳的信息太多或设计Tab时设定的高度不够,会导致滚动条出现。所以需要考虑精简内容、增加高度值,或把选中状态的内容区处理为的高度自适应。

三。考虑Tab的易用性

更复杂的交互行为的出现,在不刷新页面的状态下异步更新内容,以及如何满足用户使用不同访问方式,包括那些很难确定的非典型状况下的访问需求,这些状况令易用性成为当前最热门的话题。本章节中,我们将讨论一些在设计Tab元素时你应该知道的易用性原则。

“选择”和“未选中”状态的标签 应该使用对比鲜明的颜色

为了让视力上有障碍的用户能分清哪些标签是已选中的,哪些是未选中的,应该使用高对比的背景色来做出区分。

Yahoo! News 网站中的反面案例:选中和未选中状态的标签 只有非常小的视觉上的差异,他们对视力好的用户没问题,但是会给视力不佳的用户带来麻烦。

Yahoo! News colors make it hard for low-vision users.

此外,请务必保证标签的文字颜色(前景色)和标签背景色 有充分的对比。即使是未选中的标签,用户也应该能轻松阅读上面的文字。为了让未选择的标签看起来不显眼,而把它们都直接变灰 是不妥当的。

确保 隐藏内容区里的信息 在语音阅读器中是可读的

基于可访问性,Tab应该使用技术将未选中状态的内容区隐藏起来,但是不能在DOM Tree中删除他们。比如不能使用 display:none; 或者 visibility:none这样的css参数去定义容器。这类参数导致语音阅读器无法读取被隐藏的内容区中的信息。

(译注:中国设计师可能不太重视语音阅读器的可访问性,但是在国外,有专门的法令条款规定,机构网站不得歧视有障碍的用户,包括视力缺陷,行动障碍、癫痫患者等,所以外国的产品或前端工程师会很重视这一点,不然会遭到投诉甚至起诉。这种差异去看看中国人是如何设计盲道的就明白了。)

详情请见Roger Johansson’s 的文章 《利用css隐藏内容:问题和对策》”Hiding with CSS: Problems and solutions“.

(译注:Roger Johansson’s的文章中指出:许多CSS和JS教程建议使用display:none; visibility:none 来隐藏元素,但大多数状况下这是一个会降低可访问性的选择,。

display:none的真正含义是表示这一元素并不存在,不需要显示打印或被阅读。大多数语音阅读器会忽略任何使用display:none来隐藏链接,文字,导航和标题等。作者建议使用的技术是使用绝对定位坐标,例如 .structural { position:absolute; left:-9999px; } 。

另一个需要注意的问题是,当你决定使用JS去显示一个元素时,也应该用JS技术去隐藏它。因为考虑到客户端是否支持js以及安全等级,如果客户端的js没起作用,可能交互或动态菜单没效果,但起码内容是可访问的。但如果你使用css去隐藏一个元素,但使用js技术去显示它,在某些状况下,这个元素会变得一直无法访问。)

使用语义化的HTML结构来构造 Tab的标签。

使用无序或有序列表(译注:<ul> <li>这类标签)来构造标签的html代码,可以改善可访问性。因为使用语音阅读器的用户可以基于此来识别出这是一组Tab标签。如果标签上使用了图片来代替文字,别忘了添加ALT 或 title属性来 描述图片的含义。

允许键盘操作。

键盘导航是为一些有行动障碍或不能使用常规输入设备(如鼠标)的用户准备的。这种用户会使用替换形式(比如键盘或语音)来控制导航菜单,确保他们能将控制焦点在标签间切换,并激活他们想要的部分。

一个简单测试键盘导航的简单方法是:使用键盘上的Tab键,看你是否能将控制焦点 集中在每个标签上?使用回车键,当前的控制区域是否能被激活,使未选中状态有效地切换为选中状态。

提高对用户客户端的兼容性。

当客户端无法支持某些技术,比如当浏览器关闭了JavaScript功能时,或者 当用户没有安装Flash插件时,Tab内容区上的信息必须保证最基本的可访问性,交互元素确保能被替换为最基本的html文本。

四。 提升之道。

在提供了一些基本的可用性建议和原则后,我们还可以讨论一些方法来进一步提高Tab元素的可用性。

在标签上使用icon来形象化地描述内容区说包含的信息。

在标签上配合使用形象的icon,可以增强对内容区信息的描述。

例如在网站 DrawIt 中,图标用于形象地补充说明所对应的内容区的功能。

DrawIt uses icons in tab control text.

在标签上使用icon,必须保证它们是形象的,切题的。使用不相关的icon会适得其反。

避免在标签上直接用icon来代替文字。

不同的人对一个图像有不同的解读,最安全的方法是使用加上文本来描述内容区信息。

在内容区切换的时候使用过渡动画。

在内容区切换的时候使用过渡转场动画是一个不错的选择,可以为用户提供积极的视觉反馈——内容区正在变化!

大家可以去网站 Coda ,从左到右点击Tab标签,欣赏切换时的效果。

Coda uses animation to switch panes.

当用户在Tab的标签区进行操作时,有明确的悬停响应。

默认情况下,当用户将鼠标移到超链接或标签区域上时,鼠标指针的样式会发生改变,让用户知道标签区域是可点击的。

除此之外,还可以利用背景色变化来响应用户的鼠标操作。对于那些不熟悉Tab标签操作的网站新用户而言,这是很有用的。

下图中Vyniknite.sk 网站的案例里:当用户鼠标划过未选中状态的标签,背景色会变成鲜明的红色。

Vyniknite dot s k uses red highlights for hovers.

五。Tab的真实应用

现在为止,我们从细节上探讨了Tab这种交互元素,是时候来看看真实案例了,在这一章节,我们分析一些Tab元素的应用,希望可以带给大家灵感。

Haveamint.com

这个网站在首屏位置使用大量Tab元素 以展现数量庞大的信息。

Mint module tabs screen shot.

Yahoo!

雅虎在头版位置使用Tab设计,对信息内容的显示进行了压缩和模块化。

Yahoo! module tabs screen shot.

iGoogle

Igoogle在模块中大量使用了Tab,不占用大量的屏幕空间,又令信息饱满。

iGoogle module tabs screen shot.

Blue Acorn

蓝橡果网站 利用Tab来显示网站的热门文章: 电子商务和Magento(一个电商软件平台),内容区上还放置着引导用户浏览更多文章列表的按钮。

Blue Acorn module tabs screen shot.

MailChimp

在这个案例中,你可以看到利用图标强化标签文字描述的应用。

MailChimp module tabs screen shot.

WebNotes

WebNotes 网站的Tab元素,标签位于内容区下方,令人耳目一新。内容区切换时有淡入淡出的动画。

WebNotes module tabs screen shot.

WorldCat.org

WordCat.org 在搜索框中使用了Tab标签,让用户可以针对特定搜索需求缩小搜索范围。(比如书籍、DVD、或者文章)

WorldCat dot org module tabs screen shot.

Martha Stewart

Martha Stewart 在网站的“推荐内容”上应用用了Tab设计,可以自动播放和带有过渡动画。

Martha Stewart module tabs screen shot.

Krista’s Creations

Krista’s Creations 利用字母表作为标签来控制图片的分类显示。

Krista's creation module tabs screen shot.

Clearspring

Clearspring 拥有响应速度极快的Tab,这是一个非常好的古典样式的Tab设计案例。

Clearspring module tabs screen shot.

Homewood

在网站Homewood中,它们也利用icon来辅助了标签上文字的表述。

Homewood module tabs screen shot.

Apple – iWork

苹果网站里,垂直方向排列的Tab标签设计,非常漂亮。

Apply iwork module tabs screen shot.

ExpressionEngine

网站 ExpressionEngine 把标签控制区放在Tab窗体的底部,在快速载入内容区和快速响应内容区切换方面,它也是一个典型案例。

ExpressionEngine  module tabs screen shot.

Viget Inspire

Viget Inspire 在“热门文章”版块使用了Tab,有淡入淡出的切换动画,内容区高度可根据内容长度自适应。

Viget Inspire module tabs screen shot.

Komodo Media

Komodo Media 的标签里,icon放在文字上方。

Komodo Media module tabs screen shot.

atebits

atebits presents 用Tab来展示产品介绍,它有效地在这么小的空间里展现了如此丰富的内容。

atebits module tabs screen shot.

Tumblon

Tumblon 把标签放置在内容区下方,能快速响应切换,但不好的是,标签的选中状态和未选中状态不是那么容易区分。

Tumblon module tabs screen shot.

kevadamson.com

在 Kev Adamson的网站中,右边栏里有好几个Tab,网站使用了不同的ICON配图,帮助用户理解不同Tab的功能。

kev adamson dot com module tabs screen shot.

六。 Tab的创建教程(前端方面的)

有很多教程能告诉你在页面上如何建立和实现一个Tab,下面,你可以通过一些顶尖教程来了解更多关于创建Tab的技巧。

Building Tabbed Content 《如何创建Tab》

通过阅读这篇初级教程,你可以了解如何通过使用 JS 框架Prototype创建一个简单的Tab元素,

Building Tabbed Content Demo screen shot.

Create A Tabbed Interface Using jQuery 《使用jQuery来创建Tab》

Dan Harper 提供给读者关于如何使用jQuery库(译注:著名的js库)来构建Tab。

Create A Tabbed Interface Using jQuery demo screen shot.

Accessible Image-Tab Rollovers 《图片标签导航的快速切换》

学习如何实现用图片来制作标签导航区,并实现快速切换

Accessible Image-Tab Rollovers demos screen shot.

Create a Slick Tabbed Content Area using CSS & jQuery 《使用CSS和jQuery来实现一个可平滑切换的Tab》

Create a Slick Tabbed Content Area using CSS & jQuery screen shot.

七 。脚本资源

如果你真正查找能直接在你网站上应用的Tab脚本代码,这有一些免费的解决方案。

DOMTab

DomTab 是一个很受欢迎的脚本,能很容易创建一个Tab元素,把普通的链接列表改造为Tab元素。

DOMTab screen shot.

JavaScript Tabifier

这段由BarelyFitz 设计的即插即用 的 JavaScript代码,能够帮助你在个人网站上更快速实现Tab元素。

JavaScript Tabifier screen shot.

TabView

TabView 是yahoo用户界面库(YUI)里的一个元件,你可以利用这个元件来减化代码量和图片的使用。

TabView screen shot.

Coda-Slider

Coda-Slider 是Coda 设计的Tab实现脚本,可以实现内容区切换的转场动画效果,还可以设置将Tab标签处理为靠左对齐或靠右对齐。

Coda-Slider screen shot.

idTabs

idTabs 是 jQuery 的一个简化插件,其强大的设置功能可以简化原来控件中复杂的参数组合。

idTabs screen shot.

Tabtastic

idTabs是一个JavaScript库,也包含创建Tab工具,这有深入浅出的使用教程Step by Step pane

Tabtastic screen shot.

Ajax Tabs Content

动态和远程数据,你可以使用AJAX这种动态驱动的方法,来异步更新内容区里的信息。

Ajax Tabs Content

Carousel – Module Tabs

这段Tab脚本简单但有高度自定义的空间,支持动画与自动播放。

Carousel - Module Tabs

关于原作者

Jacob Gube 是一个JS和PHP工程师、WEB设计师、作家,Six Revision的创始人及总编。Six Revision是一个在线共享专业的开发与设计资源及教程的平台。这是他的Twitter:follow him on Twitter

cc

如何搞定站内搜索的产品设计及应用(上)http://blog.xiqiao.info/2009/06/02/343

如何搞定站内搜索的产品设计及应用(中)http://blog.xiqiao.info/2009/06/03/357

如何搞定站内搜索的产品设计及应用(下)http://blog.xiqiao.info/2009/06/19/388

六 站内搜索的开发

我写下面的关于站内搜索的开发,是尽量用浅显的语言来解释开发原理和程序请求的流程,主要给非专业的技术人员看。

搞产品应该懂得起码的开发原理,不要浮于专有词汇的表面。况且了解原理这事只要破除迷信,多读点真东西,一点都不难,也没有什么所谓的学科门槛之类的。我很想写一篇《搞产品应该懂的数据库命令》,来破除下非技术人员的代码恐惧症。

站内搜索的技术流程是:

  • 第一步 提取原料:抓取网站页面或格式化数据
  • 第二步 把原料归类:建立索引,把关键字和页面一一对应上,分类放好(想象一下老式图书馆里的归档管理方法就能形象理解索引了)
  • 第三步 听用户要上啥菜:响应用户的搜索需要,对用户输入的关键词进行分解,从索引中找到符合该关键词的所有相关网页。
  • 第四步  摆盘上桌:对搜索结果页面进行排序,将页面标题、url、摘要等信息呈现给用户。

一步步细说:

第一步:提取原料:抓取网站页面或格式化数据。

抓取页面是使用一种叫蜘蛛的程序,一个网站中成千上万个页面是通过什么关联起来的?url。蜘蛛就是通过一个页面的url找到另一个页面再找到另一个页面,把所有能链到的页面遍历一边,记录下来。

通用搜索引擎(google baidu)的蜘蛛 很复杂,因为一个页面上可能有很多个url,每个url又关联着无数页面,整个网络像一棵树,假设首页是第一层,首页上的url关联的页面是第二层,第二层页面上url关联的页面是第三层……

蜘蛛抓取的顺序就会很重要,是沿着一个url一直爬下去,还是先爬完一层再爬一层;加密或需要用户登录后才能访问的内容怎么抓取;pdf、rar及多媒体文件怎么抓取,都有讲究。不同的抓取处理在有效性、效率和对 被爬网站的资源占用 上有很大差异。

当然站内搜索没有那么麻烦,一般是技术人员根据希望被纳入搜索的内容数据库 生成一份格式化的 xml文档,让蜘蛛直接抓取就行了。但是站内搜索在提抓取页面更新索引时,有一个指标比较高,那就是抓取的更新频率。

比如对于电商类网站,某些商品,特价、抢货啦,可能刚发布出来5分钟就卖完了,或者改价格了。但是用户听说促销啦,来网站上一搜,搜不到,或者搜到了点进去发现价格不对,用户就会不舒服。 这就是蜘蛛抓取页面的更新频率过低导致的。要解决这个问题并平衡性能与资源占用之间的矛盾,需要多种算法组合优化。

通用搜索 比如google、twitter在做这方面的努力,也就是做成实时搜索。但是站内搜索服务还鲜有尝试者,霍炬余晟最近在做针对电商类的优化。目前可以做到即时更新,也就是发布后1分钟内就可以被搜索到。

第二步:把原料归类:建立索引。

建立索引这一步 集中了搜索引擎 的两大核心技术难点:索引结构和中文分词

如果按照正常人的思维,索引应该是这样建立的:

  • 把每篇文章存在文章索引表里(假定我们叫它doc索引),然后解析出该文章中有多少关键字,把关键字存在一个表里(我们叫它keyword索引)
  • doc索引的大致结构就是:docID  | doc标题/内容 | doc的url及其它信息 | doc中每个keywordID 。
  • 当用户输入关键字搜索的时,先找到关键字对应的keywordID, 然后查找到有哪些doc里包含做这个keywordID。

这种思路很符合逻辑,但是不好意思,在效率上几乎是不可行的。

因为在查找哪些doc里包含这个keyword的过程相当于 哗哗哗狂翻一本书来找里面的一个词。网站的doc索引条目动辄上万上十万,要是同时查找多个关键字,相当于多次狂翻一本十几万页的书,你说是不是累死了。

于是 就有一种更符合 程序运行方式的 索引建立方法。这就是倒排索引,也叫反向索引。 而上文中提到的符合正常人思维的叫正排索引

倒排索引中“倒”的含义是指把doc索引和keyword索引的关联次序颠倒过来。在建立索引的时候,先建一张keyword表,结构是:“keywordID  | 关键字 | 存在哪篇doc中的哪个地方 ”

“存在哪篇doc中的哪个地方” 这个信息怎么表示?

通过一种叫映射的方法。通俗地举例:“北京”这个词出现在 id为0011文章的第2段第5行第3个字,可以表达为一个字符串 0010p2l5f3,所以“北京”这个词在keyword表里是可能这样写

“ k001 | 北京 | 0010p2l5f3 , 0010p5l1f9, 0012p1l2f6……”

这是一个平面的结构,实际程序中当然不会这么简单处理,这样效率还是太低。会处理成一个有层次的结构,比如第一层只存docID  “k001 | 北京 | 0010,0010,0012……” ,第二层再存是属于哪一段哪一行等。

这样做的好处是 可以在第一层实现一次归并。因为搜索结果页面最先需要列出的只是那篇文章里包含哪个关键字,不需要具体位置,所以,当北京这个词在0010文章中多次时,第一层索引可以归并为为 “北京| 0010,0012 “ 这样结构又精简了。

索引的结构及存储方法对 搜索速度起致命的影响。

分词: 中文分词技术是中日韩语专属的一个的高难度课题,研究了十几年了。而英文每个单词之间都有空格,没这个麻烦。

比如 “作家长平时常翻阅这本书” 这句话 人可以识别“ 作家 长平 时常 翻阅 这本 书”。但是计算机可能就分成了“ 作 家长 平时 常 翻阅 这本 书”。计算机不认得“长平’ 这个人名,导致分词错误,用户搜索长平的时候就得不到这条结果。

再例如,当用户输入 “和服”搜索时,出来第一屏都是 “产品和服务”,“化妆和服装自己搞定”,用户是不是很郁闷。

所以分词技术 对于 搜索的准确有效性 起关键作用。

基础的分词方法是机械切分,也叫二元切分。以2个字为一个单位进行切分,不进行判断,比如 中华人民共和国 -> 中华 华人 人民 民共 共和 和国

在此基础上进化出了双向最大切分,就是把一句话切成最小词单元,正向切分一次,再反向切分一次,比较下哪个更合理,再通过复杂算法识别出有效关键字。

更先进的方法是在机械切分的基础上使用合理的词库,地名、品牌名、机构、简称等需要词库。而不同行业如金融类、计算机类、商品类都有不同的专业词库。

还有基于人工智能和统计概率的分词算法,但是对于站内搜索这个量级的都不适用。

对于站内搜索而且,除了好的分词算法,更重要的是词库添加和统计功能。网站管理员可以根据用户搜索行为的统计分析 手动向词库内添加新词。

第三步:听用户要上啥菜:响应用户的搜索需要

  • 用户输入的搜索条件可能是一句话,所以对用户搜索请求的解析也要用到分词技术。如果搜 “吉野家沙拉” 和 “吉野家 沙拉” 会得出不一样的搜索结果,就是比较差的搜索引擎了。
  • 用户输入的关键字是对词库的有利补充。比如搜全聚德的人多了,全聚德显然是一个有效的专业词汇。
  • 多个搜索关键字之间存在逻辑运算关系。逻辑运算。。不要怕,搞设计的人应该都知道布尔运算。。不知道?总知道反选、多选、选区交集吧。这就是逻辑运算中 非运算(not)、  或运算(or)、 与运算(and)

用户的搜索条件是“美国 金融危机”如果采用 或运算,则文章中只要包含了 美国 或 金融危机 这两个词中的一个,都有可能被列为搜索结果。 如果采用 与运算,则只有同时包含了 美国 和金融危机这两个词的文章 采会被列进搜索结果。

所有搜索引擎都应该在输入搜索条件时,支持逻辑运算符。

对于通用搜索引擎,一般 多个关键词之间的空格 就默认代表了是 与运算(and) 的关系。可以通过输入逻辑运算符 来完成其它搜索需求。比如 可以使用 “哈希 or Hash” 来搜索更多关于哈希算法的信息中英文都有, 也可以使用 “小李飞刀—电视剧” (减号)来搜索除电视剧外的小李飞刀的信息。

对于站内搜索,1 没有通用搜索那么大的数据量 2 比搜索引擎专业性更强。所以站内搜索 多个关键字之间的空格 默认代表的是 或运算 的关系。但是会在呈现结果的排序上做文章,通过多种算法计算出相关性最高的文章排在前面,相关性弱的排在后面。这样可以帮助用户发掘到更多 关联性内容,结果呈现也更人性化。这是通常定义下的 站内全文检索 的一个重要特征。也是区别于数据库搜索的技术优势。

响应用户搜索条件的时候 还有字段匹配及权重的问题,一篇doc 可能有标题、摘要、正文、tag、作者等多字段信息存在doc索引库里。Keyword是出现在标题、摘要还是正文中时,权重是不一样的。

第四步 摆盘上桌:对搜索结果页面进行排序,

琢磨过SEO的同学一定知道,所谓搜索引擎优化 1是让蜘蛛能抓取自己网站上更多的页面2 让自己网站的页面在搜索结果里能排得更靠前。

这就要研究搜索引擎的排序算法。对于各个通用搜索引擎,排序算法是许多人的关注核心,每次权重调整都会带来巨大震荡。通用搜索引擎都是在基于相关性排序上在加上各自的算法,如Google的专利pagerank就是通过页面之间的互链来判断页面的价值高低,再加上链接引用页面的PR值、是否在一个分类等 各种其它指标。

但是站内搜索,用互链这种方式来判定显然不靠谱,所以主要还是通过优化相关性的算法,计算keyword和DOC之间的关系,例如 keyword 在doc中出现的密度,词频, doc是否和 keyword 属于同一语义类别,doc的长度属性(短的doc应该降权之类的)等判定 keyword的搜索结果中,哪些doc更重要更有价值。

多个关键字的搜索条件,让算法更复杂,如何对多个关键字进行比较、两者的结果如何合并,两者的结果顺序如何穿插重排。

最后还要利用算法来优化 结果排序的速度和稳定性

由此 才能得到站内搜索的相关度排序结果。

————————————————————————————

上面基本讲了站内搜索的原理,看到这会有很多人觉得站内搜索的开发是一个技术要求很高的应用。也的确是这样,一般网站很难养得起一批能开发搜索引擎的工程师,开发周期上也承担不起,关键也缺乏持续改造的动力。产品设计人员也很难想在这个重要应用上有所发挥,对产品进行一点优化和改造都会牵扯到巨大的开发工作量和成本压力。

搜索引擎核心和分词 现在有一些开源代码或开源词库可以使用,也可以选择租用成熟的站内搜索服务来解决开发问题。使用SAAS (软件即服务模式,现在一种流行的技术外包服务模式) 的优势在于可以根据网站的去业务逻辑定制搜索模式,且搜索这部分的数据结构是单独建立重新格式化过的,对站内搜索进行产品改造不会对网站本身的业务逻辑和数据结构造成任何影响。也可以不占精力成本地享受产品改造技术升级的好处。

如何搞定站内搜索的产品设计及应用(上)http://blog.xiqiao.info/2009/06/02/343

如何搞定站内搜索的产品设计及应用(中)http://blog.xiqiao.info/2009/06/03/357

五、站内搜索的其它应用

1. 流量引导

针对站内搜索本身,流量引导的主要方式是关联、推荐和热榜。

  • 关联: 包括搜索结果关联、关键字关联 和推荐内容的关联。如,关注该关键字的用户还搜索过,买了此类宝贝的用户还买过
  • 推荐:根据用户搜索的需求分类 推荐相关的网站内容或商品。
  • 热榜:热门关键字排行,或上升快的热门关键字排行。

2. 特殊情况的设计:

当用户的搜索行为无搜索结果时、用户的搜索行为有输入错误或障碍、搜索结果过少时。

由用户行为造成的无结果或少结果,有下列几种状况:

  • 用户拼写错误。
  • 用户输入了限制过多的关键字条件
  • 用户误操作。

处理上述状况,首先应该由程序判断是否存在输入的拼写错误,在搜索结果之前首先提供纠错建议,提示和引导用户进行有效的操作,并根据数据挖掘,提供能满足用户搜索需求的有效关键字。如:“没有找到相关结果,不如试试搜索****。”等。

如用户输入了过多的关键字条件,(如用户直接在搜索框里粘贴了一句很长的话,且搜索设置为多关键字之间的匹配关系是与运算)应建议用户使用正确的条件输入方式。

误操作的状况多出现与用户直接点击了搜索按钮而没有输入关键字。这种状况不同网站有不同处理。如页面刷新、跳转到搜索结果页面但提示误操作、blank跳转到目录或索引页面、js弹窗提示误操作等。

非用户行为造成的无结果或少结果,有下列几种状况:

  • 分词错误:例如人名、专有名词、地名等专业词汇被错误地分词,造成有效结果不多。
  • 无有效数据

上述状况都应该在搜索功能的管理设置中有所反映,必须有手工补充关键词库的功能。必须能对少结果或无结果的关键词进行数据统计,以帮助决策内容维护方向。

另一种状况是当搜索结果过多时:用户输入了一个涵盖范围太广的关键字,搜索结果多于20页的时候。

宽泛的关键字定义不能帮助用户有效完成搜索目的,用户翻20页以上去检索的可能性很小,对网站性能也会造成不必要的浪费。

所以在搜索结果页面提供分类和筛选是首要前提,也应该在适当的位置体现用户使用关键字组合的正确方法或使用分类、筛选功能。

在分页设置上,可以以只显示20页为一个区间。

3. 内容价值的优化处理

在论坛、知道、百科之类应用中,设计者比较不愿意看见的一个状况就是问题和条目的重复,既浪费资源、分流用户贡献的有价值内容,也不利于信息组构。(流量膜拜主义的不在此列)

这类应用中,可在用户提问、发帖的title输入框旁边放置搜索提示或搜索框,引导用户在提问之前先搜索。

这个类应用可以通过搜索功能对内容价值进行优化。

4. 海量信息或历史内容的价值最大化

对于新闻、资讯、论坛站这类海量信息站而言,信息结构的设计是极为重要的,仅将内容价值建立在热门话题和更新速度上,是一种不明智和浪费的运维思路。好的信息结构设计,让用户不会在扫完热门和更新内容后就无事可做,降低用户跳出率、提高单ip的页面浏览数。设计思路除了明晰合理的多级信息目录结构,还应该根据运营需求建立起 话题眼、新闻脉络、信息时间轴 等内容聚合点和内容聚合线索。

搜索和数据挖掘是帮助优化此类设计的重要选择。

百度贴吧的伟大之处在于极大地发挥了由搜索关键字创建话题眼这一设计。

说到这,可能有人已经联想到了 tag 埋在正文中的关键字链接

对于论坛 或 非正规的信息站而言,通过tag来支撑一套信息维度是不现实的。

而正文中埋链接,多用于 产品库(名人库)这类专有词,主要用于导流量,在文中高密度使用也是不现实的。

所以使用分词技术或词频分析,在某篇文章中获取核心关键字后,在侧栏或标题/正文下方列出,是一个很好的处理方法。这种流量引导方式比“相关新闻”赋予用户更大的选择性,也更利于用户深度挖掘内容发现内容。

通过处理发布时间排序,可以形成以时间为脉络 新闻线索。

银杏搜索和我曾经提出一个概念产品设计,用于大型新闻/资讯网站的新闻搜索,让新闻关键字成为一个信息时间轴。

这个产品可根据某个关键字的搜索结果在时间轴上的分布,按时间区间输出搜索结果量的指数图,体现出到该关键字的新闻性时间趋势。

当鼠标移上某个节点,会显示该节点的日期和详细结果数。

用户可以通过点击年份,放大趋势图,查看某年的搜索结果的详细指数图。

这个产品可以很容易通过时间体现新闻趋势,强化传播的时间维度上的表现力,用户体验新鲜,更重要的是可以利用埋藏着的历史信息实现价值最大化。

这个应用还可以扩展为更高端的趋势比较。当用户输入2个以上的关键字时,可以在指数图中看见两个关键字的对比折线图,用户可以对两者搜索结果在时间分布上进行趋势比较。

5. 应用于内容发布系统

站内搜索除了在前端使用,在信息发布系统中也有重要的应用。典型例子的是帮助使用者筛选相关新闻(包括专题组织中的相关新闻列表)。

我讲一个我遇到过的案例:传媒类网站的cms系统,最初的设计:使用者点击“查找相关新闻”按钮,blank弹出结果页面,搜索条件直接取值于文章title和tag,全文检索。但使用者总是对筛选出来的相关新闻不满意,觉得匹配度不够高。

例如

  • 当使用者 为 ********(上)查询相关新闻时,当然最希望出来的是*******(中)和*******(下),但是标题被分词以后,再加上tag,由于词频权重的原因,中和下篇可能并不是排在前头。
  • 当使用者为一篇标题里包含 美国银行 这个词的文章查询相关新闻时,排在前几位的可能和美国银行没关系,而是奥巴马竞选或中美外贸。这是因为美国银行会被分词,拆为美国和银行,出现美国或银行频度最高的文章会被排在最上面,如果美国和银行之间采取 或运算 的话,结果就更糟糕。
  • 经过沟通和分析使用者需求,我把一个“查找相关新闻”按钮,拆分成了3个按钮,以满足使用者不同的搜索意图。

    • 按钮1 “根据标题精确搜索”,用于查找系列文章,多个关键字之间采取 与运算,满足精确关联需求。
    • 按纽2 “根据作者搜索” 仅匹配作者字段,用于精确查找该作者写过的所有文章。
    • 按钮3“相关性搜索”,匹配title分词和tag,满足查找宽泛关联的需求。

    客户此后就满意了,几乎不再需要手工自定义搜索条件,提供了处理效率。

    这个案例的启示是:1 站内搜索的应用设计中,搜索条件提取、多关键字的处理、匹配字段的处理 这些设定的变化,能对搜索结果、应用效率造成巨大差异,好的应用坏的应用由细节中产生。2 通用化设计往往是最不易用的。

    如何搞定站内搜索的产品设计及应用(上)http://blog.xiqiao.info/2009/06/02/343

    三、不同类型网站的站内搜索应用特点

    站内搜索普遍意义上可以分为两类:内容搜索和比较搜索。特殊搜索(如地图搜索,)不在讨论之列。

    典型的内容搜索:新闻(资讯)、视频、图片、音乐、人、论坛(小组)、帖子。对于内容搜索,基于分词的全文搜索是主要应用,通过分词、概率等对数据进行筛选排序,得出匹配度高的搜索结果

    典型的比较搜索:购物、餐饮、旅游、租房。 分类、筛选、排序等功能更为重要。搜索结果和用户行为关联更大。有大量基于数据库的搜索。

    1. 内容(帖子、话题、博客)搜索 。

    内容搜索 产品原型

    • 主要应用: 相关度排序。
    • 引导流量:相关内容推荐
    • 布局特点:不需要过多的功能模块,比如高级搜索、二级分类、筛选和排序。而应该重点优化设计 搜索结果、关联搜索、结果类型分布。

    2. 新闻类搜索 最重要的是时效性

    • 主要应用: 更新时间+相关度排序。 为什么把新闻类搜索从内容搜索中单提出来说,因为新闻搜索的结果排序,更新时间要的优先级要高于相关度。如果不注意这一点,会出很严重的后果。
    • 引导流量:热门关键字,“你可能还对这些关键词感兴趣”
    • 布局特点:同内容类搜索。

    新闻类搜索还有一个高级应用,就是新闻关键字的趋势比较。一般网站可能没有这个开发实力和预算,只有成熟的SaaS才有可能提供类似的高级应用。

    3. 多媒体搜索 图片/相册/视频/音乐

    多媒体搜索 产品原型

    • 主要应用: 分词+过滤,因为许多图片的alt是直接使用文字标题,所以正确的分离出关键词很重要。

    图片常用的过滤包括:文件类型、图片尺寸、风格、图片色调。

    视频由于没有统一的描述协议,暂时也没有成熟的OCR技术,所有视频搜索主要基于tag,数据库分类和人工填写的描述。视频常用的过滤包括:分类、时长。

    音乐常用的过滤包括:文件类型、专辑、歌手、风格、语种、源状况

    • 布局特点:图片和视频类搜索由于结果的展现主要是缩略图,搜索结果区域的面积要尽可能大,建议使用全屏单栏设计。图片搜索需求的目的性很明确,除过滤外,没必要放置其它功能属性和关联搜索。

    多媒体基本都存在专辑或系列,专辑和系列是基于人工分类的更准确的检索方法,包含更大的信息量。应当通过精确匹配后,优先列在搜索结果中。

    4. 用户搜索:

    • 主要应用:高级搜索、重音或拼写纠错提示。
    • 引导流量:“搜索该词的用户还关注什么”,“你可能还对这些关键词感兴趣”

    对人的搜索应使用精确匹配,根据数据类型支持高级搜索选项的过滤,还有一些特殊的比如在线状况、活跃程度、信用等级等。
    对于人名应提供重音和拼写纠错提示。

    5. 消费搜索:

    消费类搜索在过类别属性的侧重点上有很大差异,购物搜索:价格、信用、热度。租房搜索:匹配度、地域、价格、其它属性。餐饮搜索:地域、菜系、热度、价格。旅游搜索:时效性、价格、折扣

    消费类搜索 产品原型

    • 主要应用: 多维度属性过滤,支持多种排序,多种搜索结果显示形式、搜索结果对比。
    • 引导流量:搜索结果(竞价推广),“搜索该词的用户还关注什么”,“你可能还对这些关键词感兴趣”,热门关键字、历史记录。
    • 布局特点:应该重点优化设计二级分类、筛选、排序等模块。

    一个消费搜索的产品设计是否成功?我觉得有一个衡量方法:看用户是否可以通过不打任何字,光用鼠标也能顺利完成检索需求。
    站内搜索的筛选设计

    四、高级搜索功能的设计

    分类、过滤、排序这3个是应用最普遍的高级搜索功能。

    分类:帮助用户逐层定位所需搜索范畴,一般通过罗列所有分类项的方式展现,可一级级展现多层列表。

    站内搜索的分类设计

    过滤:通过在搜索结果中排除某一维度中的某个或多个属性 来帮助用户剔除不需要的搜索结果。一般通过单选、多选、下拉菜单、选项卡、标尺等形式展现。

    排序:帮助用户按某一属性对搜索结果进行重新排序。

    1. 排序的设计

    排序看起来简单,但是有问题的设计确很多。

    • 不分正序倒序

      人均花费排序,不分正序倒序,那默认是从高到底,还是从低到高呢?右图是较好的设计

    • 使用排序按钮,但是表意不清,增加用户学习成本
      排序按钮的设计
      猜猜左图4个操作排序的按钮分别是什么意思?销量、价格、折扣、上架时间。(除了第二个,其它我打死也想不出来)
      右图是较好的设计
    • 未明示哪些选项可允许排序操作
      未明示哪些选项可允许排序操作
      这里面有些允许排序操作,有些不允许。用户在点击的时候都得小祈祷一下…
    • 排序和过滤功能混淆在一起
      排序和过滤功能混淆在一起

      图中有一堆看起来功能相似的下拉菜单,但里面有的是排序操作,有的过滤操作。排序操作不会减少搜索结果,但过滤操作会。用户点击完其中某个下拉菜单,可能页面中搜索结果就为空了,用户能搞清是自己干了什么导致的吗?

    • 默认排序是什么?
      正确的排序设计
      上图 排序下拉菜单的设计非常好,同时有下拉菜单和按钮,同时有文字说明和图示箭头,一目了然。
      但是谁能告诉我,默认排序是基于什么的排序?
      常规意义上默认排序是基于相关度的排序,是认为用户无法理解相关度这3个字吗?

    2. 过滤的设计不好用的过滤器

    分类和过滤是两个容易混淆的概念,最常见的错误是把分类 设计成了过滤,让产品反而很难用

    如右图:这只是多组看起来像过滤器的分类列表而已,用下拉菜单的设计形式来代替索引链接,用户品牌维度下:用户只能选择某一个品牌,匹数维度下:用户只能选择一个固定区段。

    一个真正的过滤器应该能允许用户在终于的信息维度上,自由取得或排除部分搜索结果。

    下面是两种功能的正确设计

    正确的站内搜索筛选功能设计

    另一个常见错误是使用错误的表现形式来破坏用户的筛选自由度

    单选模式的筛选功能

    如上图:如果我理想的出发时间是在8:00~10:00之间,使用这个过滤器,我就得搜索两次。

    而下图这两种都是不错的设计模式。

    自由划分区间的筛选功能

    当我搜一个酒店,只想去7天、如家、汉庭这几家,要求有免费宽带和餐厅。

    如果是品牌和设施这两个维度的筛选形式做成了下拉菜单、选项卡或单选框,就只能歇菜了。

    最好的设计是将搜索选项做成多选框,用户可以任意组合。
    排序和过滤功能混淆在一起

    如果搜索页面空间比较紧张,没有太多位置放置筛选过滤器,下面的设计也是一个办法。将排序和筛选结合起来。

    混合类搜索和筛选功能

    3 高级搜索:

    高级搜索是一个比较传统的应用,它的特点是给出了多个input框,指望用户通过在固定位置输入每个维度的关键字,来获取精准的搜索结果。

    问题是如果用户输错了一个地方,可能就得不到任何有效结果。

    下图的设计让用户很容易输错。

    不好用的高级搜索

    下面这个改进过的高级搜索要好用得多,除了减少用户动脑子想关键字的时间,动键盘打字的次数,关键是能是输入条件规范,不会出现用户的理解错误或输入格式错误。

    不好用的高级搜索



    Copyright © 2007–2013. All rights reserved.

    RSS Feed. powered by Wordpress a theme by Xiqiao.