本文章是由機器翻譯。

ALM Ranger

透過 ALM 準備尋寶

ALM Ranger

下載代碼示例

在本文中,我們介紹示例 Windows 商店 app,ALM 準備寶藏圖,並分享設計、 編碼和測試經驗的Visual StudioALM Rangers在構建應用程式。它旨在提供主目錄中的內容可説明開發人員成為精通應用程式生命週期管理 (ALM) 的做法。ALM Rangers是一個促進Visual Studio產品組、 Microsoft 服務和 Microsoft MVP 社區之間的協作處理缺少的功能,通過刪除通過受體阻滯劑,併發布最佳做法和指南,基於現實世界的經驗的專家組。

我們做了什麼,為什麼?

我們要向您告解一下:我們愛Visual Studio和Visual StudioTeam Foundation伺服器 (TFS)。Microsoft 會產生一些最佳的軟體發展工具。我們不只說,因為我們為微軟工作 — — 我們認為這方法早在加入本公司之前。這些套件提供令人難以置信的數量的功能,但可以證明令人生畏的新使用者。開發人員如何開始學習使用這些工具?這個問題本身向我們提出以稍有不同的方式。

ALM Rangers目前在 TechReady 會議通常具有數量的會話描述如何提高微軟開發工具的知識。會議甚至舉行互動式會話參與者那裡可以提供回饋到建築這些產品的內部組。我們發現這些是令人興奮的機會,為開發人員和顧問。加入ALM Rangers隊後, 我們開始探索發佈的指南,並很快意識到,有大量的內容,以消化 ; 我們不知道應該從何處開始學習。

我們真正想要的東西是一種資源,説明我們成為精通 ALM 的做法。我們開始建立 ALM 準備寶藏地圖 Windows 商店 app 成為專家們在他們的旅程導致使用者通過材料。圖 1 顯示您我們的工作的結果。它包含五個類別,每個都有多個主題的研究:

  1. 籌備
  2. 快速簡介
  3. 指引
  4. 模具
  5. 講習班


圖 1 寶地圖 Windows 商店

這些領域包含指南、 動手實驗室和視頻,使其盡可能為使用者輕鬆地拾取他們需要迅速和有效的技能。導航的材料特別好在新啟用觸摸的設備如 Microsoft Surface 上工作。

為了提供最佳的體驗,我們得到了專家的 UX 設計師和高級開發人員構建應用程式的説明。

ALM 準備寶藏圖解決方案:UX 設計掘金

製造一個良好的第一印象 寶藏圖瓦 (見 圖 2) 是吸引眼球和明亮,用來象徵砂橙色背景。立即,使用者可以看到該應用程式的主題 — — 這是明確的棕櫚樹和在通向那裡"的 X"標誌著寶藏的現場。應用程式標題是清晰可見的瓦片。確保該圖塊描述了您的應用程式是什麼其實關於創建一個良好的第一印象。你想要的最後一件事是使用者打開您的應用程式,並對他們為什麼使用它以及它可以如何説明他們混淆不清。


圖 2 寶藏地圖 Windows 存儲應用程式平鋪

我們已經利用初始螢幕 (請參閱圖 3) 顯示更多的應用程式的個性,並説明確保好發射經驗。尋寶圖初始螢幕呈現珍重,這也是一種平穩、 拋光載入經驗擴展的路徑。它是整齊和簡單的設計,反映出使用者體驗將會如何。此外,獨特的螢幕可以説明加強品牌。


圖 3 寶藏地圖 Windows 存儲應用程式閃屏

主頁 — — 藏寶圖本身 — — 出現一旦應用程式已載入。再次,我們清楚、 內容重點設計立即確認該應用程式的目的。我們想要使此頁面的神奇,所以使用者想要探索該應用程式的其餘部分。主頁是旅程開始和位置,使用者一眼就知道這將一段旅程。標題是用於導航,源和我們"chrome 上的內容"的設計,因為他們站出來。應用程式的內容被強調通過刪除非功能性的任何元素。要快速查找資訊的任何人都可以在螢幕上查找的所有連結,而不必流覽該應用程式,為所有類型的使用者提供了極大的體驗。

有時會被忽視,但關鍵 Windows 8 介面跨其所有應用程式使用一個網格系統的原則。這一原則促進一個乾淨、 整潔的設計。

尋寶圖 app 雇用我們到處上主頁的網格系統,結果是,內容是高度可見 — — 更多的內容,減少鉻。此項內容在 chrome 原則之上是更獨特的 Windows 存儲區的應用程式樣式,原則之一視覺統一,有助於偉大的使用者體驗主頁是唯一頁,則此規則的一個例外。我們正在塑造之旅和一個海盜主題,我們就不會一直能夠實現無的可視表示形式。

版式有時被忽視,很多人都不知道多少,它可以加強 app 的品牌。使用的字體,正確和一致地有助於實現清晰並提供乾淨、 整潔的外觀,使應用程式更易於閱讀,因此使用。推薦的字體是文本的瀨越 UI (主要用於使用者介面元素 (如按鈕)、 宋體 (用於閱讀和寫作,如電子郵件) 和 Cambria (對於較大塊)。我們瀨越 UI 用於除標題以外的所有文本。對於那些,我們用行楷來建立一個更強的主題 (見圖 4)。因為我們想要的應用程式的外觀符合基於紙張的地圖,因為這有助於加強海盜主題,我們不要打破這裡,字體的規則。所以,在這種情況下,它不會工作很好。


圖 4 我們在寶藏地圖 Windows 存儲應用程式中使用的字體

無縫和流體的導航是關鍵的是要提供的易用性和巨大的使用者體驗推薦兩種形式的導航模式:階層式系統和平板系統 (見圖 5)。大多數應用程式所使用的等級體系。它是最常見的將是最熟悉類型的導航向多個使用者。它也是最好的制度,以創建該流體的感覺,但仍然是簡單易用。平面系統主要用於遊戲、 瀏覽器或創建文檔的應用程式,使用者可以只向後轉並轉發同一層次級別。尋寶圖應用程式使用的等級體系,和我們相信它也使用它。主頁將歸類為中心,和每一節創建的第一個層次分支,從每一節然後將創建另一個層次結構的分支。例如,從主頁,使用者可以導航到準備部分,其中使用者可以流覽其他準備款。


圖 5 推薦導航模式

可用性 ,評估 app 的 UX 改善設計,使該應用程式是很重要:

  • 簡單易用
  • 給使用者更有價值 — — 例如的功能它可以提供
  • 更適宜使用

評估您的設計為您提供了該應用程式具有優秀的使用者體驗和使用者會發現它有用的、 可用的和可取的信心。

我們那麼如何評估應用程式的使用者體驗?有很多的方法來做到這一點,但兩個常見原因是自我評估和認知的演練中,如中所示圖 6

圖 6 評估應用程式的使用者體驗

  自我評估 認知演練
使用的原因 這根據您想讓使用者實現或查找的目標。它可以確保設計是與您的主要意圖的軌道上。 這是有點更多地圍繞特定的任務,使用者可能希望實現,例如,要查找有關資訊"VM 廠模具及指南"。
發生時機 這是一個好主意,要做自我評估每個衝刺 (sprint),或當已達到每個目標 ; 他們最後 30 分鐘的時間。 在設計過程中,並通過每個衝刺 (sprint)。

有四個將説明在 app 的自我評估,以及 app 的認知演練的成功標準。包括:

  • 偉大的人:什麼是 app 在偉大?聯絡點的視覺效果是什麼?
  • 可用:什麼使用者應該能夠明白、 知道或做更成功,因為 app?
  • 很有用:你有什麼想要為值使用者?
  • 可取:您想要取悅使用者,或使它們愛這款應用程式的哪些部分?

我們使用的自我評估和認知的演練。自我評估是在我們每週的立場 ups 進行審查和進行通過每一次衝刺。進行的認知演練了在設計過程中,通過每個衝刺 (sprint)。評估我們的 app 的 UX 説明我們理解的願望和情感連接到使用者可以確認的經驗。

總結 UX 設計:

  • 請確保該圖塊描述了您的應用程式是怎麼回事。
  • 創建唯一的閃屏,來加強您的品牌。
  • 編寫具有明確的重點內容。
  • 使用推薦的網格佈局來創建一個簡單和乾淨的設計。
  • Don不要忘了關於版式。使用推薦的字體,如有可能,瀨越 UI、 宋體或 Cambria 等。
  • 有一種明確的導航模式。從分層系統或扁平的系統中進行選擇。
  • 評估您在整個開發週期的應用程式的可用性。

編碼的珠寶

編碼開始之前,我們提出一系列的編碼為這一專案的目標。這些目標成為口頭禪我們如何設計和開發基本代碼。

  • 適應性:要求可以更改、 可添加或減少,功能和設計可以支援完全不同的東西扔掉。適應性是遊戲的名稱 !
  • 簡單:簡單是重要許多優勢,在軟體設計中,特別是可維護性和 fixability。
  • 可測試性:品質保證必須是每個專案的高度優先事項和基本代碼必須允許有全面和"簡單"的測試。
  • 性能和流動性:從一開始,這款應用的使用者體驗必須為正數。App 必須及時地顯示資訊、 總是必須回應使用者輸入和不能落後。
  • 團隊環境:App 是很少建立由個別參與者或甚至個別的團隊。我們將確保 app 建成可以縮放到許多更多的團隊成員的方式。

所以現在,我們有我們定義的目標,在世界做我們如何實現編寫一個應用程式,在這麼短的時間 — — 工作部分時間 — — 不僅滿足功能要求,但也以及我們非功能性要求的同時呢?幸運的是我們,這輪建成了之前和建設我們的 app 的是將我們的 app 應用行之有效的模式和做法的問題:

  • C# 和 XAML:我們決定使用 C# 和 XAML,主要是因為在這個專案上派遣大多數都是熟悉這種方法。這包括自己的語言,以及模具和對他們的支援。
  • 模型-視圖-ViewModel (一直堅持使用 MVVM):這是一個為您的演示文稿層分開您從您的物件的業務邏輯的模式。我們選擇這一特定模式,因為 C# 和 XAML 技術本身很好它。但更重要的是,用一種單一模式,我們就可以開始鑿掉在我們非功能性要求。一直堅持使用 MVVM 最積極影響的目標是適應性、 可測試性、 團隊環境和簡單性。適應性得到改進,您可以在您的應用程式的功能部分的任何轉乘。也許已經完成新的演示文稿的特定視圖模型,並可以立即而無需更改任何其他代碼替換它。因為每個核心功能程式碼片段分隔成自己個人的責任,哪些手段測試可以直接針對那些編寫和自動化提高可測試性。因為您有一組定義的合同之間應用程式的移動部件,允許團隊與另一個並行工作,提高團隊環境。簡單得到改進,每個運動部件是其自己定義的移動部件,在以特定的方式進行交互。詳細資訊,請參閱"什麼是 Microsoft 測試管理器 2012 年新"在 msdn.microsoft.com/magazine/jj618301
  • 資源:一直堅持使用 MVVM 的精神和分離的角色和可更換部件後,我們決定為我們的字體、 按鈕和其他類似的設計項目的定義添加資源。這有助於改善團隊環境、 簡潔性和適應性。
  • 但我們有關性能和流動性做了什麼呢?我們隨後長時間運行進程的等待非同步/模式。這是開發人員可能在構建應用程式,Windows 存儲區中掙扎,但它並不一定要的領域之一。幸運的是,Windows 存儲應用程式使用 C# 和 XAML 的電源來自 Microsoft.NET Framework 4.5,使您可以方便地包括非同步工作負載分配到您的應用程式通過這種模式。如果它那麼容易做,為什麼做鄉親掙扎與它?這個問題的答案通常歸結為使用邏輯,是長時間運行而不提供現成的由.NET 框架。此示例可以邏輯來計算基於複雜的數學圖表的繪製點。A 充分理解非同步和等待是提供流體、 高性能的應用程式的關鍵。有關詳細資訊,請參閱"非同步性能:瞭解非同步費用和等待"在 msdn.microsoft.com/magazine/hh456402

其他考慮因素包括:

  • 觸摸語言:從發展角度來看,這不是任何更容易。幾乎每一個外框控制項中所有您預期的方式支援觸摸。從編碼的角度來看,這是應用程式生成的最容易的部分。
  • 魅力:交互的魅力也是簡單的。註冊這些在你的 appxmanifest 和到您想要註冊,如搜索或共用的特定魅力為每個頁面添加在事件處理常式。我們已經沒有魅力所處理的問題。他們運作良好,像魅力應該工作。
  • 瓷磚、 閃屏和方向:所有這些被處理在 appxmanifest 中,然後通過在應用程式級別的應用程式中的事件掛鉤。它是簡單的和一切詳細的示例代碼中。

如何所有真正運作在這裡是如何在實踐中解決事情:

  • 一直堅持使用 MVVM 命令:一直堅持使用 MVVM 非常棒的理論。然而,在現實中,它證明有點不同于平常Windows Presentation Foundation(WPF) 和 Silverlight 發展,特別是執行命令,因為我們舊的樣本沒有工作。幸運的是,命令 <T> 是非常容易實現在新的框架中,可以看到在我們的應用程式範例中。但我們苦惱沒結束與命令,因為 ListViewBase 專案沒有附加的命令屬性 !我們決定解決這用於演示目的的兩種方式:

第一,我們決定要解決此問題,使用一個未使用的屬性:

<ListView Grid.Column="2"
          SelectedItem="{Binding Selected,Mode=TwoWay}"

向它是綁定的返回"null"並不會引發任何異常 (即使您打開所有異常),這很好,但是關鍵的屬性是集合中。在組中,而不是設置什麼,我們使導航調用並作為參數傳遞的選定項的索引。

第二,我們決定創建附加的依賴項屬性的類型 ICommand。示例的實現是在類中"ItemClickCommand""MVVMSupport"資料夾內。

  • 多個檢視狀態導致大規模查看檔:我們查看檔變得非常大,更難於管理,主要是由於多個檢視狀態。不同的佈局,每個檢視狀態一般需要,而且你甚至可以有不同的看法,為不同的顯示尺寸或更改維度,等等。我們的做法是將其分為多個的.xaml 檔,使用每個狀態的每個視圖的一個.xaml 檔。例如,如果我們有一個叫做"HomePageView"的視圖,我們會在充分、 捕捉和填充的資料夾,每個在其狀態的資料夾內有"HomePageView.xaml"。
  • 適應在現實世界中:這是一個好的故事。我們制定了我們的 app 大部件後 — — 切換資料服務提供者、 交換教科文組織統計研究所和添加新魅力相互作用對所有適當的地方 — — 適應不斷變化的需求變得一塊蛋糕。問題可以很容易地追蹤,和很多規劃還清了,因為設計師可以並行工作,與發展商和贊助商。

總結這一節,從編碼的角度來看,Windows 存儲應用程式非常簡單正確制定。經過幾個預定義的規則,心態和模式允許您快速建立一個很好的應用程式。應用程式檢視狀態、 應用程式生命週期狀態、 魅力的互動、 流動性、 確保將您的代碼中,使您的設計團隊來迴圈設計,主要關注問題。有關詳細資訊,請參閱 dev.windows.com

測試和驗證解決方案的品質

我們從一開始定義的核心驗收要求之一就是要提高樣本代碼品質,是我們的總體品質先行嘗試程式的一部分 (見 aka.ms/df_tooling)。嚴格的品質蓋茨地緣政治、 命名空間、 代碼分析和 StyleCop (見 stylecop.codeplex.com) 法規遵從性説明我們製造更好的解決方案,儘管只是一個示例。

測試不應事後才想到的並與樣品一樣重要,這一點與要徑任務解決方案。強制執行的代碼的品質,並管理使用者的期望和要求,從一開始,而不是面對數以百計的法規遵從性 bug 和憤怒的測試人員和有遲來的品質改進週期內處理的功能和代碼改動,以容易。

因為目的是快速示例解決方案中,我們主要被通過測試策略著重行為作為一部分的系統和使用者的接受度測試 (使用者接受度測試) 的"黑箱"。前者是手動執行的團隊,重點放在預期的功能和非功能性要求和探索邊緣情況在內部被理解。社會應邀協助使用者接受度測試驗證、 執行探索性測試基於真實場景和期望,併發掘 bug 缺失、 不切實際,和不清楚的功能。

如圖所示,在圖 7 (這裡對應圖中的紅色圓圈數位數位),與我們通常使用 Microsoft 測試管理器探索性測試功能 (1) 和 (2) 對評價上表面類型設備,捕獲的示例解決方案的模擬器詳細的意見 (3) 和記錄測試會話 (4) 供將來參考。


圖 7 探索性測試

在將來,我們會認真考慮結構更加合理的測試案例的定義和使用 Microsoft 假貨來説明我們實現單元和冒煙測試。這將使我們能夠自動地連續驗證功能變化和相關的代碼更改。

下一步是什麼?

我們將演變 ALM 準備寶藏圖的應用程式,和我們正在考慮為準備參考資產線上更新功能。有關詳細資訊,請參閱"下­站Visual StudioALM Rangers"在 aka.ms/vsarunderstand; 在"Visual StudioALM 兵兵解決方案" aka.ms/vsarsolutions; 在 ALM 準備寶藏圖示例代碼 aka.ms/almtreasure; 與應用程式本身在 Windows 存儲在 aka.ms/vsartmapapp。我們歡迎你坦率的回饋和想法 !

Anisha Pindoria 是與 Microsoft 諮詢服務在聯合王國的 UX 開發顧問。

Dave Crook 是一位顧問開發人員與 Microsoft 諮詢服務東地區,Visual Studio和Team FoundationServer 他的工作重點在哪裡。

Robert Bernstein 是與 Microsoft 諮詢服務全球公共部門網路安全小組高級程式師。

Robert MacLean 一個軟體發展者依偎在一個典型的開放式發展辦公室在昆山日高威泰 (bbd.co.za)。

Willy-Peter Schaub 是Visual StudioALM Rangers在微軟加拿大發展中心高級專案經理。

感謝以下技術專家對本文的審閱中:派特裡夏 · 瓦格納 (微軟)