关于 微软必应词典客户端 的案例分析
【前言】
随着中国与国际接轨的不断深化，人们在工作、学习、生活中越来越多的要接触英语，在加上如今火热的智能市场的催化，人们需要一款优秀的软件来帮助人们查找生词以及学习英语。这样的软件除了基本的字典功能，还需要有生词本，多样化的记词方式（如词根、词性分类，按照诸如CET4、TOEFL、GRE、GMAT的考试分类），基于搜索引擎的翻译功能，例句补充，原声电台，原版社评等其他的辅助功能。
微软作为软件业的巨头对于这样一个市场肯定不会轻易放弃。必应搜索（Bing）也是世界上第二大搜索引擎，在这种基础上微软的必应词典想必不会令大家失望。
这次案例分析将比较两款词典类软件。分别是偏大众化的有道词典以及学习型的longman。
【测评】
0.测试平台：Ipad Air
1.综合体验
栋哥这次作业要我们找BUG，但是我自己用了一通下来并没有找到什么大BUG。不过找到了一些小问题，按照《构建之法》里的定义：软件的行为与用户的期望不一样即为BUG。这样的话也算是找到了，hhhhh。
（1）在这款软件中，用户可以登录Microsoft账户，将个人记录同步到Onedrive。在登陆账户后退出软件，再次打开想要同步数据的时候还需要再次登陆微软账号。
(2) 当在浏览网页或者ebook时，看到生词可以通过copy获得语意，语意将在弹窗上显示。而现在这个功能并不能实现。
（3）当点击了单词挑战，如选择”四级词汇“，这时候我并没有去完成这个挑战，而是点了左侧的其他栏目，等我再次点到单词挑战时，他的计时并没有因为我的切出而停止。
之所以会有这些个问题，应该这些都是小问题，大多数情况下人们并不会用到，开发者就没有太在意这个。而且并不是很多人拥有微软账号，更不用说使用其云服务来与OneNote等软件相关联。
2. 用户体验与调研
这次案列分析我采用的是深入面谈这个方式，让用户实际使用必应词典，探究用户在使用软件时有哪些困难，比如看用户怎样找到想要的单词，用户对软件给出的解释是否满意，界面是否流畅，是否简捷易上手，多次使用之后是越来越难用还是越来越好用等等问题。
（1）采访对象的背景和需求
| 姓名 | 杰克尤 |
| 性别，年龄 | 男，21 |
| 收入 | 学生，除1500生活费一般无收入 |
| 知识层次 | CET-4，单词量2000左右。 |
| 生活/工作情况 | 上课，学习，娱乐，健身 |
| 动机，目的，困难 | 在工作学习中需要阅读英语文献。困难：1.难以持之以恒地学习英语。 2.在阅读文章时有大量单词不认识，影响学习效率。 |
| 用户偏好 | 简捷方便的界面，流畅的操作，精确的语意。 |
| 用户比例 | 7成 |
| 典型场景 | 离线、在线服务皆可，能够查找单词、句子的意思，制定学习计划并执行。 |
| 典型描述 | 无。 |
(2) 用户正在使用必应词典
(3) 用户的实际使用体验
----界面简洁直观，操作流程，有足够的提示和反馈，满足软件的一致性标准，用户的错误操作可以回退。
----用户能够在搜索栏键入所查单词，在键入过程中软件会给出查询建议。如查询abnormal时，当打出abnor时，查询建议中就包括abormal,abnormality等以当前键入为前缀的词语，方便用户选择。但此时如果用户错误的将单词打成了 abnomal(正确的为abnormal，少了一个r),将无法查到，软件本身也没有提供所谓的模糊匹配。
----在查到单词后用户可以浏览其解释，例句，收听发音。但是音频服务需要联网，对于离线环境有些不足。
----”我爱说英语“的评分不做口语、书面语、广播语等的区分，更弱的方面则是仅仅通过重读和停顿来评分，忽视连读，缩略等方面。没有任何参考价值。
----“单词挑战”每做完一题，切换的过程不够流程，要等差不多1S才能切到下一题。
（4）用户建议
--在查询栏优化匹配。
--自带基础词源的离线包，同时用户可以根据自己的需要下载不同程度的离线包，如常用3000次，TOEFL词等等。
--“单词挑战”界面切换的流畅度提高。
--“我爱说英语”的评判要更合理。
（5）综合评价：一般
3. 分析
主界面：简洁直观，操作流程，有足够的提示和反馈，满足软件的一致性标准，用户的错误操作可以回退。
每日阅读：能够提供外文新闻，但是新闻的来源未必好，有些中媒的外文版在用词上有些欠妥。另外点击“每日阅读”是直接跳到XX新闻网而不是经过转码以适应该机器。影响用户阅读体验。
查找单词：1. 有一定程度的匹配，但不够完善。找到目标单词后能够浏览其解释，例句，收听发音，但是需要联网才能使用音频和相关资料的Bing查询。2.英英解释做的不够完善，没有词组，搭配等提供。
单词挑战：每做完一题，切换的过程不够流程，要等差不多1S才能切到下一题
我爱说英语：评分不做口语、书面语、广播语等的区分，更弱的方面则是仅仅通过重读和停顿来评分，忽视连读，缩略等方面。没有任何参考价值。
假设有6名应届CS毕业生和专业UI设计师
以下是很粗略的估计。
| 进行调研，明确概念，明确用户需求，进行业务建模 | 1周 |
| 需求分析， | 1周 |
| 实现分析与初步设计，包括初步架构设计、UI设计、测试计划。 | 2周 |
| 数据库设计 | 1周 |
| 编码实现，中间夹杂一定的复审，把可执行的系统搭建起来。 | 3周 |
| 用户测试反馈，项目完善 | 2周 |
| 测试，项目管理 | 1周 |
| 正式版本发布 | 1周 |
| 部署上线 | 1周 |
| 合计 | 13周 |
<横向比较>
在引文中我已经说了，在移动端，中国使用最多的词典是有道词典，同类型的多功能词典。另外还将比较longman，非常详尽的英英词典。
与网易有道词典的对比：
1. 界面上没有广告，用户不会觉得烦。如下图的有道词典的广告。
2. 查词时，有道提供了对所查单词更多的解释。
3. 功能上不如有道词典丰富。
4. 口语练习方面，有道词典的”口语大师”能够更好的帮助用户解决发音，停顿，重读，快慢等方面的问题。
5. 有道词典提供了云图书服务，可以在线阅读英文原版图书，有道词典会对书中的长难句，经典句子进行标记，用户也可以直接点击生词获得词义。
总结：必应词典有的功能，有道词典也有，必应没有的，有道还有。甚至在查词方面也不如有道完善。
与朗文（longman）词典对比
朗文的版本很多，这次对比的是我自己常用的一款，LDOCE 5
朗文是一款比较专业的英英词典，功能非常单一，只有词典功能。
1. 朗文词典非常大，一共要1.8G的存储空间，必应则是非常小。朗文词典是纯离线软件，蕴含了非常详尽的解释，词组，例句，发音。
2. 必应词典在用户浏览字典的时候可以根据CET-4/6,TOEFL,GMAT,GRE等进行分类。
总结：朗文更像是一个纸质字典，内容非常详尽（毕竟实体字典畅销全球），作为离线的英英词典，不会拥有其他基于建立在搜索引擎词典的解释不准确的问题。但是功能太过单一，是个小众化的应用，多用于英语学习者。必应的功能相比之下就丰富的多了，而且受众要广的多。作为一款免费软件，更容易得到别人的青睐（LDOCE 要35刀）。
第三部分：建议和规划
1. 在查词方面提高查词的便利性，模糊匹配，前缀匹配等做的更细致一些。同时提升屏幕取词解释功能，并能够使用于本机其他的杂志软件、电子书。
2. 在现有查词界面上添加专业释义，口语例句，书面语例句等功能，方便不同需要的用户来使用。
3. 引入权威词典，提高准确度。
4. 提高软件整体的流畅度，比如单词挑战，每做完一题，切换的过程不够流程，要等差不多1s才能切到下一题。
5. 口语测试、练习采用更科学的评判标准（实现起来难度感觉很大）。
6. 强化对电子书，电子杂志的支持，实现E阅读。
7. 与微软其他产品的关联，如OneNote,office系列，使其成为外语处理的平台，更方便用户使用，尤其是是Surface,WP的用户。
8. 单词复习功能，类似于简单的背单词软件。
9. 每日推送里加入歌曲（版权又是个大坑），趣谈等更多的内容，不应像现在这样只有一个名言和新闻。
在长句翻译方面，我使用的时候谷歌、百度和必应并没有什么明显差别，机器翻译的质量都不怎么样，这个方面的提升是比较困难的。
以上所提的建议，既可以满足普通用户日常查词的需求，也可以满足英语学习者的学习需求（口语练习，单词会议，原版英文阅读，英语的纪录片），以及高层次学习者的需求。
这些提议是综合了现有的专业词典和学习型词典软件，以及自己学英语的个人经验提出来的。如果说想要设计的东西，我觉得就是所提到的第5点，对现有的“我爱说英语”进行改进。
NABCD模型
| NEED | 用于想要提高自己的口语，即听说读写中的“说” |
| APPROACH | 用于可以选择是Oral还是Formal，然后加载一个模块，里面有原文（文章或对话），加载的模块中有音频先给予示范，然后用户再读，读后系统给予点评（评分）。 |
| BENEFICIAL | 不管是日常对话还是正式演说，不同的场景需要人们以不同的语气，停顿，重读来加强表现力，这正是口语的作用。通过这个功能自然能够教用户怎么说英语才够地道。 |
| COMPETITION | 市面上还没有这样的功能，做的好就有市场。 |
| DELIVERY | 抓住优势扩大宣传力度。 |
如果我的团队有5个人, 4个月的时间，作为项目经理，我将按照如下进行角色配置以及任务安排：
| 进行调研，明确概念，明确用户需求，进行业务建模 | 第1周 |
| 实现分析与初步设计，包括初步架构设计、UI设计、测试计划。 | 1-2周 |
| 数据库设计 | 2-3周 |
| 编码实现，中间夹杂一定的复审，把可执行的系统搭建起来。 | 3-7周 |
| 用户测试反馈，项目完善 | 7-8周 |
| 正式版本发布，部署上线 | 8-9周 |
