关于 微软必应词典客户端 的案例分析

【第一部分】  调研，评测

一、用户采访

1)   介绍采访对象的背景和需求：

被采访同学是马来西亚华裔叶能端同学，由于此前在马来西亚英语是第二语言，因此经常需要使用字典查阅单词。

2)   让采访对象使用10-30分钟必应词典的功能（附上能端同学美照一张lol）

3)   描述用户使用这个产品的过程,  用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？

根据能端同学的原话：“在用的过程中，我在yahoo new选了一篇文章的一句话翻译了一下，结果是可想而知的失望。”

“这结果对一个学习过双语（中英）的人来说关键字都出现在内容，但词句排法错误造成翻译错误。

这UI不错，是我喜欢的简约风。在其他的应用我使用了感觉很智能的语音分析“我爱说英语”但是结果让我不敢相信，后来才发现每次测试前必须听已设置好的语音，然后照着他的“旋律”就能获得高分。
语音分析这东西有待加强。。”

“关于bug的发现在 taught，became这些irregular verb 的past tense 自动转跳到infinitive verb。虽然注明了“XXX 是XXX的过去式”，但是用的方式不一样。还有bin，这字和本拉登没太大关系。。。

在过程中发现该软件的名词在翻译句子的中英对照的准确率很高，但是形容词和助词方面不是很理想。”

4)   用户对产品有什么改进意见？

“改进的地方有点多，句子翻译时中英对照有些字对不上，还有前面说的那几个都是要改进的。

这软件解决了在没有网络的情况下可以查阅。”

二、软件的BUG、功能评测

 1）软件的BUG

 ① 功能BUG：例句中英对应出错

该BUG应该是测试中最明显也最严重的一个BUG，我强烈建议软件开发人员能够对这种BUG负责。

如图中所示，第一个例句“And he'll never be able to emerge from his bathos of coarseness and ignorance”，

此句中的bathos应该和trite一个意思，即为后面coarseness的paraphrase，而软件却将其和“那”这一明显意思不同的中文相联系。

在这里我可能查了较偏的文学词汇“bathos”，但是其它常用单词也经常出现这种情况。

尤其考虑到必应词典是一款学习工具，正因为它的职责才需要开发者不能误导使用者。

第二个例句中bathos明显对应中文释意中的“虚伪”，但软件却没有给出指示。

②功能BUG：OCR强力取词

开启了屏幕取词后，打开一篇pdf文档（图片格式），获取到的解释不准确。

测试时，鼠标停留在"those initial sentences later"附近，但程序却给了"and"的翻译。

可见OCR技术还需要进一步加强。

另外，在网上浏览一些带链接的图片时，将鼠标移至图片上的英文不会显示释义。

③软件本身UI错位

笔者测试环境为：win7旗舰版，出现了如上的UI错位问题。

④软件运行导致状态栏错位

该问题出现在打开Bing OCR强力取词的时候，在此之前状态栏排布一切正常。

当打开OCR取词后，状态栏开始错位。

结论：经过这么多工作，你一定有充分的理由给这个软件下一个评价：

经过一系列测试和调研，我对该软件的推荐程度是：一般

Bing比较适合日常生活中上网时查查生词，但绝对不是一个理想的英语学习软件。

第二部分 分析

(参考 8.6 节 对工作的估计， 和14.1 节 软件工程的质量)

1）使用此软件的所有功能（包括必应词典背单词, 单词挑战，口语练习等），联系第二部分的分析，估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）。 

在个人设想，若六个人这样分配：1人PM，3人为程序员（熟悉网络编程，其中两人需要承担架构师的工作，一人需要另外承担测试员的工作），2人UI（一人负责代码，一人负责美工设计）。

按照这样的设想，以及正常计算机大学毕业生的水平，对开发流程做如下规划：

1. 产品市场需求调研，功能调研与设计，可行性分析，团队职责划分，规范确立。 1.5week

2. 词典数据库整理，在线数据挖掘算法设计，对应UI框架设计。2weeks

3. 基础查词、查例句、翻译等功能的实现，UI框架代码实现，UI框架和后端代码的耦合。1.5week

4. 部分拓展功能，如：屏幕取词，OCR取词功能等的完成，对应UI框架设计及耦合。1.5week

5. 单机功能，必应生词本、必应背单词、必应电台（单机部分）的完成，对应UI设计及耦合。2weeks

6. 在线功能，完善必应电台，我爱说英语，对应UI设计与耦合。1.5week

7. 全部功能的整合，与后期测试。2weeks

根据上述估计，我设想中的开发周期是12weeks，约三个月左右。

2）分析这个软件目前的优劣（和类似软件相比）

就目前手头在用的我个人认为最好的一款词典软件——Lingoes，两者就如下几个方面进行对比：

此处故意不用有道比较，因为有道太渣，和它比较没有任何意义（曾把我写的文翻译成鬼话，为了保持对Bing的好感，我还未把这个文交给Bing翻译）

1. 核心功能：查词的准确性和全面性

在经过对一些日常常用单词的查取，普通的屏幕取词，图片清晰的OCR取词，Bing词典的表现都算十分不错。

但还是避免不了计算机技术在自然语言处理上的不足，如，查询assume这个单词。

我们将Bing的结果和最具权威的韦氏大学词典放在一起比较，即可发现Bing翻译的不够全面。

针对assume这个单词，Bing缺少了“穿衣(don)” 和神学(Theology)中的"assume to heaven"的意思

PS: Bing依赖于网络信息，而Lingoes的离线功能十分方便。

2. 可拓展性比较

在可拓展性这个方面，两者均有各自的利弊。

Lingoes采用的是词典数据库的方式，需要用户自行导入词库，但正因此它的可拓展性十分高。

而Bing采用的是自身词库（不可拓展），结合网络释义，虽然网络的力量之大可以轻易囊括所有信息，但是要从这些无数的信息中找到合适的并不容易。

因此Bing的拓展性会受到错误信息的限制。

3. 拓展功能比较

Bing词典有点让我非常喜欢，即它根据遗忘曲线科学定制的背单词功能（但还是受限于单词释义的不准确性，我不敢使用）

还有很多有趣的学单词功能，如词缀背单词，口语练习等。这些在Lingoes这款单调的软件上都没有。

同时，我也十分喜欢Bing的OCR图片取词功能。

虽然Bing和Lingoes都有屏幕取词、屏幕划词功能，但是Bing多了一个OCR取词让它一下子出彩不少。

3）推理出团队在软件工程方面可以提高的一个重要部分（具体建议）

从上述分析来看，团队对功能的基本实现都很到位，但是缺乏深入的市场调研，对面向的用户群体把握不是很准。

由于Bing词典的面世较晚，我甚至怀疑它只是对大部分现有词典的借鉴与拼凑。

就目前Bing词典的功能来看，它的查词功能差强人意，并非那么专业准确，但其拓展功能又是面向英语学习者的，这就使得软件的功能自相矛盾。

因此我建议Bing词典的开发团队需要重新审视这款软件的定位，它是仅着眼于日常需求或者专业需求，

还是全面（适合英语学习人士、专业英语从业者与日常用户需求）？

在定位好软件的受众后，可以考虑在团队中加入一些语言学家，虽然语言学家大多数情况下较为刁钻会对软件指出许多不满（深有体会。。语言学家就是种神奇的生物。。）

但若能够经受得住他们的考验，这个软件在专业性上就有了保障。

三、  建议和规划

(参考《构建之法》第8章 功能的定位和优先级；第9章 项目经理)

1. 这个软件有很多可以提高的部分，如果你是项目经理，如何提高从而在竞争中胜出？

作为项目经理用户需求分析和市场调研是必不可少的一环责任。为了履行好这一职责，我会将大部分时间花在市场调查上。

综合地域、教育水平、性格特征、学习目标等多种因素，通过各种因素的组合，进行市场问卷调查和软件试用，并收集反馈。

并以换位思考的方式将自己置于消费者角度进行思考。

2. 目前市场上有什么样的产品了？你要设计什么样的功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用 NABCD 分析。

根据百度软件排行版以及360软件管家两个用户群较大的评价机制得到的结果如下：

可见当前市面上的主要竞争对手是：1. 有道词典（微软认真做的话完全可以比它好不知多少倍吧。。鄙视有道。。） 2. 金山词霸（没用过，不予评论） 3. Lingoes（英语学习阶段强烈推荐）

综合身边同学使用词典的习惯而言，Bing词典完全可以在此基础上引入众多词典的数据库（如果需要收费，可以推出付费服务）。

除了网络释义和本身词库的意思外，必应需要多参考专业的解释，并引入一些特色功能，如引入每个单词的词源历史，每个单词的词根词缀，并根据同义反义关系，词源同宗关系构建知识图谱。

这一功能是当前任何一个软件都没有的！而经过实践证明，这种记忆和学习单词的方式比刷词汇或者Bing里的拓展功能单词本要高效得多！

举个简单的例子：assume = *ad- + *em-，其中*ad- = towards，*em-经过辅音化变成当前的词根sume-意为"拿取"，因此assume的意思可以理解为“向前把...拿取过来”。

经过这样的解释后再来看先前提过的assume所有词义，是不是都觉得能够解释得通也没那么难记了？

assume ：承担（即将责任拿过来）；采用（将采用的东西拿过来）；穿衣（将衣服拿过来披身上）；夺取（将别人的东西拿过来）；上任（将职权拿过来）；（神学）接入天国（将天国拿到自己面前）

除此之外，assume还能和同源词进行同族谱构建联系，如：presume, consume, resume, subsume，鉴于这是软工作业。。这些单词不再一一解释。。

做这一功能最重要的一点是根据我自身和其它同学的体验，发现了这种英语学习方式是很值得提倡的，但当前市面上完全没有此类软件能提供单词的图谱关系。

这导致背单词变成1-1的死板记忆过程，虽然这样可能能在短期内掌握一定量词汇，但远不如通过图谱在长期建立指数型爆炸数量的单词来得划算。

而用户选择我们的理由很简单，第一，我们在基础翻译部分并不比其它软件要差，希望按照常规学单词的用户可以放心选择。而希望尝试不同途径的，我们又有图谱记忆法，拓宽了用户选择范围。

根据NABCD模型：

N：解决的需求很明确，除了常规用户的需求外，提供了新型的学习方式供用户选择。

A：做法即和专业的语言学家合作，并且建立初期试用群体，做产品试用报告，并将结果用于宣传推广，进一步拓宽用户群。

B：提供了一种更高效，不再死记硬背的学习英语方式，并且在市面上任何其它软件上都找不到该功能。

C：就目前调研来看，该市场无人竞争。

D：通过初期用户试用，将其结果作为宣传材料。

3. 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？

人员分配：3人为程序员（其中两人需要承担架构师的工作，一人需要另外承担测试员的工作），2人UI（一人负责代码，一人负责美工设计）。

4. 描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件。

1. 产品市场需求调研，功能调研与设计，与语言学家建立合作关系。 2week

2. 词典数据库整理，与语言学家合作整理现有图谱关系；同时UI进行界面美工设计和开发。4weeks

3. 图谱知识库初具规模，进行图谱构建算法的研究；同时UI进行界面美工设计和开发；PM负责开始确定初期试用用户。4week

4. 开始具体实现算法，进行前后端的耦合。2week

5. 拓展功能，将图谱关系和在线功能相结合，增强用户间的交互性。2weeks

7. 全部功能的整合，与后期测试，发布软件并交给初期用户试用。2weeks