從Windows Phone到Windows 8平臺Metro應用的統一設計
許多 Windows Phone 開發者已經計劃將他們的 Windows Phone 應用移植到 Windows 8 系統上。也許你會想：同樣是 Metro 的界面風格，應該很容易能夠進行直接移植吧？讓我們通過下邊的案例來看看是否確實如此。
這個案例相信可以給我們帶來一些啟發。通過這個對現有 Windows Phone 應用移植到 Windows 8 的過程，我們將對 Windows Phone 和 Windows 8 設計指導中主要相似之處和不同點進行討論，了解我們的設計哪些能夠在這個過程中被復用，以及哪些不能。
出于這個目的我們使用 Tasks（這是一款目前 Windows Phone 平臺上下載量超過 10,000的 todo 類工具應用）作為我們的設計案例。作為使用我們所開發的 Windows Phone 平臺 UI 組件搭建的演示案例，這個應用由 Telerik 的 Windows Phone 團隊開發。它起初是名為 ToDoLists 的應用，最初是作為 Windows Phone 開發者學習材料而發布的。（該應用源碼可免費使用。下載）
我們將涉及所有 Metro 應用中關鍵的設計模式和設計流程，并對 Windows Phone 和 Windows 8 之間的異同進行討論。因此主要目錄如下：
- 設計流程
- 界面布局和導航
- 操作命令和動作
- 觸摸操作
- 屏幕導向和視圖
- 通知和活動磁貼
- Telerik 即將推出的 Windows 8 套件
你也可以點擊下載高分辨率 PDF 文件（大約 7M）和低分辨率 PDF 文件（大約 2M）。
一、設計流程
在獲得初步的設計思路之前，我們并不需要關心應用所在的平臺究竟為何。在一開始的時候，重點在于研究和思考用戶實際的需求，以及對所有平臺上的 同類應用進行分析。在本案例中，我們已對 Tasks 在 Windows Phone 平臺有了初步的信息架構。在此基礎之上我們需要對其進行優化并確保它能夠適應于不同的屏幕尺寸。
下圖即為這一階段所使用的低保真原型——各種創意草圖，能夠形成完整交互流程的應用頁面以及應用早期的紙面原型。下一步的工作是將原型從紙面轉化成原型文件，并在此過程中提高線框圖保真度。
紙面草圖
開發人員需要參與設計流程中的每一步，提供技術參考并協助創意。在我進行視覺設計的同時，他們開始進行應用原型的開發。這并不意味著我的工作將 在視覺設計的工作完成時結束，恰恰相反，在所有功能的開發和集成過程中一位專業設計人員的參與是十分必要的。只有這樣，我們才能確保所有的設計決策得以正 確的理解和實施（尤其是觸摸操作）的同時，還可以有流暢自然的交互過程。如果條件允許的話，通過與開發團隊和測試人員的協作進行多次迭代，堅持敏捷思想的 實踐。
我的建議是盡可能早些在硬件設備上進行調試。而且一旦你開始在硬件設備上調試應用，不要抗拒任何能夠讓應用體驗獲得最優的必要的變更修改。需要切記的是，不要執迷于那些沒辦法正常使用的設計或功能特性。
頁面流程圖——最終設計環節的可交付成果之一
二、界面布局和導航
Windows Phone 和 Windows 8 的界面布局和導航模型既有比較多的相似，也有一些十分顯著的區別。讓我們先來看看這兩個平臺間的相似之處：
1. 內容組織和導航
“Content not Chrome”也是基本的 Metro 原則之一（譯者注：“Content not Chrome”最初是 Chrome 瀏覽器的設計理念，旨在將更多的內容展現給用戶，盡可能的減少外邊框，讓用戶的視覺專注在自己的內容上，注重用戶的易用性。），并被采用在 Windows Phone 和 Windows 8 的 Metro 應用中。以下是對這種從中心發散式的導航模型的詳細說明：
中心頁（Hub page），或稱為主頁
在應用中，用戶可通過該頁面到達應用中的所有其他頁面。中心頁的目標是按照類別規劃展現應用所提供的豐富內容。這有些像為應用創建的一個雜志（用戶能夠很快對所有內容進行瀏覽）。在 Tasks 中，我們在中心頁面根據對應的任務、項目和類別展現對應的內容摘要。
Windows 8 版 Tasks 的中心頁
Windows Phone 版 Tasks 的中心頁
部分頁（Section pages）
集合同一類內容的頁面。例如所有任務頁面。
Windows 8 版 Tasks 的部分頁和 Windows Phone 版 Tasks 的部分頁
詳細信息頁（Detail pages）
如其名稱所示，該頁顯示某一個單獨內容的詳細信息。
Windows 8 版 Tasks 的詳細信息頁和 Windows Phone 版 Tasks 的詳細信息頁
接下來我們將要詳細說明 Windows 8 和 Windows Phone 在設計模式上的差異。
2. 無硬件返回按鍵（Windows 8）
Windows 8 中的軟件返回按鈕
與 Windows Phone 不同，Windows 8 沒有硬件的返回按鍵。這導致在設計時需要在頁面的頁首或導航欄中加入返回按鈕。除了中心頁（hub page）以外的所有頁面都需要有返回按鈕，以便用戶可以從進入的路徑返回。
在 Windows Phone 中返回按鍵十分重要，它保存了用戶當前進入的一連串路徑。返回按鍵的導航處理需要十分小心，確保用戶不會在應用里迷失，落入應用中可能因為處理不當而出現 的陷阱、死循環或其他會造成迷惑的頁面。只有這樣才能獲得用戶的信任，使她相信可以在應用中獲得她想要得到的信息。
讓我來舉例說明。在 Windows Phone 版 Tasks 中，用戶可以將某一個任務（或項目、類別）pin 到 Windows Phone 的開始菜單，這樣當用戶點觸主頁的任務磁貼時可以打開這個任務的詳細信息頁。此時，如果打算繼續瀏覽應用的其他部分，用戶需要點擊頁面 logo 旁邊的 home 按鈕進入中心頁(主頁)。這時最初進入的詳細信息頁會從返回按鍵的后退路徑中移除。這么做的原因完全是由于在 marketplace 中發布應用時的規則限制。微軟要求，當用戶位于主頁時點擊返回按鍵，必須從應用中退出并返回到開始菜單。
在 Windows Phone 中用戶在應用中導航需要依靠點擊內容條目、應用按鈕完成前進的操作，并通過返回按鍵后退返回。
在 Windows 8 中，用戶擁有更多的機會來選擇自己的導航路徑。
3. 通過手指輕掃屏幕邊緣的方式導航
輕掃屏幕邊緣可以劃出 app bar 和導航欄。導航欄提供全局導航控制，可以在導航欄顯示所有的頁面并提供統一的導航體驗。Windows 8 版 Tasks 的導航欄是與 WP 版 Tasks 的主要區別之一。我們在已經實現的導航模型基礎上加入這種導航欄，以便使用戶從應用的任意頁面都可以很方便跳轉到想要到達的頁面。
導航欄
4. 頁面過濾和排序
Windows Phone 中可以使用 Pivot 控件管理應用中的頁面和視圖。Pivot 常常用作內容過濾、查看多種數據集或視圖切換。在 Windows 8 中使用頁面過濾和排序組件替代 pivot 控件。這一組件更像是傳統的標簽（tab）模式。
Windows 8 中的標簽控件和 Windows Phone 中的 pivot 控件
5. 列表菜單導航，過濾菜單
Windows 8 更大的屏幕為設計帶來更多的自由度，在所選對象的詳情頁面側邊我們可以添加一個當前對象所確定的對象類型的菜單。而且為了防止菜單列表太長無法讀取而帶來 的不便，我們還可以在頂部加入一個過濾器以便更容易獲取到目標信息。這種在顯示細節信息的同時并在界面上提供其他選項的方式在屏幕尺寸較小的手機上幾乎是 不可能實現的。當然這種方式可能不一定適合所有的情況，但在我們給出的 Tasks 案例中確實是一種更加友好的方式。
Windows 8 中帶有過濾器的列表菜單
6. 水平/垂直滾動
滾動的處理方式是 Windows Phone 和 Windows 8 之間另外一個顯著的區別。在 Windows Phone 中這兩種滾動方式都是允許的：在 Panorama 整頁內滑動是橫向的，而在 Panorama 頁內的列表區域滑動則是縱向的。但在 Windows 8 中則無法采取這種方式，只能從選擇橫向或者縱向進行單向滑動。原因在于 cross-slide 交互過程中，選擇一個對象后手指只能垂直于平移的方向滑動很短的距離。因此在大尺寸屏幕上將移動方式限定在其中一種有助于為單頁內的選定操作維持一致性的 交互體驗。
7. 語義變焦（semantic zoom）
主頁中的語義變焦
另一個需要在 Windows 8 中設計語義變焦，以便用戶能夠縮小內容集合并快速跳轉到所需的內容上。
8. 使用 charms 設計應用的設置、共享、關于、反饋和搜索等功能界面
Windows 8 中提供了一個特殊的位置放置這些頁面以便能夠使他們協調一致。這種 charms 控件能夠以輕掃屏幕邊緣的方式劃出。我必須承認，在 Windows Phone 版 Tasks 里，這些頁面組織的沒有那么好，但是在 Windows 8 里這方面獲得了很大程度的提升。
反饋彈出
三、交互動作
1. 選取
Windows 8 的選取和 Windows Phone 的選取
在 Windows Phone 中多選操作通過列表框中的勾選框完成。在 Windows 8 中單個選擇和多選操作都通過 cross-slide 交互動作來完成。
在 Windows Phone 中當用戶點擊選取按鈕之后，應用會根據當前情境切換顯示為選取模式，這時用戶可以通過點擊操作選取多個對象。Windows 8 也采用了同樣的方式處理這種情況。
2. 情境應用菜單（Contextual Application Menu）
在 Windows Phone 中，應用菜單（application menu）既可以是頁面間的導航工具（naviga- tional tool），也可以是命令工具欄（command toolbar）。當作為導航使用時應用菜單總是可用的，但當它作為對數據內容的操作命令菜單時，其可用性需要視具體的數據而定。當用戶選取了對應的數據 集時，應用菜單需要顯示在屏幕下方并且使用戶知道命令切換至可用狀態。在 Windows Phone 版 Tasks 中，我們將應用菜單作為命令工具欄使用。通過結合內嵌操作命令，使應用菜單成為一個強大而靈活的工具箱，以幫助用戶管理自己的數據（如任務、項目或類 別）。在應用中我們未曾考慮將應用菜單作為導航工具，因為應用菜單中已經包含了許多任務，同時我們無法將導航和數據操作這樣兩種完全不同屬性的交互動作混 合在一起。同樣我也完全不建議其他開發者這樣做。
應用菜單的操作按鈕會根據頁面或內容不同而變更
在 Windows 8 中用戶輕掃屏幕頂部或底部邊緣會顯示應用菜單，在作為導航菜單時用戶選取某個對象也會顯示。在這兩種情況下應用菜單顯示的命令會有不同。在沒有選取對象的 情況下，應用菜單中的命令應該是在應用中通用的操作命令。例如在 Tasks 中“新建”和“同步”命令按鈕會一直顯示在應用菜單中。但是應用菜單并不保持顯示在屏幕中，需要用戶通過手勢才能顯示我所建議的內容。
沒有選取對象時的應用菜單欄
在選取對象的情況下，應用菜單中的操作命令按鈕需要根據選取的對象確定。Windows 8 的應用菜單功能可以是主要的應用菜單也可以是針對某個內容對象的操作菜單。我強烈建議為通用的操作按鈕和情境操作按鈕設定風格一致的固定位置。例如在 Tasks 中通用操作按鈕放置在靠近右手拇指的右側，而情境操作按鈕放置在靠近左手拇指的左側區域，并以此作為拇指（誰這么多拇指:P）操作的交互規則。這樣符合交 互設計中的一條重要規則，即“可預見性”，也就是在用戶期望能夠操作的地方提供操作按鈕。
在所有的任務頁面中有一個對象被選中時的應用菜單欄
但是應用菜單并不保持顯示在屏幕中，需要用戶通過手勢才能顯示我所建議的內容。
3. 內容的關鍵動作（Critical Actions in the Content）
接下來的會有一點復雜。我之所以用到“關鍵的”（critical）這個詞，是想說明這些操作動作會對用戶的內容做一些很重要的操作。作為一名 設計人員，我們的工作需要從所有任務中區分出最重要的，并通過設計手段強調他們的重要性。當我們決定在 Windows Phone 版 Tasks 中將應用菜單作為操作命令區后，我們要對關鍵的操作動作進行區分，并把它們以圖標按鈕（icon buttons）的形式放置在 app bar 中。其他的菜單選項放置在應用菜單當中。通過這種方法確保關鍵性的操作按鈕可以保持可見。比如對于一個任務來說，重要的動作應該包括：確認完成、編輯和刪 除，而 pin 到首頁、今天完成和延期一天等操作則不那么重要。
WP 版 Tasks 中的動作優先級
Windows 8 的應用中關鍵的動作應該與 Windows Phone 中保持一致，但有一點不同，即在 Windows 8 的應用菜單并不總是可見的，因此我們無法使用與 Windows Phone 中相同的方式處理。我們可以將關鍵的動作按鈕放置在內容區域中，而把其他的動作放在 app bar 上。
Windows 8 中的關鍵動作按鈕放置在任務標題上方，位于內容區域當中
四、觸摸操作
假如 Windows Phone 只能通過觸摸界面操作，其觸控規則與在 Windows 8 中一致。微軟發布了一個全面的指南是一個很好的總結參考，在指南中包含對于觸摸界面你所需要知道的一切內容。在此之外我需要做一點提示，有一些方式是有像 素限制的。你需要針對 Windows 8 觸摸屏幕的默認像素密度計算你所需要的像素大小并對此有一個確定的方案。在大多數情況下設備的像素密度是不同的，例如 Nokia Lumia 800 采用 252 ppi 的像素精度，而 Nokia Lumia 900 采用 217 ppi 的像素精度。這些只是手機設備的情況，對于 Windows 8 所有設備所采用的硬件類型和屏幕像素密度我們尚不清楚。所以如果能夠確定一些物理指標（如毫米）可能更好一些。在你設計軟件的過程中對這些方面很難預料， 這也是為什么我們說盡可能早些在足夠多的觸摸設備上調試原型是非常重要的。
以下是我總結列出的在觸摸交互設計中最重要的幾點：
- 目標和目標尺寸必須足夠大，在最大限度上減少用戶誤操作。
- 為用戶觸摸提高可見反饋，可以是動畫動作或更改圖案，等等。
- 為 cross-slide 交互進行設計（在 Windows 8 中），對頁面進行設計，確保用戶只在一個方向平移視圖。
在 Windows 8 平臺應用設計的過程中不要忘了把鼠標和鍵盤，在你的應用的大部分重要特性中都要支持這兩樣設備的可接入性，所有的任務也必須可以通過鼠標或鍵盤的操作實現。
微軟建議開發者使用橫向視圖，因為這樣對屏幕空間的利用率比較高，同時在一個視圖導向的設備上能讓用戶感覺更加自然。但是我建議開發者應該根據 你所呈現給用戶的信息類型來決定使用何種視圖。無論是 Metro 原則還是 UX 指南都沒有要求設計決策應該脫離于具體的情境，僅僅為了設計而設計。設計人員的意義在于思考并確定什么方式是對用戶來說最佳的選擇。用戶體驗的重要性先于 遵循規則。
五、屏幕導向和視圖
我們怎么能不愛微軟，他們讓設計人員的工作變得前所未有的重要，因為每個應用都至少有兩種視圖需要我們來設計！（譯注：這句是吐槽+反諷）在 Windows Phone 中只有兩種屏幕視圖可以使用，但是 Window 8 中有 4 個：
1. 全屏視圖（Full View），顯示在設備的整個屏幕上。
2. 填充視圖（Fill View）
當然最低限度的處理方案就是什么也不做。微軟承諾如果你僅僅設計了一個視圖屏幕會將應用界面自動填充到指定的屏幕區域。
3. 貼邊視圖（Snapped View）
屏幕形狀有些類似于手機屏幕。貼邊視圖可以被看作是界面尺寸完全不同的另外一個應用。你需要在狀態、情境和交互多個方面為你的用戶進行調整。這 里并不強制保留全屏視圖的所有元素，只需要能夠確保用戶在當前空間和視圖下能夠完成應用中所有必要的任務。例如在 Tasks 中，我們通過只顯示一個任務群組可用并且使用下拉框在不同的群組之間切換顯示的方式簡化布局。同時在貼邊視圖中也沒有 app bar ，只在左側有關鍵性的操作動作。
4. 縱向視圖（Portrait View）
這并非強制性的要求，但是應用如果能對縱向視圖有適應性方案會有更好的用戶體驗。由于屏幕的垂直變化你至少需要對界面布局的規劃進行優化。好在柵格系統足夠靈活可以進行優化處理。
六、通知和活動磁貼
1. 活動磁貼（live tile）
live tile 是 Metro 原則的另一個直接說明，完全的數字化風格。這意味著盡量不要模擬物理對象來制作數字化風格 UI。作為一個視覺元素，傳統的圖標無法為用戶提供應用實時更新的數據信息。而與之相對的，live tile 完全可以做到這一點。它能夠而且需要提供持久信息和當前更新的動態信息。例如 Windows Phone 版 Tasks 的 live tile 會顯示今天任務的數量，磁貼翻轉后背面會區分顯示今天需要完成的任務和過期尚未完成（緊急）的任務。之所以這樣設計，是由于用戶大多出于“把事情完成”的 心理而更加關心這些信息。
Windows 8 上我們可以有更大的自由度來決定需要展示的數據，除了數字以外我們還可以顯示任務名稱。
WP 中 live tile 的正面和背面
Windows 8 中的 live tile 可以在每一面展示更多的信息
2. Toast 通知（Toast Notifications）
不同于 live tiles，toast 通知主要顯示需要立即吸引用戶注意力的緊急信息。在 Windows Phone 版 Tasks 的當前版本中，我們并沒有使用這種通知方式，而是使用微軟的提示對話框控件提示用戶。在 Windows 8 版 Tasks 中可以將任務或項目分享給該應用的其他用戶。當前用戶如果獲得應用中其他用戶分享的任務，就是一個緊急的事件更新，比較適合使用 toast 通知的方式來呈現。
緊急事件的 toast 通知
七、Telerik 即將推出的 Windows 8 套件
Windows Phone 版 Tasks 應用目前在 Windows Marketplace 可免費下載（點擊此處進入）。Windows 8 版 Tasks 目前正在開發當中。
Windows Phone 版 Tasks 使用 RadControls for Windows Phone 開發。RadControls for Windows Phone 是一款可用來搭建 Windows Phone 應用程序的 UI 組件和基礎應用控件套件（點擊此處可以了解更多信息并下載免費試用版本）。可以用以開發 Windows 8 Metro 風格應用的 Telerik 套件目前已在研發，我們馬上將會分享更多的細節。
如果你有興趣加入我們的 Windows 8 早期開發者俱樂部，你可以率先在你的 Metro 應用中接入我們的產品，并且獲得特別的海外產品推廣和營銷機會。
原文：Designing a Windows 8 Metro style app starting from an existing Windows Phone app