可用性設計
任何應用程序的可用性基本上由用戶決定。界面設計是需多次反復的過程；在為應用程序設計界面時，第一步就設計出非常完美的界面的情況非常少見。用戶參與設計過程越早，花的氣力越少，創(chuàng)建的界面越好、越可用。
什么是好的界面
設計用戶界面時，開始時是先看看 Microsoft 或其他公司的一些賣得很好的應用程序。畢竟，界面很差的應用程序不會賣得很好。將會發(fā)現(xiàn)許多通用的東西，比如：工具欄、狀態(tài)條、工具提示、上下文菜單以及標記對話框。Visual Basic 具有把所有這些東西添加到應用程序中的能力，這并不偶然。
也可以憑借自己使用軟件的經(jīng)驗。想一想曾經(jīng)使用過的一些應用程序，哪些可以工作、哪些不可以以及如何修改它。但要記住個人的喜好不等于用戶的喜好，必須把自己的意見與用戶的意見一致起來。
還要注意到大多數(shù)成功的應用程序都提供選擇來適應不同的用戶的偏愛。例如，Microsoft Windows“資源管理器”允許用戶通過菜單、鍵盤命令或者拖放來復制文件。提供選項會擴大應用程序的吸引力，至少應該使所有的功能都能被鼠標和鍵盤所訪問。
Windows 界面準則
Windows 操作系統(tǒng)的主要的優(yōu)點就是為所有的應用程序提供了公用的界面。知道如何使用基于 Windows 的應用程序的用戶，很容易學會使用其他應用程序。而與已創(chuàng)建的界面準則相差太遠的應用程序不易讓人明了。
菜單就是這方面很好的例子——大多數(shù)基于 Windows 的應用程序都遵循這樣的標準：“文件”菜單在最左邊，然后是“編輯”、“工具”等可選的菜單，最右邊是“幫助”菜單。如果說 Documents 會比 File 更好，或者“幫助”菜單要放在最前，這就值得討論一下了。沒有任何事情阻止您這樣做，但這樣做會引起用戶的混淆，降低應用程序的可用性。每當在應用程序與其他程序之間切換時，用戶都不得不停下來想一想。
子菜單的位置也很重要。用戶本期望在“編輯”菜單下找到“復制”、“剪切”與“粘貼”等子菜單，若將它們移到“文件”菜單下會引起用戶的混亂。不要偏離已經(jīng)創(chuàng)建的準則太遠，除非有很好的理由這樣做。
可用性的檢測
測試界面可用性的方法是在整個設計過程中請用戶參與。不論是正在設計大型的壓縮包應用程序，還是小型的有限使用的應用程序，設計的過程應當完全相同。使用已創(chuàng)建的設計準則，界面設計應從紙上開始。
下一步是創(chuàng)建一個或者多個原型，在 Visual Basic 中設計窗體。還需要增加足夠的代碼來啟動原型：顯示窗體、用示例數(shù)據(jù)填充列表框等等。然后準備可用性測試。
可用性測試可以是個不拘形式的過程：與用戶一道審查設計；也可以是在已創(chuàng)建的可用性實驗室中進行的正式的過程。這兩種方法目的是一樣的：從用戶那兒了解哪兒設計得很好，哪兒還需要改進的第一手材料。放開，讓用戶與應用程序在一起，然后觀察它們；這種方式比詢問用戶更為有效。當用戶試圖完成一系列任務時讓他們表達其思考過程：“要想打開新文檔，所以要在‘文件’菜單中找一找?！庇浵履男┑胤降慕缑嬖O計沒有反應他們的思考過程。與不同類型的用戶一起測試，如果發(fā)現(xiàn)用戶完成某個特定的任務有困難，該任務可能需要多加關照。
下一步，復查一下記錄，考慮如何修改該界面使它更加可用。修改界面并再測試。一旦對應用程序可用性滿意，就準備開始編碼。在開發(fā)的過程中也需要不時地測試來確保對原型的設想是正確的。
功能的可發(fā)現(xiàn)性
可用性測試的關鍵的概念是可發(fā)現(xiàn)性。如果用戶不能發(fā)現(xiàn)如何使用某個功能（或者甚至不知道有此功能存在），則此功能很少有人去使用。例如，Windows 3.1 的大多數(shù)用戶都從來不知道 ALT 和 TAB 的組合鍵可以用于在打開的應用程序之間切換。界面中沒有任何地方可提供線索來幫助用戶發(fā)現(xiàn)這一功能。
為了測試功能的可發(fā)現(xiàn)性，不解釋如何做就要求用戶完成一個任務（例如，使用“窗體模板”創(chuàng)建新文檔）。如果他們不能完成這個任務，或者嘗試了好多次，則此功能的可發(fā)現(xiàn)性還需要改進。
當用戶或系統(tǒng)出錯時與用戶交互
在理想世界里，軟件與硬件都會無故障地一直工作下去，用戶也從不出錯。而現(xiàn)實中錯誤總是難免的。決定當事情出毛病時應用程序如何響應，是用戶界面設計的一部分。
常用的響應是顯示一個對話框，要求用戶輸入應用程序該如何處理這個問題。不太常用（但更好）的響應是簡單地解決問題而不打擾用戶。畢竟，用戶主要關心的是完成任務，而不是技術細節(jié)。在設計用戶界面時，考慮可能出現(xiàn)的錯誤，并判斷哪一個需要用戶交互作用，哪一個可以按事先安排的方案解決 。
創(chuàng)建容易理解的對話框
偶爾應用程序中會出現(xiàn)錯誤，需要為解決這種情況做出判斷。這通常作為代碼的分支出現(xiàn)——If...Then 語句或者 Case 語句。如果這個判斷需要與用戶交互，此問題通常用對話框來提交用戶。對話框是用戶界面的一部分，像界面的其他部分一樣，它們的設計在應用程序可用性中發(fā)揮了作用。
任何應用程序的可用性基本上由用戶決定。界面設計是需多次反復的過程；在為應用程序設計界面時，第一步就設計出非常完美的界面的情況非常少見。用戶參與設計過程越早，花的氣力越少，創(chuàng)建的界面越好、越可用。
什么是好的界面
設計用戶界面時，開始時是先看看 Microsoft 或其他公司的一些賣得很好的應用程序。畢竟，界面很差的應用程序不會賣得很好。將會發(fā)現(xiàn)許多通用的東西，比如：工具欄、狀態(tài)條、工具提示、上下文菜單以及標記對話框。Visual Basic 具有把所有這些東西添加到應用程序中的能力，這并不偶然。
也可以憑借自己使用軟件的經(jīng)驗。想一想曾經(jīng)使用過的一些應用程序，哪些可以工作、哪些不可以以及如何修改它。但要記住個人的喜好不等于用戶的喜好，必須把自己的意見與用戶的意見一致起來。
還要注意到大多數(shù)成功的應用程序都提供選擇來適應不同的用戶的偏愛。例如，Microsoft Windows“資源管理器”允許用戶通過菜單、鍵盤命令或者拖放來復制文件。提供選項會擴大應用程序的吸引力，至少應該使所有的功能都能被鼠標和鍵盤所訪問。
Windows 界面準則
Windows 操作系統(tǒng)的主要的優(yōu)點就是為所有的應用程序提供了公用的界面。知道如何使用基于 Windows 的應用程序的用戶，很容易學會使用其他應用程序。而與已創(chuàng)建的界面準則相差太遠的應用程序不易讓人明了。
菜單就是這方面很好的例子——大多數(shù)基于 Windows 的應用程序都遵循這樣的標準：“文件”菜單在最左邊，然后是“編輯”、“工具”等可選的菜單，最右邊是“幫助”菜單。如果說 Documents 會比 File 更好，或者“幫助”菜單要放在最前，這就值得討論一下了。沒有任何事情阻止您這樣做，但這樣做會引起用戶的混淆，降低應用程序的可用性。每當在應用程序與其他程序之間切換時，用戶都不得不停下來想一想。
子菜單的位置也很重要。用戶本期望在“編輯”菜單下找到“復制”、“剪切”與“粘貼”等子菜單，若將它們移到“文件”菜單下會引起用戶的混亂。不要偏離已經(jīng)創(chuàng)建的準則太遠，除非有很好的理由這樣做。
可用性的檢測
測試界面可用性的方法是在整個設計過程中請用戶參與。不論是正在設計大型的壓縮包應用程序，還是小型的有限使用的應用程序，設計的過程應當完全相同。使用已創(chuàng)建的設計準則，界面設計應從紙上開始。
下一步是創(chuàng)建一個或者多個原型，在 Visual Basic 中設計窗體。還需要增加足夠的代碼來啟動原型：顯示窗體、用示例數(shù)據(jù)填充列表框等等。然后準備可用性測試。
可用性測試可以是個不拘形式的過程：與用戶一道審查設計；也可以是在已創(chuàng)建的可用性實驗室中進行的正式的過程。這兩種方法目的是一樣的：從用戶那兒了解哪兒設計得很好，哪兒還需要改進的第一手材料。放開，讓用戶與應用程序在一起，然后觀察它們；這種方式比詢問用戶更為有效。當用戶試圖完成一系列任務時讓他們表達其思考過程：“要想打開新文檔，所以要在‘文件’菜單中找一找?！庇浵履男┑胤降慕缑嬖O計沒有反應他們的思考過程。與不同類型的用戶一起測試，如果發(fā)現(xiàn)用戶完成某個特定的任務有困難，該任務可能需要多加關照。
下一步，復查一下記錄，考慮如何修改該界面使它更加可用。修改界面并再測試。一旦對應用程序可用性滿意，就準備開始編碼。在開發(fā)的過程中也需要不時地測試來確保對原型的設想是正確的。
功能的可發(fā)現(xiàn)性
可用性測試的關鍵的概念是可發(fā)現(xiàn)性。如果用戶不能發(fā)現(xiàn)如何使用某個功能（或者甚至不知道有此功能存在），則此功能很少有人去使用。例如，Windows 3.1 的大多數(shù)用戶都從來不知道 ALT 和 TAB 的組合鍵可以用于在打開的應用程序之間切換。界面中沒有任何地方可提供線索來幫助用戶發(fā)現(xiàn)這一功能。
為了測試功能的可發(fā)現(xiàn)性，不解釋如何做就要求用戶完成一個任務（例如，使用“窗體模板”創(chuàng)建新文檔）。如果他們不能完成這個任務，或者嘗試了好多次，則此功能的可發(fā)現(xiàn)性還需要改進。
當用戶或系統(tǒng)出錯時與用戶交互
在理想世界里，軟件與硬件都會無故障地一直工作下去，用戶也從不出錯。而現(xiàn)實中錯誤總是難免的。決定當事情出毛病時應用程序如何響應，是用戶界面設計的一部分。
常用的響應是顯示一個對話框，要求用戶輸入應用程序該如何處理這個問題。不太常用（但更好）的響應是簡單地解決問題而不打擾用戶。畢竟，用戶主要關心的是完成任務，而不是技術細節(jié)。在設計用戶界面時，考慮可能出現(xiàn)的錯誤，并判斷哪一個需要用戶交互作用，哪一個可以按事先安排的方案解決 。
創(chuàng)建容易理解的對話框
偶爾應用程序中會出現(xiàn)錯誤，需要為解決這種情況做出判斷。這通常作為代碼的分支出現(xiàn)——If...Then 語句或者 Case 語句。如果這個判斷需要與用戶交互，此問題通常用對話框來提交用戶。對話框是用戶界面的一部分，像界面的其他部分一樣，它們的設計在應用程序可用性中發(fā)揮了作用。