一個例子

讓我們來假象一個場景：用戶正在使用一套類似“信息管理系統(tǒng)”的軟件，準備新增一條記錄，輸入完全部的數(shù)據(jù)后，軟件卻給出一條錯誤提示：

用戶可能此時已經(jīng)崩潰在屏幕前了，因為需要輸入的記錄可能有很多條，這意味著他不得不一項一項檢查數(shù)據(jù)。

但換一種場景：用戶同樣輸入完后，軟件給出提示：

同時，點擊確定后，光標自動跳轉(zhuǎn)到錯誤的地方，用戶只需輸入正確的信息就可以了。這樣避免了很多額外的工作量，省時省力。

人性化的提示信息

  在我們使用軟件時，經(jīng)常出現(xiàn)一些錯誤。這時程序可能只是簡單地提示“出錯啦！”，或者給出一大堆錯誤代碼。這經(jīng)常使初學者很茫然不知所措。如今，軟件正越來越朝著人性化的方向發(fā)展，如何實現(xiàn)人性化的語言提示，是軟件開發(fā)中一件至關(guān)重要的事。它不僅體現(xiàn)支持與服務(wù)的質(zhì)量、影響產(chǎn)品的銷量、更會表現(xiàn)出一家軟件公司的風格——我們對用戶有無微不至的關(guān)懷。

人性化提示的重要性不言而喻，它包括的內(nèi)容也很廣泛但要做到人性化提示并不是一件簡單的事情，它涉及到數(shù)據(jù)有效值分析、錯誤處理、異常拋出、層之間數(shù)據(jù)傳遞、程序執(zhí)行效率分析、人性化語言設(shè)計等眾多方面方面的內(nèi)容。

設(shè)計與要點

結(jié)合近期嘗試制作的“學生信息管理系統(tǒng)”，在程序人性化信息提示方面，我個人認為需要在開發(fā)時做到以下幾點：

第一，要有嚴格的數(shù)據(jù)檢查。這是人性化錯誤提示的基礎(chǔ)，連錯誤都發(fā)現(xiàn)不了，就提不上什么人性化錯誤提示了。首先，要搞清楚各種數(shù)據(jù)的合法條件；其次，在涉及到數(shù)據(jù)傳遞的每個類中加入常規(guī)檢查函數(shù)，保證程序的健壯性，需要特別注意邊界值上的問題；最后，一些特殊數(shù)據(jù)的特殊檢查函數(shù)，并選擇在合適的類中實現(xiàn)，如ID是否重復的檢查就應放在鏈表類中進行。

第二，設(shè)計錯誤信息的上拋機制。一旦檢查出錯誤，一定不能直接停止運行，而不管其他的事情。最簡單的檢查函數(shù)返回值會是bool類型，即檢查通過與不通過。顯然，這樣設(shè)計的函數(shù)無法提供更具體的信息，也就無法進行提示了。個人認為，除非是在UI層的單項檢查，否則最好設(shè)計返回值為int類型的函數(shù)，為了避免混亂，可以使用枚舉類型來用ERR_開頭的單詞代替數(shù)字。你也可以直接返回字符串類型的錯誤信息，但是這樣就會有大量的信息在各個層之間不斷上拋，會造成程序效率降低。當然，可能另一種更好的錯誤處理的方式是拋出異常，但對于我們初學者來說，還接觸不到這些知識。

第三，UI層的呈現(xiàn)方式。錯誤信息經(jīng)過層層上拋，終于到達了UI層，此時就要考慮如何去呈現(xiàn)給用戶了。一般來說，最常用的方式是彈出對話框，這樣做雖然簡單，但有時候也不免會出現(xiàn)這樣的情況——用戶面對點不完的對話框無語了。此時，個人認為有兩種處理方式：一種是將所有的錯誤信息整合后放在一個對話框中彈出，如開篇提到的第二種情景里的；另一種則是直接提示在原對話框上提示，如一般網(wǎng)站才用的方式——在錯誤的數(shù)據(jù)后打上*號。這兩種方式都有缺點，對于前者，如果錯誤的數(shù)據(jù)較多，很可能用戶點完確定就忘記哪些信息發(fā)現(xiàn)錯誤；對于后者，可能用戶不會在意到錯誤提示，而且，需要在窗口上添加很多控件。一種比較好的方法是綜合兩者的優(yōu)點——彈出錯誤信息，然后將錯誤信息整合在UI的ERROR_LIST中。還有一些類似網(wǎng)頁形式的提示信息如控件上的Popup Message等，但總體來說，在MFC中實現(xiàn)可能會比較難。

另外，提示文字的設(shè)計也是一門藝術(shù)，它會極大的影響到用戶的使用感受，但本文作為技術(shù)文檔就不涉及此方面的內(nèi)容了。

總結(jié)

要實現(xiàn)人性化的信息提示，需要考慮很多方面問題，雖然實現(xiàn)起來難度要比核心的設(shè)計要簡單得多，但這確實是軟件設(shè)計中一個很實際也很有挑戰(zhàn)性的問題，它牽涉到用戶的使用的方便性與易用性，也遵循了軟件開發(fā)與服務(wù)的根本——“客戶需求”。

這是我在這次中軟國際實訓中提交的技術(shù)文檔，各位老鳥看了不要笑，呵呵，歡迎大家評論！