必應詞典使用體驗及改進建議

必應詞典使用體驗及改進建議

1、發現的BUG

一、使用PC客戶端（版本號3.5.0），由於是第一次使用必應詞典，以前一直習慣用有道，有本身的生詞本，以xml格式保存，此次但願經過必應詞典把有道詞典舊有的生詞本中的內容同步到必應詞典當中來，結果發生了以下的事情：

選擇導入

點打開出現彈窗：

我以爲很納悶：都是xml格式的文件，爲何有道能正確打開並解析，而必應詞典卻不能夠呢？

我以爲必應詞典應該想辦法解決這樣一個兼容性問題，由於我以爲像我這樣從其餘平臺上遷移過來的用戶再也不少數，個人這樣一個用戶需求對他們來講也是常見的。

二、取詞功能在網頁上沒法正常工做

當我打開一個網頁，不管是英文的仍是中文的，不管我把鼠標指向某個文字或單詞多長的時間，沒有給我任何響應，只有把單詞選中，點擊上方的必應log，而後纔會翻譯，說明劃譯功能是正常的，並且測試在word裏能夠正常進行中英文的取詞互譯。

個人瀏覽器是chorme的，雖然與IE不是同一個內核，可是也不算小衆了吧，我以爲這點功能應該可以支持才行，否則弄個取詞功能又然並卵可很差。

又試了下把OCR強力取詞開了（表示這個名詞通常人實在不明白），可以在部分網頁取詞了，可是依賴於網頁的編輯格式，獨立性很差。

三、Android客戶端有一個bug直接致使程序崩潰，截圖以下：

點擊那個相似攝像的東西，而後：

直接崩潰了，這是個大bug，等於有一個功能不只無法使用，還會使軟件崩潰，這樣還要這個功能幹什麼？

四、翻譯常識性錯誤

我做爲一個籃球迷和湖人粉，試了試在必應詞典裏翻譯了一下科比，結果：

。。。看來必應詞典的開發團隊全是足球迷吧。

2、用戶體驗吐槽

一、爲何不能支持ctrl+F搜索文本內容？每次一查單詞下面一長串的東西，我想定點搜索文本內容，沒反應！如今大部分的文本編輯器、代碼編輯器甚至網頁瀏覽器都支持這一功能了，爲何不把這個功能加上？

二、搜索了單詞以後，爲何非要點擊一下單詞頁面，才能夠進行光標上下鍵翻頁？若是我是一個鍵盤控，那麼豈不是無法翻頁了？

3、同窗使用採訪

一、學英語是出於學習的須要，主要用來查詞的釋義和用法，還有就是用來翻譯長句子和練習下聽力。

二、拍照

三、用戶帶着本身的需求使用了必應詞典，基本能夠解決用戶的需求，軟件的單詞量略有不足，界面比較美觀，功能上可以涵蓋用戶的全部需求，翻譯長句的準確度不夠，這一點極大地影響了用戶體驗。

四、用戶對產品的改進意見就是取消「劃詞取義」（PC端）這個功能，他以爲這個功能很蛋疼，沒什麼大用，還總是擋着屏幕。

綜上，他對這款產品的評價是：通常。

4、項目開發時間估計

以Android上的必應詞典客戶端爲研究對象，共有七大功能：生詞本、背單詞、長句翻譯、語音翻譯、單詞挑戰、我愛說英語、必應電臺。其中，語音翻譯和長句翻譯涉及到人工智能方面的知識，鑑於我如今對該方向不甚瞭解，所以估計開發時間比較困難。因爲我查到了網上有開源的人工智能項目，爲了簡單起見，我如今假設自動翻譯和語音識別這兩個項目的核心代碼已經封裝成API能夠供必應詞典開發團隊直接調用，他們作的工做就是把這些功能在Android客戶端上實現。

我採起的計算模式以下：假設7人團隊，分工以下：1人總負責設計和測試，其他6人組成3個小隊，進行結對編程，其中一個小隊負責前端UI設計以及Andriod平臺的移植，另外兩個小隊一個負責生詞本、背單詞、單詞挑戰三個功能模塊，另一個小隊負責長句翻譯、語音翻譯、我愛說英語、必應電臺四個功能模塊。開發流程分爲需求分析、需求規格、設計規格、代碼開發、後期測試五個階段。

各階段預估時間：

一、需求分析：全團隊一塊兒參與，定出用戶所須要的這七大功能，鑑於有其餘相似軟件做爲參照，所以這一工做量不會很大，保守估計一個月能夠完成。

二、需求規格：由設計總負責牽頭，每一個團隊設計生成本身的需求規格，因爲這涉及到不少需求的細節，將很大程度上決定用戶體驗，所以須要投入較長的時間，期間可能會涉及到不少的爭論和修改，保守估計一個半月完成。

三、設計規格：這一階段要具體到每一個功能模塊由哪幾個函數來構成，每一個函數內部又要用什麼數據結構來實現。生詞本、背單詞和單詞挑戰核心是在後臺用數據庫來管理大量的單詞數據，至於這些單詞的來源，咱們假設有在線的開放的詞典能夠下載，免去本身建立單詞詞條的繁瑣過程，這個估計須要半個月；長句翻譯、語音翻譯、我愛說英語因爲有核心的人工智能部分有現成的API能夠調用，其餘的設計不會太困難，至於必應電臺，也沒有太多須要本身實現的東西，所以難度也不太大，半個月至一個月應該能夠實現。前端UI可能要多花些心思，由於一個界面是否友好可能須要一遍又一遍地修改，預估一個月定下方案。因爲三個團隊是同時工做，取時間最長的爲準，一個月完成。

四、代碼開發：預估整個軟件本身實現的代碼行數在10萬行左右。考慮到程序員都是大學本科畢業生，編碼能力在500行一天，因爲有結對加成因素，定在每團隊天天能夠完成800行代碼，所以該團隊天天可完成的代碼行數爲800*3+500 = 2900 行代碼，若是這樣算下來大約須要100000/2900 = 35天，再算上雙休和代碼修改，時間翻倍，也就是說，兩個月多一點能夠完成代碼開發。

五、後期測試：鑑於大學生的編程能力有限，所以初版的代碼bug必定會很是多，所以對於初版的軟件，指望不能定得太高，每一個模塊能夠基本實現功能便可，假設每一個模塊須要1000個測試用例，總共須要7000個測試用例，加上總體的測試用例，一共10000個測試用例，按天天能夠測試經過或者修復200個測試用例估計，大約須要50天，接近兩個月。

總計：1+1.5+1+2+2=7.5個月。

考慮到除了總設計人員，其餘人都沒有相似項目的開發經驗，取三分之一的浮動值，完成區間5~10個月。

5、軟件優劣分析

優勢：

一、很喜歡微軟作的界面， 比較簡單易用，把最經常使用的功能展示給了用戶，隱藏了那些不經常使用的功能，這點比其餘的相似軟件要作得更好。

二、沒有廣告，沒有彈窗！這個超級贊，特別是在看個五分鐘視頻都要先看兩分鐘廣告的時代，沒廣告已是個奇蹟了。（但也許是微軟太土豪，不在意這點廣告收入，主要在於推本身的產品）

缺點：

一、詞條比起有道詞典不夠豐富，自動翻譯的質量仍是很不盡人意。

針對以上的開發流程，我以爲團隊應該在前期的需求分析和設計上花更多的工夫，避免後期進行大的修改。鑑於此，我認爲應該進行大量的用戶調研。具體形式我認爲能夠採起高校內調查問卷的方式，這個方式省時省力，可是能得到很多的原始數據，有助於團隊對用戶習慣和用戶需求進行較準確的定位，幫助進行需求分析。

6、進一步改進建議

我以爲如今的詞典軟件的用戶黏性並非過高的一個緣由就是軟件的開發人員並無真正搞清楚哪些人對本身的軟件的依賴度最大？若是對於普通的用戶，只是偶爾查一下單詞，我很難被說服去專門下載一個查詞軟件，由於如今的搜索引擎徹底能夠替代這樣的功能，簡單而方便，又不佔用電腦的硬盤空間，拖慢運行速度。而對於專業的英語人員，他們寧肯去查專業的牛津大辭典，由於這樣獲得的解釋更可靠。

綜上，我認爲雖然該類軟件名義上是查詞型軟件，但真正的定位不該該放在詞典上，而應該面向一類特殊的用戶：有強烈的英語學習需求、而且但願能短期內得到迅速進步的人。這類人的特徵是：大學學生、家境比較優越、有出國意向、準備各種語言考試、正在新東方等英語培訓機構接受培訓。

如今市面上的大多數主流軟件只是針對這類用戶提供了背單詞的功能，而沒有一套專業的量身訂作的學習計劃。

所以，我對詞典軟件的定位是：對於普通用戶，查詞是必要需求，但不是殺手功能；對於迫切須要經過考級考試的用戶，爲他們提供學習計劃是殺手功能，能戳中其痛點。

這些人迫切但願本身的詞彙量能在幾個月內暴漲，但願本身可以很快聽懂原滋原味的英文對話，可以讀懂英文的專業文章，可以作大量的雅思託福GRE習題。爲何必應詞典不可以提供一個在線英語培訓功能，這個功能以下：經過一個簡單的測試，對被測試者的英文水平進行評估，制定一份詳細的學習計劃，當用戶選擇執行這樣一個計劃，須要繳納必定的押金，只有當完成學習並經過考試纔會退還，這樣能夠逼着用戶按照計劃學習，避免錢打了水漂。接着天天的計劃有：背多少個單詞，聽多少個對話，作多少道習題，還有按期看一些新東方老師的網上公開課，而且經過階段性測試來反饋學習進度。若是愈來愈多的大學生經過這個軟件實現了本身的出國夢，這個軟件的用戶才能真正多起來。

假設咱們的詞典已經發布了1.0版，也就是咱們已經可以實現基本的查詞、翻譯等功能，在2.0版，咱們要實現上述的爲用戶制定學習計劃的功能，爲此咱們須要作的有：

一、經過大量的調查採訪，與專業的英語培訓師溝通，可以對各個層次的用戶制定合理的學習計劃。

二、蒐集大量的各類考試的真題，由英語培訓師來負責進行審覈，挑選適合備考者學習的資料。

三、創建一套評估系統，評估用戶的學習進度。

四、與傳統的教育機構合做，取得教師公開課的播放版權。

五、爲每個用戶創建其數據庫。

六、界面設計和美工。

以上是2.0版主要的新增功能，其中三、五、6屬於技術方面的工做，由3我的負責；其他三項屬於商業運做方面的工做，由另外兩我的完成。

具體流程安排：

技術團隊：第一個月創建數據庫，第二個月創建評估系統，第三個月設計界面和美工。

商業團隊：第一個月獲得學習計劃的資料，第二個月蒐集近五年的考試真題，整理成電子版，第三個月和有關機構談判購買視頻資源。

最後一個月進行總的測試。