一個例子

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

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

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

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

人性化的提示信息

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

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

設計與要點

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

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

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

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

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

總結

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

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