可用性設計
　　　　任何應用程序的可用性基本上由用戶決定。界面設計是需多次反復的過程；在為應用程序設計界面時，第一步就設計出非常完美的界面的情況非常少見。用戶參與設計過程越早，花的氣力越少，創建的界面越好、越可用。

　　　　什么是好的界面
　　　　設計用戶界面時，開始時最好是先看看Microsoft或其他公司的一些賣得很好的應用程序。畢竟，界面很差的應用程序不會賣得很好。將會發現許多通用的東西，比如：工具欄、狀態條、工具提示、上下文菜單以及標記對話框。VisualBasic具有把所有這些東西添加到應用程序中的能力，這并不偶然。
　　　　也可以憑借自己使用軟件的經驗。想一想曾經使用過的一些應用程序，哪些可以工作、哪些不可以以及如何修改它。但要記住個人的喜好不等于用戶的喜好，必須把自己的意見與用戶的意見一致起來。
　　　　還要注意到大多數成功的應用程序都提供選擇來適應不同的用戶的偏愛。例如，MicrosoftWindows“資源管理器”允許用戶通過菜單、鍵盤命令或者拖放來復制文件。提供選項會擴大應用程序的吸引力，至少應該使所有的功能都能被鼠標和鍵盤所訪問。

　　　　Windows界面準則
　　　　Windows操作系統的主要的優點就是為所有的應用程序提供了公用的界面。知道如何使用基于Windows的應用程序的用戶，很容易學會使用其他應用程序。而與已創建的界面準則相差太遠的應用程序不易讓人明了。
　　　　菜單就是這方面很好的例子——大多數基于Windows的應用程序都遵循這樣的標準：“文件”菜單在最左邊，然后是“編輯”、“工具”等可選的菜單，最右邊是“幫助”菜單。如果說Documents會比File更好，或者“幫助”菜單要放在最前，這就值得討論一下了。沒有任何事情阻止您這樣做，但這樣做會引起用戶的混淆，降低應用程序的可用性。每當在應用程序與其他程序之間切換時，用戶都不得不停下來想一想。
　　　　子菜單的位置也很重要。用戶本期望在“編輯”菜單下找到“復制”、“剪切”與“粘貼”等子菜單，若將它們移到“文件”菜單下會引起用戶的混亂。不要偏離已經創建的準則太遠，除非有很好的理由這樣做。

　　　　可用性的檢測
　　　　測試界面可用性的最好方法是在整個設計過程中請用戶參與。不論是正在設計大型的壓縮包應用程序，還是小型的有限使用的應用程序，設計的過程應當完全相同。使用已創建的設計準則，界面設計應從紙上開始。
　　　　下一步是創建一個或者多個原型，在VisualBasic中設計窗體。還需要增加足夠的代碼來啟動原型：顯示窗體、用示例數據填充列表框等等。然后準備可用性測試。
　　　　可用性測試可以是個不拘形式的過程：與用戶一道審查設計；也可以是在已創建的可用性實驗室中進行的正式的過程。這兩種方法目的是一樣的：從用戶那兒了解哪兒設計得很好，哪兒還需要改進的第一手材料。放開，讓用戶與應用程序在一起，然后觀察它們；這種方式比詢問用戶更為有效。當用戶試圖完成一系列任務時讓他們表達其思考過程：“要想打開新文檔，所以要在‘文件’菜單中找一找。”記下哪些地方的界面設計沒有反應他們的思考過程。與不同類型的用戶一起測試，如果發現用戶完成某個特定的任務有困難，該任務可能需要多加關照。
　　　　下一步，復查一下記錄，考慮如何修改該界面使它更加可用。修改界面并再測試。一旦對應用程序可用性滿意，就準備開始編碼。在開發的過程中也需要不時地測試來確保對原型的設想是正確的。

　　　　功能的可發現性
　　　　可用性測試的關鍵的概念是可發現性。如果用戶不能發現如何使用某個功能（或者甚至不知道有此功能存在），則此功能很少有人去使用。例如，Windows3.1的大多數用戶都從來不知道ALT和TAB的組合鍵可以用于在打開的應用程序之間切換。界面中沒有任何地方可提供線索來幫助用戶發現這一功能。
　　　　為了測試功能的可發現性，不解釋如何做就要求用戶完成一個任務（例如，使用“窗體
　　　　當為應用程序創建對話框時，心里想著用戶。這個消息給用戶傳達了有用的信息嗎？它容易理解嗎？命令按鈕表示的選擇明確嗎？這選擇適合給定的條件嗎？記住，僅僅一個討厭的消息框就會使用戶對應用程序產生壞印象。
　　　　如果正在設計自定義對話框，盡量堅持用標準類型。如果與標準消息框布局相差太遠，用戶可能不會把它認作是對話框。
　　　　詳細信息關于對話框的詳細內容，請參閱本章前面的“對話框”。

　　　　不用對話框的錯誤處理
　　　　當錯誤出現時不一定要打斷用戶。有時更可取的是不通知用戶而用代碼來處理錯誤，或者以不停止用戶工作流程的方法來提醒用戶。這個技術的很好的例子是MicrosoftWord中的“自動更正”功能：如果普通單詞拼錯了，Word自動修改它；如果不常用單詞拼錯了，在其下劃一條紅線提醒用戶以后改正。
有大量的技術可以使用；哪些技術適用于應用程序應由自己決定。這里有幾個建議：
　　　　1.在“編輯”菜單中添加“撤銷”功能。對于刪除等情況，與其用“確定”對話框來打斷用戶，還不如確保他們作出正確的決定并提供“撤銷”功能以備他們以后改變主意。
　　　　2.在狀態欄或圖標上顯示消息。如果錯誤不影響用戶當前的任務，不要停止應用程序。使用狀態欄或亮色警告圖標來警告用戶，當他們準備好后可以處理該問題。
　　　　3.改正問題。有時錯誤的解決辦法很顯然。例如，當用戶試圖存文件時磁盤已滿，則在其他驅動器中檢查系統尋找空間。如果空間可用，則保存該文件；在狀態欄中顯示一條消息告訴用戶做了些什么。
　　　　4.保存消息等候處理。因為不是所有的錯誤都是緊要的，或要求馬上注意的；考慮把這些記錄到文件中，當用戶退出應用程序時或其他方便的時候再把它們顯示給用戶。如果用戶發生輸入錯誤（如：把MainSt.寫成MianSt.），記錄它。添加“ReviewEntries”按鈕和顯示差異的函數，以便用戶可以改正它們。
　　　　5.不要做任何事。有時錯誤并不重要，不足以成為警告的原因。例如，LPT1上的打印機的紙張沒準備好這一事實，在準備打印之前并沒有多大關系。等待，直到消息合乎當前的任務。
　　　　詳細信息關于錯誤處理技術的詳細內容，請參閱第十三章“調試代碼與處理錯誤”。

　　　　設計用戶輔助模式
　　　　不論用戶界面設計得多么好，有時用戶總需要幫助。應用程序的用戶輔助模式包括諸如聯機幫助和打印出來的文檔等東西；它也可以包括用戶輔助設備，如工具提示、狀態條、“這是什么”幫助以及向導。
　　　　像應用程序的其他任何部分一樣，用戶輔助模式設計應當在開始開發之前。模式的內容將隨著應用程序的復雜程度與預期讀者的不同而不同。

　　　　幫助與文檔
　　　　聯機幫助是任何應用程序的重要部分，它通常是用戶有問題時最先查看的地方。甚至簡單的應用程序也應該提供“幫助”。不提供它就好像是假定用戶從來不會有問題。
　　　　在設計“幫助”系統時，記住它的主要目的是回答問題。創建主題名稱與索引條目時盡量用用戶的術語，例如，“我如何格式化頁面？”比“編輯”，“頁格式”菜單更容易找到主題。不要忘記上下文相關性；對大多數用戶而言，如果他們按下F1鍵尋求一指定字段的幫助，卻發現自己在內容主題上，則他們會感到受挫折。
　　　　基本概念的文檔，不管是打印的和/或由壓縮盤提供的，對所有的應用程序都是有幫助的，除了最簡單的以外。它可以提供那些用簡短的“幫助”主題難以傳達的信息。至少，應該在ReadMe文件窗體中提供用戶在需要時可以打印的文檔。

　　　　用戶輔助設備
　　　　在用戶界面中，有幾種對用戶提供輔助的技術。用VisualBasic在應用程序中添加工具提示、“這是什么”幫助、狀態顯示和向導是很容易的。這些設備中的哪些適用于自己的應用程序應由自己決定。

　　　　工具提示
　　　　當用戶在用戶界面上搜索時，工具提示（圖6.23）是一種向他們顯示信息的好方法。工具提示是個小標簽，當鼠標指針在控件上停留會兒即顯示，通常包含此控件的功能描述。正常情況下工具提示與工具欄結合使用，它在界面的大多數部分也能很好工作。

　　　　大多數VisualBasic控件都包含用來顯示工具提示的屬性：ToolTipText。以下代碼將對名為“cmd　　　　4.為任何其它的控件重復步驟2到步驟3。

　　　　向導
　　　　向導是一種用戶輔助設備，它引導用自己的實際數據一步一步地實現一個過程。向導通常用來提供任務專用輔助。它們幫助完成需要相當長的（而且令人討厭的）學習過程的任務，它們給還沒有成為專家的用戶提供專家信息。
　　　　VisualBasic的專業版與企業版包括了創建向導的工具：向導管理器。
　　　　詳細信息關于向導的詳細內容，請參閱第四章“工程的管理”中的“使用向導與外接程序”。