共用方式為


本文章是由機器翻譯。

展現可用性

畫面設計之道

Dr. Charlie Kreitzberg 和 Ambrose Little

認知的檢視

Dr。查爾斯 B。Kreitzberg古老的中文原理講話的 [Tao 為原則和組織在世界的路徑。雖然根目錄的 [Tao 返回某些 2,500 年,其 teachings 會具有一個有趣的平行互動設計。Tao 的核心概念是,每個動作其後一個反應會。概念是,熟悉 Yin Yang 符號 (圖 1) 的描述世界,如分成彼此互動的互補 opposites 老鼠。在螢幕設計我們可能會認為的這個符號表示兩個互補的模型的軟體:實作模型和資訊清單的模型]。這些模型由阿蘭·庫珀描述書About Face 中。庫柏說明實作模型為實際方式,軟體的運作方式。資訊清單的模型,相反,是軟體代表其功能給使用者的方法。有效的設計重點是,才能建立資訊清單模型方式適合使用者認為與問題相關的。


圖 1 的 Yin Yang 符號

身為的開發人員您深 immersed 實作模型中,,但是當您移到,設計 UI 時,您需要移動您觀點方式請參閱軟體使用者]。不 ’s 容易進行,因為它 ’s 難略過您知道並採用另一個人 ’s 檢視。許多設計技術,我們 ’ve 例如建立人物代表來代表一般的觀眾成員和建構工作案例要了解使用者的運作方式的前一個資料行中所討論的被為了協助您建立的心理移位。您需要清楚瞭解您的對象]、 [他們需要完成,工作] 及 [他們認為他們的活動相關的方式。也 ’s 重要辨識技術的了解您可以預期的對象的層級。使用這項知識,您可以開發資訊清單的模型符合。

第一次建立架構

我們先前撰寫關於區別高階和詳細的設計。螢幕設計應該永遠開頭的高階架構設計。該架構放好之後您可以使用它為基礎的詳細的畫面。架構的兩個索引鍵的項目如下所示:

  • 可讓使用者輕鬆地從螢幕畫面移動 accord 與工作流程中巡覽配置。我們討論瀏覽我們的 3 月 2009年資料行 (msdn.microsoft.com/magazine/dd458810.aspx)。
  • 錨定使用者,並提供使用者所在的線索,做為標題,等這類的永續性元素。

亦即您可以透過它定義通用於所有的畫面的項目是由上而下方法的開頭,並建立清除模型的使用者取得周圍的方式。

使用就地架構,開發精簡架構,如果需要在最重要螢幕。最後,開發剩餘的畫面和對話方塊。

建立框線範本

您可能會實作為主版的網頁的架構應該指示螢幕上的主要區域。部份的資訊在這些區域中會在每個畫面 (,就例如產品名稱、 標誌和主功能表) 相同。某些資訊會將變更從畫面,但應該會出現在相同的位置在每個畫面 (比方就說畫面標題和提示路徑)。最後,某些資訊將會從螢幕畫面 (比方就說控制項特定的螢幕) 不同的。所有這些元素但是,應該一起建立一致而完整的設計。

請先將螢幕分割成函數為基礎的區域。例如,查看 圖 2, 用來安排基本的螢幕區域的框線。請注意如何這個線框中的每個區域已被標記,讓使用者將會瞭解它的目的。


圖 2上的 [螢幕區域] 的定義

整體的設計是方便使用者 perceptually 組織的。每個主要的索引標籤可能稍有不同的設計,但只要 doesn’t 移動基本版面配置,設計會出現一致給使用者。要對此進行說明,查看 圖 3, 顯示另一個範本,可以用於應用程式中其他索引標籤。因為基本框架項目會保留常數,可用性會保留,即使不同設計的關鍵項目。


圖 3的一個相容的範本]

就說您為每個畫面選取設計模式應該一致。就例如如果兩個索引標籤有搜尋功能,他們應該以相同的方式呈現該功能。

所有但最簡單的系統需要處理對話方塊和其他第二個畫面。在過去,因為的瀏覽器,限制的很多的 Web 架構的系統避免子視窗和層級。常見的替代方案是將使用者傳送到另一個頁面,使用者必須想出如何取回。通常,這導致混淆。

與平台就像在 .NET Framework、 其相關程式的語言,AJAX,建立快顯視窗和其他優雅的方式管理詳細資料更逼真。當您建立一個架構,考慮如何處理對話方塊及詳細資料。就例如 目錄 23 範本會適用於強制回應快顯視窗的子視窗, 圖 4 所示。

架構建立時, 您應該也考慮使用者支援和說明。說明通常建立為一個 「 螺栓的上,」 的一個 afterthought,但它的運作更遠時它已整合至畫面。請注意,在快顯示 圖 4, 我們 ’ve 保留位置,可以做為提示,以指示使用者的說明文字中。進一步連結可讓使用者存取的其他資訊。(的就說您需要設計範本,以顯示該連結將會如何處理)。


圖 4 的快顯

為了完成表單的使用者,您可能也要建立工具提示,讓使用者以取得有關特定欄位的其他資訊。的 [圖 5] 所示範例設計的。


圖 5 的工具提示

根據使用者支援設計開頭思考您採取大步確保它實際上會建立,而且會很有用且一致。請注意工具提示就像在的提示字元讓使用者瞭解更多的連結。雖然這並不是活動的常見的作法 (和某些工具提示控制項中無法實作),卻是活動的一項強大的技巧,因為它可讓使用者深入更深時保持其目前的內容中。您可能要建立的快顯視窗來支援這些連結,以避免額外的瀏覽的另一個層級的範本。

我的經驗可能是兩個層級的對話方塊,少數的基本範本可以容納甚至很大的系統的 UI。然後您可以藉由指定最多前面的架構,建立設計特定的畫面在臨時平台。

建立樣式輔助線

您在建立架構將它文件樣式輔助線中。這會提醒您選擇的您進行,也可以讓其他人需要開發畫面以維持一致的設計。不一定美觀樣式輔助線。通常,我擷取螢幕範本、 註解這些,並將其註解的畫面貼到 Word,Visio 或網站)。圖 6 是如何快顯線框可能註解的範例。


圖 6 註解的樣式手冊的框線

請務必指定字型、 字型的大小和色彩,讓它們可以是一致畫面之間切換。儘可能,使用樣式而不是硬式編碼的值,做字型和色彩,因此您 (或圖形的演出者) 可以變更視覺設計並仍將一致性維護應用程式。

文件編寫指南也可以指定在 UI 中使用的術語。請務必以一致地使用詞彙,並且選擇對您的觀眾的有意義的條款。

Agile

如同我們 ’ve 所討論的前一個資料行,重整 UI 會造成混淆。這個原因 ’s 通常最好向上全面且有彈性的架構第一次,然後詳細說明在開發週期。您可能會發現,就說您需要的其他範本,或者您需要有額外的設計規則。您當然可以修改文件編寫指南隨著 UI 開發,只要您修改原始設計。如果您發現原始的設計必須 rethought,您應該返回和檢閱所有的畫面的一致性,並考慮變更使用者的影響,如果軟體已部署。

可用性測試

一旦建立您的架構測試其可用性如果可能的話,可以讓某些設計運作方式如您期望。它是一個容易對範本中的變更,並且編碼樣式本指南之前很多的畫面。

建立詳細資料畫面

就地架構和樣式的指南,您可以建立畫面。如果您 ’ve 開發良好的樣式輔助線,可分散在數個開發人員工作然後仍可維持您想要的一致性。

設計個別畫面的工作是美工圖案] 和 [工程的組合。若要建立一個適用於使用者的螢幕設計,您需要將自己放在使用者 ’s 鞋,並看看會全球使用者的方式。’s 不容易的工作,而是其中一個原因可用性測試可能會因此強大,做為工具。

認知的模型

做為起點查看 圖 7,顯示簡化的認知模型的使用者如何處理一個畫面。


圖 7 認知模型的處理的螢幕

使用者通常會啟動關閉工作階段以記住主要目標。就例如 「 我想選取我公司的優點 」 或者 「 我想要解決此客戶 ’s 問題 」。然後,使用者 confronts 每個螢幕,她建立較小、 螢幕層級的目標,如 「 我想要登入 」 或 「 我想要找出客戶 ’s 資料錄 」。

記住這些目標,使用者檢視螢幕,並決定要採取什麼動作。她執行動作,並觀察結果。根據這些結果,使用者建立新的目標,然後再重複程序。

這個處理程序可以輕易地跳遺失,如果使用者沒有辨識出適當的控制項在螢幕上。如果設計工具假設使用者 「 記住 」 何處,而且不會為其建立可見的提示,就會發生這種情況。範例可能是一項產品的使用者需要請按 F1 鍵查看有關,[說明],但提示的作用不存在。另一個範例是當使用者需要回到特定的畫面,找不到函式,但不會記住何處可以找到函式時。在任何的情況下,結果會是通常 frantic 搜尋] 和 [挫折。

這會導致索引鍵的螢幕設計的規則:永遠不會依賴使用者 ’s 記憶體 ;而是,請試著讓每一個選項可以看到。將時間上的同時使用者將會學習系統,任何依賴記憶體只新增到認知的負載,以及,因此,工作。請記住 cognitively,辨識永遠比回收容易。當您大量的選項您可能需要進行的選擇 multistep 處理程序。在這些的情況下輕鬆,盡可能找不到項目,他必須為快速且輕鬆地盡可能,與永遠最少的認知載入使用者。

因為開發人員關心效率,他們可能會覺得它是浪費而 sloppy 要重複已呈現其他地方的資訊。但因為辨識永遠 trumps 回收,您最好呈現項目多次比假設如果它不 ’s 它們的前面,使用者會記住的項目。因為使用者很少開發精確的心理模型的瀏覽的流程 — 至少不直到有很多產品的曝光度 — 依賴它們回收所需的函式是在特定索引標籤下認知載入大量加入處理程序。

配置

上個月,我們討論有關資訊架構,以及如何設計簡單必須對企業有所理解之外並資訊的簡報。個別的螢幕配置時,請記住這些構想。請確定螢幕是 orderly 和可用的雜亂。您希望使用者 perceptually 群組的項目一起成視覺化的單位。尋找在 圖 8 若要查看如何 disorderly 的對齊方式可以讓您的眼睛群組相關的項目在一起真的硬碟。日期對齊 ; 項目,並將按鈕放在接近他們控制的項目,perceptual 群組而輕易地形成。


圖 8 群組讓 「 畫面其他懂

內部一致性

除非不到有 「 真正的好理由嘗試會盡可能以一致畫面之間切換。就例如,以下是一些一般的指導方針:

  • 使用相同的術語,整個系統
  • 組織一致使用相同的表單標題及簡報資訊的資訊
  • 搜尋查詢和結果使用相同的技術

流程 

時您想讓使用者掃描螢幕方式訂單您是通常是最佳的下列使用者 ’s 原生語言的流程。在英文和許多其他語言,這建議從左到右和上到下。查看 圖 9 如何更容易為依字母順序排列的順序讀取字母時它們符合到語言的流程。


圖 9 的流程

如果您的觀眾 ’s 語言是希伯來文、 阿拉伯文、 波斯、 中文,日文,流程可能是由右至左,讓您的螢幕應該調整。流程不是在每個畫面中重要的考量。流程永遠無關的文字。因此,就例如若想代表多個步驟的處理序排列流程重要,即使在螢幕上的物件是圖形。查看 「 washing t 恤 」 則在 i18nguy.com/MiddleEastUI.html

然後將魔法反應

許多 (包括自己) 的設計工具發現它們很好的螢幕設計的情緒回應。您知道時設計是右因為項目看起來屬於的地方。當您從不同觀點檢視它,方法才有意義。我們會在自己描述該情緒的感覺,為 「,魔法的反應然後,」 和我們絕望能夠說明為什麼這個特定的設計是正確答案的用戶端。

身為的開發人員,您有可能發生類似 「 Aha 」 時間,當您解決特別 knotty 技術的設計問題。當您可以在螢幕設計中相同的點,在您將能夠信心有關您的設計決策的 rightness,而且很少會可用性測試證明您錯誤。

研究 [Tao 螢幕設計的並了解您必須建立兩個互補的檢視產品 – 一個技術和置中的一個使用者。當您可以切換從一個檢視其他稍微調時,你就已經精通 「 困難,但值得技術。

[軟體] 檢視


Amborse Little

螢幕設計種,我認為,因此具象且實用大多數的我們只是讓它的項目。  具有不幸讓我們 complacent 的結果:我們不認為足夠相關,或只假設我們知道,我們 ’re 專家,因為我們設計的畫面。

有顯示此資料行的其他篇,沒有確實不同的科學和要讓軟體介面的圖案。平均的開發人員可以根據他 innate talent 和 empathy,在促進良好的經驗的介面來取得只為止。  水平翻轉一邊希望此欄也會顯示即使 UI 設計並不是您主要的專業知識,您可以取得更好在它並也取得更好,在決定當您需要尋求專業人員,在 [] 欄位中。

我說所有此的注意我們 UI 技術似乎長識別設計架構的需求。  我敢說這類的平台的存在有被急迫更我們需要開發人員保留我們例行性和持續的產能比的一致性的重要性的任何意識辨識我們 lovingly 當作使用者變更需求的表面的某些 modicum。 因此,它是 serendipitous 我們有我們有什麼。

到底是什麼,我們有嗎?  嗯,很明顯地取決於何種技術使用,但 ’ll 嘗試保持著重於主要的.NET UI 技術,這是,之後就所有的 MSDN Magazine 的。 

您取得全部的內容

先關閉,讓我假設所有.NET 技術都有一個共用、 具體的基本使用者介面重複使用的概念,控制項和其衍生物 (所謂的使用者控制項)。  這些項目,如我 ’m 確定大多數的我們知道,讓配套向上的不只是視覺化的 UI 部分也功能的重複使用。  我不 ’m 一個技術歷史學家,但我印象控制項通常是跨問題領域 (通常顯示在自己的外部專案或組件,或甚至協力廠商所提供) 的解決方案,以及這些的解決方案控制項通常實作非常廣泛適用的模式中。使用者的控制項在另一方面,是通常導向特定的問題] 網域通常是在相同的專案方案。

控制項和使用者控制項是良好的程式碼,這是已知,使用者介面重複使用,但它們讓您只到目前為止設計架構的觀點。  項目,您需要更多類似項目通常稱為 「 主要 」 或 「 範本 」 的架構,來處理總版面配置和階層式共用的項目,以及使用方式來管理一致的樣式 (意義字型、 色彩、 間距及其他視覺 treatments 做 aesthetics 和資訊的設計) 的項目。  這些項目,跨技術方案而有所不同。

Windows Form

許多衛星前,fearless Floridian 老兄,Stan Schultes,penned 發行項在 Visual Studio 雜誌 稱為 「 瞭解 Visual 繼承 」 (msdn.microsoft.com/library/aa288147(VS.71).aspx)。  本文所述的方法可以幫助主要是與總、 共用的版面配置需求 — 亦即,您便可以製作基底表單及基底的對話方塊,以及從那些符合您需要的大部分建置出。     

我 ’m 恐怕您 ’ll 在幫助您取得 Windows Form 用完所有相關的 ’s 到它自己的裝置從,實作設計的架構。  話雖有如 Infragistics ’s 應用程式設定樣式的架構及工具 ( infragistics.com/learn/applicationstyling.aspx),提供更多的一致性和靈活度,並填滿關閉 Windows Form 留在幫助您實作和管理一個一致的設計架構的間距可以幫助的協力廠商解決方案。

您可能會想有關複合 UI 應用程式區塊 (也稱為 CAB ;請參閱 msdn.microsoft.com/library/aa480450.aspx,),雖然封包為了更 modularizing 和實作一個一致的設計架構的比 decoupling UI,您可以定義殼層使用者介面 (使用一或多個工作區) 可提供該層級的設計架構實作的母片版面配置的排序。  您仍然 ’re 離開需要以確保特定模組表單 harmonious 整個,但是,並提供封包提供模組化,這表示在模組的開發人員遵循您設計的架構指導方針的多個責任。然後如果您 ’re 實作使用封包的應用程式,您應該尋找到 [智慧型用戶端軟體工廠 (SCSF)。(請參閱的一些很好的指引的 msdn.microsoft.com/library/bb266334.aspx 上兩個一起)。

ASP.NET

ASP.NET,是一種 Web 技術可以使用標準的 Web 技術協助設計架構。  chiefly,這表示 CSS,並且在較新的年,熱門共用 CSS 架構 (bing.com/search?q=css+frameworks).  如果您 ’re 小心和一個的 CSS Zen 母片就有點立即取得與頁面的版面配置的幾乎完全控制權,但更有可能您 ’ll 有一些 interplay HTML 結構之間 CSS。  CSS 是最適合更細微的設計詳細資料,例如間距 (邊界、 與邊框距離、 線之間的間隔等等)、 字型、 色彩,而且牽涉到動作的視覺 treatments 的就說要框線和各種影像為基礎的 gymnastics]。 

以一的補數 (或矛盾,取決於您要求的人) 以全新的樣式,ASP.NET 支援佈景主題和面板,協助您取得的額外的控制項出您的應用程式的組織和潛在可維護性的位元。  Infragistics 也提供應用程式設定樣式的 ASP.NET 可讓您管理的應用程式更特別是如果您 ’re 使用 Infragistics ASP.NET 控制項容易樣式。  CSS 及 HTML 功能非常強大,但它們也成為無法管理,並且 Infragistics 產品和內建 ASP.NET 佈景主題及外觀元素設定,以及其他架構嘗試幫助您管理的複雜性,並保留您的例行性。

為了共用總額的版面配置和項目,ASP.NET 具有主版頁面 ( msdn.microsoft.com/library/wtxbf3hh.aspx),可讓您定義常用的父/母片版面配置和使用內容預留位置的版面配置,可以變更根據特定的檢視區域的項目。  主版頁面可以巢狀,您可以有多張母片 (,就例如一個公司,一個用於 MyApp,甚至是一個用於 MyAppDialog — 該排序的項目)。  它真的 ’s 好而 ingenious 架構支援和簡化維護設計的架構與實作,是的 MVC 愛人,您可以使用主版頁面那里也。(請參閱 msdn.microsoft.com/library/dd381412.aspx 做為起點)。

在 ASP.NET 上其他一個便箋。  可以也運用 ASP.NET AJAX (和其他的 AJAX 技術) 本質上維護的外部常見的版面配置,並只更新並取代內容區域。  ASP.NET AJAX 是另一個工具可用於與主版頁面,讓您 AJAX 的優點同時使用 CSS 及一致的設計架構的主版頁面的優點。

SharePoint 和其他內容的管理系統

最後,多半是有關 ASP.NET,SharePoint 和其他內容的管理系統通常超出的項目您取得 ASP.NET 架構提供網頁的範本內容類型,基本概念和類似的功能,可以進一步幫助您建立並維護一個甚至啟用 nondevelopers 若要在一個的意義擴充系統時保持不變的相同的設計架構的一致的設計架構。

WPF

WPF (Windows Presentation Foundation) 有基本上有兩層的樣式,樣式和範本 (請參閱 msdn.microsoft.com/library/ms745683.aspx。) 樣式是基本上是一個群組在一起共用的組,屬性值的方法。  範本是在 WPF 中的兩種基本類型 — 資料範本和控制項範本。  控制項範本會是一個完全自訂包括它們的基本結構和行為的控制項的外觀和感覺的方法。  控制項範本通常用在一起 (比方就說您可以設定範本屬性在控制項的樣式中) 來訂一個不在較早的.NET UI 技術真的可行的程度。資料範本是一個非常各式各樣的方法,來共用一個通用 UI 圖形的定義我是說的資料範本在乎只需尋找相符的繫結而非,範例特定類型的資料來源的資料。

至於總額的版面配置] 和 [共用的項目,因為 WPF 是一種原本的用戶端技術它 ’s 更多或更少的簡單種建立檢視 (視窗),它,配置 (通常使用使用者控制項執行個體) 的執行階段取代版面配置區的內容。  WPF 也支援日誌功能模式的實作 (請參閱 quince.infragistics.com/#/Main/ViewPattern$pattern=Journal+Navigation),可讓您與它使用框架來模擬的不同頁面瀏覽 Web 經驗。  這可能是有效的方法實作版面配置區的方法。(您 ’ll 在 msdn.microsoft.com/library/ms750478.aspx 中找到的詳細資訊)。

WPF (和 Silverlight) 也有一個類似封包的架構,稱為複合應用程式指引 (CAG,(之前稱為 Prism ;請參閱 msdn.microsoft.com/library/cc707819.aspx) 您可以利用類似的方式與先前所述的 Windows Form。  CAG 支援的區域的可以用為容器] 或 [版面配置區中由較大的配置,以及其可以巢狀也的概念。然後如果 ’re 處於 Blend 不可 (避免,這一次),您可以尋找好一些指導組織內容,讓 Blend Prism 合作愉快在 johnpapa.net/silverlight/using-blend-with-prism-apps-in-silverlight-3/

使用的範本的樣式組合主要檢視版面配置區,和使用者控制項 (或框架頁的控制項),請您可以在 WPF 中實作一個非常容易管理的設計架構]。

Silverlight

因為 Silverlight 的所有意圖和目的是 WPF,子集,它是 Microsoft 的嘗試為 100%來源 (XAML) 相容性,Silverlight 之間 WPF 敘述的目標,大部分的我說 WPF 有關套用至 Silverlight,一些的例外情況當然。

第一次關閉,沒有沒有正式的概念,核心 Silverlight 中頁面的 — 基本上,一切都是控制項或一個使用者控制項。  在第 3 版 Microsoft 會新增一個加入框架裝載 「 網頁 」 和 Page 類別衍生自使用者控制項,會自動更新瀏覽器標題列的標題屬性類別的導覽架構。  這些都是日誌功能的實作,以便您可以模擬 Web 方法 (類似 WPF,但撰寫本文的實作不相容的來源,請參閱msdn.microsoft.com/library/cc838245(VS.95).aspx)。 而非的瀏覽的網頁,您瀏覽至模擬網頁的使用者控制項。  但定義的核心概念與版面配置區會保持共用總額的版面配置和項目。和使用 WPF,您可以手動管理與新的 UI 的特定區域 (「 預留位置 」) 中的視覺化項目取代 — 通常是使用者控制項。

至於樣式和樣板化,很幾乎相同本文,與 [Silverlight 提供一個 VisualStateManager 可讓開發人員定義語意的狀態和狀態群組控制項 (或使用者控制項) 的警告。  在這裡我們討論的內容,這 chiefly 表示,VSM 影響,方法自訂控制項範本。  VisualStateManager WPF 的 ; 現在是在工具組請參閱 windowsclient.net/wpf/wpf35/wpf-35sp1-toolkit-visual-state-manager-overview.aspx

而且,因為 Silverlight 不是一種全有或全無的選項,您可以使用它結合 ASP.NET 與用於表示 ASP.NET 的許多設計架構。您只需要管理樣式在 Silverlight 樣式與標準的網頁 (CSS + HTML) 技術的整合。  因此記住這如果您到該路由。

您可以找到在 msdn.microsoft.com/library/cc903925(VS.95).aspx WPF 和 Silverlight 之間差異的相關資訊。

SketchFlow

SketchFlow 就已經釋放的撰寫本文。  雖然 SketchFlow 支援 WPF 和 Silverlight (雖然 SketchFlow 專案目標單一的技術),它有一些關於設計架構管理它自己想法。  因為許多開發人員會使用它來原型的這些.NET 技術,我以為它值得一提。  雖然在這兩種技術,位於 SketchFlow,但卻有一些不同的術語,也就是螢幕和螢幕元件。

在螢幕基本上是它聽起來 — 一個人瀏覽的畫面。(您可以建立 SketchFlow 圖中的畫面之間的視覺化瀏覽連線)。  什麼這通常表示是一個螢幕有足夠不同的 UI 來保證它自己的生命週期和版面配置。  元件螢幕能夠基本上輕鬆地與其他畫面類似使用者控制項共用一個畫面的位元。(在就事實元件螢幕將會在程式碼中建立 UserControls)。

原型的一部分時特別早期原型,會為不超過認為東西要設計架構,沒有的點,此時您可能要執行這項操作。  若要取得多原型超過一頁或兩個以進一步重複及改善,您要開始思考如何共用通用的位元,讓您原型更容易管理。  話雖如此,即使沒有本文最後實作的 ’s 不在主要點的 SketchFlow 向前執行從 SketchFlow 原型。 

您思考詳細的實作設計架構可能可以等待,直到您決定要啟動此時您可以利用一些或許多元件] 畫面,以及甚至部分的樣式、 視覺狀態管理員中) 中的狀態及相關的分鏡板如果您或您的設計工具移至定義它們的任何詳細資料的麻煩的建築物。

使用通用控制項

除了架構工具,協助您實作一個一致的設計的架構和您的應用程式中,您應該也思考設計架構方面的方案如何對應到其他的設計架構的一致性。這是其中 UI 模式可以協助您選擇並實作解決相關的問題的最佳、 最常見的方式。

一次,看來,開發人員 unconsciously (或不) 完成所有以及藉由嘗試來模擬一般使用者所熟悉 (如 Excel 和 Outlook) 常見的解決方案和的就說使用在 [] 方塊中的控制項。  許多人 don’t 思考它,但項目可以說的一致性所提供的有限的控制項集合。我們 don’t 需要太擔心如何實作說,以將下選擇 (請參閱 (quince.infragistics.com/#/Main/ViewPattern$pattern=Drop+Down+Chooser) 因為我們必須在方塊中。同樣地,如需詳細資訊複雜,但是熟悉的介面不是在核心架構的程式庫,我們可以利用工作的協力廠商提供的項目,如的 OutlookBar 功能區,好實作等等。

您可以這些通用控制項視為一種共用通用設計架構內的內建大部分 (商務) 應用程式,並且您應該利用共用的設計架構利用這個熟悉度。  一些有說什麼是直覺反應是通常只是只是什麼很熟悉 (請參閱,就例如 portal.acm.org/citation.cfm?id=584629),所以使用熟悉的 UI 控制項,可以移遠向幫助您似乎直覺式的介面。

在此同時請記住,您仍然需要選擇控制項,根據您的應用程式的需求並不套用 unthinkingly 熟悉控制項只是因為它是熟悉或因為,就例如 Microsoft Office 中使用它。  它可能沒有達到,但才能完成工作匆忙,我認為我們 ’ve 所有誤用的控制項,就像這樣。

一件事,可以幫助您讓多快速是這類判斷呼叫是很好 UI 和 UX 模式庫像 Quince (quince.infragistics.com)。讀取模式的問題]、 [方案]、 [內容],] 及 [基本原理,他們通常 ’re 相當短,有許多方法來協助您辨識特定的模式 (這通常做為控制項實作) 是否適合您的內容。許多的替代方案會提供,您可以使用標記瀏覽其他可能的替代方案。

結論

既然您 ’ve 有啟用.NET 功能,在各種不同的.NET UI 技術的此旋風教學課程,您應該要能夠套用,並利用您 (或您的設計工具 ’s) 工作,來定義一致的架構,讓它易於管理,讓您來改善它在開發期間,並繼續重複,並修改它,維護應用程式在實際執行環境中的項目。