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