我以前只知道有道詞典、金山詞霸，最近才知道還有“必應詞典”，對它的陌生不言自明。
這次著手分析“必應詞典”，先在360軟件寶庫下載最新版本——“微軟必應詞典 3.5.0”：

---

第一部分 調研，評測

評測：

bug1:UI界面不合理

【類別】【來源】【難度】【釋義】所對應的方框明顯太大了，以至于方框內的字顯得有些下沉，這不是一個“習慣思維中”正常的用戶界面。
當然，這也許就是UI設計師有意這么做的——但是，他們考慮過用戶的切實感受嗎？比如說——我自己就不太喜歡這樣的設計。

bug2:光標停滯

依舊是上面那幅圖，在點擊方框進行選擇的時候，會出現這么個現象——光標突然就動不了，持續大約1秒鐘,然后跳出下拉菜單，光標又可以移動了。
也就是說，這些小方框對于鼠標的響應不夠及時，正常來說，這些下拉菜單欄應該是即時的，但必應詞典卻沒有做到。

bug3:詞典自帶的“MSN今日熱點”的鏈接問題

上面分別點擊上圖所示兩條熱點，第一個熱點（天安門廣場花壇首次試燈）顯示如下：

所跳轉出的頁面和“天安門廣場花壇首次試燈”沒有一點關系

第二的熱點（“鋼鐵俠”帶100萬戰車相親）顯示如下：

即，鏈接是失效的

這反應了【MSN今日熱點】所推薦的消息的鏈接不一定存在。另外要吐槽的是，這些所謂的今日熱點都是很久以前的消息了，也就是說——
MSN很久沒更新過這些消息了。

---

為什么必應產品組的人沒有發現這些bug? 我覺得主要有三點：

1. 必應詞典不是微軟的主打產品，所以不會花費精力去修改bug;
2. 上述的這些bug并不會影響必應詞典的正常使用;
3. 軟件測試不夠充分。

---

采訪：

深入面談（In-depth Interview）——一對一的采訪

本次采訪對象是一名大三的計算機學生 呂，因為和代碼打交道、以及備考CET6的緣故，平時會經常用到詞典。

用戶使用過程：

呂在必應詞典的輸入框輸入“逆境”，界面跳出“adversity; adverse circumstances”兩個詞匯，都比較準確。
呂覺得“adverse circumstances”有意思，想進一步查看，于是點擊該詞組，發現只能查看一個單詞，即使用光標
選中了這個詞組，在點擊的時候也只能查看一個詞。

呂覺得很郁悶，只好復制黏貼進行查詢。
他想將“adverse circumstances”加入生詞本，但卻出現這個狀況：

【發音】【釋義】都沒有……而且不親自填寫其中任一個框，就不能添加到生詞本

無語ing。 然后輸入“LSP”（Liskov Substitution Principle的縮寫，屬于軟件工程的術語）界面跳出“標記交換路徑(Label
Switched Path)；光飽和點(light saturation point)；線譜對(Line Spectrum Pair)”，沒有想要的解釋。
呂笑著說，其實很多專業術語都比較難查到。
“那，接下來談談其他方面是使用吧？”
“好的。我另外用得較多的是‘必應背單詞’，里面的【記憶曲線】【詞頻瀏覽】等都很不錯。其他功能我用的不多。”
“是否解決了基本問題？”
“我用的功能不多，基本滿足需求”
“數據量、界面、功能、準確度都怎么樣”
“你看嘍，”他指著屏幕，“詞匯蠻豐富的，尤其是例句非常多，解釋得很詳細，所以——數據量很大——不過有時覺得有點繁雜。
界面嘛，就是有的地方不太美觀，不過整體界面設計的并不差。功能不必說了，很強大。準確度嘛，可以查得到的單詞一般都很準
確，有的查不到的，也沒辦法。”

附上迷之圖片：

結論：推薦!

---

第二部分 分析

疑問：估計這個項目做到這個程度大約需要多少時間?（團隊人數6人左右，計算機大學畢業生，并有專業UI 支持）

我的估計如下。

根據《構建之法》8.6節“計劃和估計”里面的一套經驗公式，實際花費時間往往大于估計，
并受到估計時間X和做過類似項目的次數N有關，前面提出X=36周，而N的次數的取值大概在
0-2次之間（取決于大學生自身的經驗），那么實際的耗時的取值區間應在[48,+∞]（單位：周）

優勢：

資源豐富，數據量相比同類軟件要多
名氣不錯，在中國和“有道”各有千秋
功能強大，且無雞肋，綜合性能勝過任何同類軟件

劣勢：

用戶界面的口碑不太好（就是設計的不好）
小bug挺多的，影響了用戶體驗

---

第三部分 建議和規劃

1. 軟件可以提高的部分：UI設計（包括響應時間）。

2. 目前市場上已有的同類產品：有道詞典、金山詞霸，以及名氣較小的——例如海詞詞典、靈格斯詞霸、百度詞典、QQ詞典等。

3. 如果我是PM，我想在“必應背單詞”里面添加可以準確表達單詞（某些詞義）的圖片，即，希望可以通過圖片來記憶單詞。
之所以要優化這個功能，是因為我曾用過用圖片記單詞的方法，效果不錯，值得嘗試。
我覺得用戶會用到這個功能的原因：圖形記憶更形象，效率更高，更有趣。

4. 如果我來領導這個團隊，會更加注重用戶的體驗，在用戶調查這一方面做足功課。

5. 如果我的團隊有5個人, 4個月的時間，作為項目經理，我會這樣配置角色：

前期所有人負責需求分析,寫spec；

中期2人負責文檔、美工等等，3人負責代碼編寫；

后期3人負責測試，2人負責修改。

6. 16周的規劃如下：

第一周 通過Wide-band Delphi形成大概的計劃和時間估算；進行需求分析；

第二周 完善需求，設計原型，統一編碼規范，做spec；

第三周 基本的UI設計，詞典后端開發。

第四周 完善UI設計，詞典后端開發。

第五周 翻譯功能的開發

第六周 生詞本的開發

第七周 背單詞功能的開發

第八周 電臺功能的開發

第九周 單詞挑戰的開發

第十周 口語練習的開發

十一周 功能整合

十二周 測試與修改

十三周 生成1.0版本，交給客戶使用，獲得反饋

十四周 基于反饋的修改與測試

十五周 正式版本完善，編寫、發布用戶手冊

十六周 正式版本發布

總結

以上是生活随笔為你收集整理的关于 微软必应词典客户端 的案例分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。