由产品开发方委托评估，并授权发表。原载于《程序员》杂志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 上不支持文本复制