可用性設計
任何應用程序的可用性基本上由用戶決定。界面設計是需多次反復的過程；在為應用程序設計界面時，第一步就設計出非常完美的界面的情況非常少見。用戶參與設計過程越早，花的氣力越少，創建的界面越好、越可用。
什麼是好的界面
設計用戶界面時，開始時最好是先看看Microsoft或其他公司的一些賣得很好的應用程序。畢竟，界面很差的應用程序不會賣得很好。將會發現許多通用的東西，比如：工具欄、狀態條、工具提示、上下文菜單以及標記對話框。Visual Basic具有把所有這些東西添加到應用程序中的能力，這並不偶然。
也可以憑借自己使用軟件的經驗。想一想曾經使用過的一些應用程序，哪些可以工作、哪些不可以以及如何修改它。但要記住個人的喜好不等於用戶的喜好，必須把自己的意見與用戶的意見一致起來。
還要注意到大多數成功的應用程序都提供選擇來適應不同的用戶的偏愛。例如，Microsoft Windows“資源管理器”允許用戶通過菜單、鍵盤命令或者拖放來復制文件。提供選項會擴大應用程序的吸引力，至少應該使所有的功能都能被鼠標和鍵盤所訪問。
Windows界面准則
Windows操作系統的主要的優點就是為所有的應用程序提供了公用的界面。知道如何使用基於 Windows的應用程序的用戶，很容易學會使用其他應用程序。而與已創建的界面准則相差太遠的應用程序不易讓人明了。
菜單就是這方面很好的例子——大多數基於 Windows的應用程序都遵循這樣的標准：“文件”菜單在最左邊，然後是“編輯”、“工具”等可選的菜單，最右邊是“幫助”菜單。如果說 Documents 會比 File 更好，或者“幫助”菜單要放在最前，這就值得討論一下了。沒有任何事情阻止您這樣做，但這樣做會引起用戶的混淆，降低應用程序的可用性。每當在應用程序與其他程序之間切換時，用戶都不得不停下來想一想。
子菜單的位置也很重要。用戶本期望在“編輯”菜單下找到“復制”、“剪切”與“粘貼”等子菜單，若將它們移到“文件”菜單下會引起用戶的混亂。不要偏離已經創建的准則太遠，除非有很好的理由這樣做。
可用性的檢測
測試界面可用性的最好方法是在整個設計過程中請用戶參與。不論是正在設計大型的壓縮包應用程序，還是小型的有限使用的應用程序，設計的過程應當完全相同。使用已創建的設計准則，界面設計應從紙上開始。
下一步是創建一個或者多個原型，在 Visual Basic中設計窗體。還需要增加足夠的代碼來啟動原型：顯示窗體、用示例數據填充列表框等等。然後准備可用性測試。
可用性測試可以是個不拘形式的過程：與用戶一道審查設計；也可以是在已創建的可用性實驗室中進行的正式的過程。這兩種方法目的是一樣的：從用戶那兒了解哪兒設計得很好，哪兒還需要改進的第一手材料。放開，讓用戶與應用程序在一起，然後觀察它們；這種方式比詢問用戶更為有效。當用戶試圖完成一系列任務時讓他們表達其思考過程：“要想打開新文檔，所以要在‘文件’菜單中找一找。”記下哪些地方的界面設計沒有反應他們的思考過程。與不同類型的用戶一起測試，如果發現用戶完成某個特定的任務有困難，該任務可能需要多加關照。
下一步，復查一下記錄，考慮如何修改該界面使它更加可用。修改界面並再測試。一旦對應用程序可用性滿意，就准備開始編碼。在開發的過程中也需要不時地測試來確保對原型的設想是正確的。
功能的可發現性
可用性測試的關鍵的概念是可發現性。如果用戶不能發現如何使用某個功能（或者甚至不知道有此功能存在），則此功能很少有人去使用。例如，Windows3.1 的大多數用戶都從來不知道 ALT 和 TAB 的組合鍵可以用於在打開的應用程序之間切換。界面中沒有任何地方可提供線索來幫助用戶發現這一功能。
為了測試功能的可發現性，不解釋如何做就要求用戶完成一個任務（例如，使用“窗體模板”創建新文檔）。如果他們不能完成這個任務，或者嘗試了好多次，則此功能的可發現性還需要改進。
當用戶或系統出錯時與用戶交互
在理想世界裡，軟件與硬件都會無故障地一直工作下去，用戶也從不出錯。而現實中錯誤總是難免的。決定當事情出毛病時應用程序如何響應，是用戶界面設計的一部分。
常用的響應是顯示一個對話框，要求用戶輸入應用程序該如何處理這個問題。不太常用（但更好）的響應是簡單地解決問題而不打擾用戶。畢竟，用戶主要關心的是完成任務，而不是技術細節。在設計用戶界面時，考慮可能出現的錯誤，並判斷哪一個需要用戶交互作用，哪一個可以按事先安排的方案解決 。
創建容易理解的對話框
偶爾應用程序中會出現錯誤，需要為解決這種情況做出判斷。這通常作為代碼的分支出現——If...Then 語句或者 Case 語句。如果這個判斷需要與用戶交互，此問題通常用對話框來提交用戶。對話框是用戶界面的一部分，像界面的其他部分一樣，它們的設計在應用程序可用性中發揮了作用。
有時有這樣的感覺，好像許多程序對話框的設計員，不會講使人容易理解的話。比如這樣的消息：“硬盤 C 的扇區被損壞或不能訪問。中止、重試、忽略？”（見圖 6.22 ）這對一般的用戶而言不大好理解。這等於有侍者問顧客：“我們沒有湯或者廚房正在生火，中止、重試、忽略?”您會如何回答呢？以用戶能理解的方式或短語描述問題（和選擇）是重要的。在前面的例子中，更好的消息可以是“在 C 盤上存文件有問題，請把文件存於 A盤。存不存文件?”
當為應用程序創建對話框時，心裡想著用戶。這個消息給用戶傳達了有用的信息嗎？它容易理解嗎？命令按鈕表示的選擇明確嗎？這選擇適合給定的條件嗎？記住，僅僅一個討厭的消息框就會使用戶對應用程序產生壞印象。
如果正在設計自定義對話框，盡量堅持用標准類型。如果與標准消息框布局相差太遠，用戶可能不會把它認作是對話框。
詳細信息 關於對話框的詳細內容，請參閱本章前面的“對話框”。
不用對話框的錯誤處理
當錯誤出現時不一定要打斷用戶。有時更可取的是不通知用戶而用代碼來處理錯誤，或者以不停止用戶工作流程的方法來提醒用戶。這個技術的很好的例子是 Microsoft Word 中的“自動更正”功能：如果普通單詞拼錯了，Word 自動修改它；如果不常用單詞拼錯了，在其下劃一條紅線提醒用戶以後改正。
有大量的技術可以使用；哪些技術適用於應用程序應由自己決定。這裡有幾個建議：
1.在“編輯”菜單中添加“撤銷”功能。對於刪除等情況，與其用“確定”對話框來打斷用戶，還不如確保他們作出正確的決定並提供“撤銷”功能以備他們以後改變主意。
2.在狀態欄或圖標上顯示消息。如果錯誤不影響用戶當前的任務，不要停止應用程序。使用狀態欄或亮色警告圖標來警告用戶，當他們准備好後可以處理該問題。
3.改正問題。有時錯誤的解決辦法很顯然。例如，當用戶試圖存文件時磁盤已滿，則在其他驅動器中檢查系統尋找空間。如果空間可用，則保存該文件；在狀態欄中顯示一條消息告訴用戶做了些什麼。
4.保存消息等候處理。因為不是所有的錯誤都是緊要的，或要求馬上注意的；考慮把這些記錄到文件中，當用戶退出應用程序時或其他方便的時候再把它們顯示給用戶。如果用戶發生輸入錯誤（如：把 Main St. 寫成 Mian St.），記錄它。添加“Review Entries”按鈕和顯示差異的函數，以便用戶可以改正它們。
5.不要做任何事。有時錯誤並不重要，不足以成為警告的原因。例如，LPT1上的打印機的紙張沒准備好這一事實，在准備打印之前並沒有多大關系。等待，直到消息合乎當前的任務。
詳細信息 關於錯誤處理技術的詳細內容，請參閱第十三章“調試代碼與處理錯誤”。
設計用戶輔助模式
不論用戶界面設計得多麼好，有時用戶總需要幫助。應用程序的用戶輔助模式包括諸如聯機幫助和打印出來的文檔等東西；它也可以包括用戶輔助設備，如工具提示、狀態條、“這是什麼”幫助以及向導。
像應用程序的其他任何部分一樣，用戶輔助模式設計應當在開始開發之前。模式的內容將隨著應用程序的復雜程度與預期讀者的不同而不同。
幫助與文檔
聯機幫助是任何應用程序的重要部分，它通常是用戶有問題時最先查看的地方。甚至簡單的應用程序也應該提供“幫助”。不提供它就好像是假定用戶從來不會有問題。
在設計“幫助”系統時，記住它的主要目的是回答問題。創建主題名稱與索引條目時盡量用用戶的術語，例如，“我如何格式化頁面？”比“編輯”，“頁格式”菜單更容易找到主題。不要忘記上下文相關性；對大多數用戶而言，如果他們按下 F1 鍵尋求一指定字段的幫助，卻發現自己在內容主題上，則他們會感到受挫折。
基本概念的文檔，不管是打印的和/或由壓縮盤提供的，對所有的應用程序都是有幫助的，除了最簡單的以外。它可以提供那些用簡短的“幫助”主題難以傳達的信息。至少，應該在 ReadMe 文件窗體中提供用戶在需要時可以打印的文檔。
用戶輔助設備
在用戶界面中，有幾種對用戶提供輔助的技術。用 Visual Basic在應用程序中添加工具提示、“這是什麼”幫助、狀態顯示和向導是很容易的。這些設備中的哪些適用於自己的應用程序應由自己決定。
工具提示
當用戶在用戶界面上搜索時，工具提示（圖 6.23）是一種向他們顯示信息的好方法。工具提示是個小標簽，當鼠標指針在控件上停留會兒即顯示，通常包含此控件的功能描述。正常情況下工具提示與工具欄結合使用，它在界面的大多數部分也能很好工作。
大多數Visual Basic控件都包含用來顯示工具提示的屬性：ToolTipText。以下代碼將對名為“cmdPrint”的命令按鈕提供工具提示。
cmdPrint.ToolTipText = "Prints the current document"
像界面的其它部分一樣，要確保此文本能明確地傳達給用戶的消息。
詳細信息 關於工具提示的詳細內容，請參閱《語言參考》的“ToolTipText屬性”。
“這是什麼”幫助
當用戶選取“這是什麼”幫助並單擊控件上的“這是什麼”光標，“這是什麼”幫助提供了和彈出式“幫助”主題（見圖 6.24 ）的鏈接。“這是什麼”幫助可以從工具欄按鈕、菜單項或者對話框的標題欄上的按鈕啟動。
要從菜單或工具欄使“這是什麼”幫助有效，請按照以下步驟執行：
1. 選取希望為其提供幫助的控件。
2. 在“屬性”窗口中，選取 WhatsThisHelpID 屬性。
3. 為相關的彈出式“幫助”主題輸入上下文標識符號。
4. 為任何其他控件重復步驟 1 到步驟 3。
5. 選取窗體。
6. 在“屬性”窗口中，設置該窗體的 WhatsThisHelp 屬性為 True。
7. 在菜單或工具欄按鈕的 Click 事件中，鍵入以下代碼：
formname.WhatsThisHelp
當用戶單擊該按鈕或菜單時，鼠標指針會改變為“這是什麼”幫助指針。為了使在自定義對話窗體的標題欄上的“這是什麼”幫助有效，設置該窗體的 WhatsThisButton 與 WhatsThisHelp 屬性為 True。
詳細信息 關於“這是什麼”幫助的詳細內容，請參閱《語言參考》的“WhatsThisHelp 屬性”與“WhatsThisButton 屬性”。
狀態顯示
狀態顯示也可用與工具提示差不多的方法來提供用戶輔助設備。狀態顯示是提供那些不太適合工具提示的指令或消息的一種好方法。包括在 VisualBasic 的專業版與企業版中的狀態條控件能很好地顯示消息；Label 控件也能用作狀態顯示。
在狀態顯示中顯示的文本可以用以下兩種方法中的一種來更新：用控件或窗體的 GotFocus 事件，或者用 MouseMove 事件。如果想把顯示用作學習設備，在 Help 菜單中添加一個項目來轉換其 Visible 屬性的開與關。
要添加狀態顯示，請按照以下步驟執行：
1. 在窗體中添加 Label 控件。
2. 選取希望為其顯示消息的那個控件。
3. 在控件的 MouseMove（或 GotFocus）事件中添加以下代碼：Labelname.Caption = "Enter the customer's ID number in this field"當鼠標移到該控件上時，這條消息將顯示在此 Label 控件中。
4. 為任何其它的控件重復步驟 2 到步驟 3。
向導
向導是一種用戶輔助設備，它引導用自己的實際數據一步一步地實現一個過程。向導通常用來提供任務專用輔助。它們幫助完成需要相當長的（而且令人討厭的）學習過程的任務，它們給還沒有成為專家的用戶提供專家信息。
Visual Basic的專業版與企業版包括了創建向導的工具：向導管理器。
詳細信息 關於向導的詳細內容，請參閱第四章“工程的管理”中的“使用向導與外接程序”。
