淘寶新UI需求分析篇 - “四核”驅動的“三維”導航

前言

孔子說："軟件是對客觀世界的抽象"。

首先聲明，這里的"三維導航"和地圖沒一毛錢關系，"四核驅動"和硬件也沒關系，而是為了復雜的應用而發明創造的導航邏輯。說這是發明創造，也不是危言聳聽，因為它完全突破了傳統意義的頁面導航概念，看完了本博客以后，相信會讓你腦洞大開。當然這也是一種嘗試，只有UWP的出現才會帶來這種機遇，希望廣大開發者給予指正。

上周發布了淘寶UWP的更新，地址在這里：https://www.microsoft.com/zh-cn/store/apps/%e6%b7%98%e5%ae%9d/9nblggh6c2cd

以前淘寶UWP的mobile版叫“手機淘寶”，desktop版叫“淘寶HD”。上周把silverlight版的半殘“淘寶”下線了，把“淘寶”這個應用名稱拿回來了，現在終于把二者統一為“淘寶”了。

隨著UWP的誕生，一個App應該既可以在狹小的手機屏幕上運行，也可以在手持式平板電腦上運行，甚至可以在寬大的桌面電腦屏幕上運行。而對我們程序員來說，這才是真正的挑戰。Windows 10，一統天下的宏偉計劃確實給操作系統本身的設計帶來了巨大的挑戰，同時也給UWP應用的開發帶來同樣大的困難，因為它要求你的App可以運行在所有運行Windows 10的硬件上，而這些硬件有著截然不同的屏幕尺寸，從Band，到手機，到平板，到桌面電腦，到Hub。但從另外一個方面看，統一的操作系統和UWP卻給用戶帶來了統一的體驗，給整個產業帶來了同樣巨大的利益。

扯遠了……

一維Z軸導航模式

首先看看手機上運行的App采用的導航模式：

 

這是最簡單的導航模式了，從數據結構上看，是一個簡單的堆棧。A是起始頁面；在A上點擊個按鈕，進入B頁面；在B上點擊個圖片，又進入C頁面。按back鍵從C回到B，再按就回到A。

以下是淘寶UWP中，在手機屏幕上運行時的情況。

首先進入主頁A，然后點擊了"淘搶購"頻道，進入淘搶購的列表頁B，然后在B中點擊了一個列表項，進入該商品的詳情頁面C。

手機屏幕有限，一次只能看一個頁面，當用戶想看其它商品信息時，必須先返回到B頁，然后再選擇另外一個條目。

在UWP中，導航必須在Frame類上實現，下面代碼中所示的BackStack，是Frame類中的一個屬性，專門用于保存導航歷史記錄:

 

//
// Summary:
// Gets a collection of PageStackEntry instances representing the backward navigation
// history of the Frame.
//
// Returns:
// The backward navigation stack.
public IList<PageStackEntry> BackStack { get; } 

 

當用戶按了back鍵時，你就可以簡單地用Frame.GoBack()方法來返回到上一頁了。

在Z軸導航模式中，我們使用App.xaml.cs里創建的Frame來做所有頁面的導航容器。

 

Frame rootFrame = new Frame();
Window.Current.Content = rootFrame;
rootFrame.Navigate(typeof(PageA));

調用Frame.Navigate(typeof(PageA))時，會把Page A作為該Frame的Content，同時，這個Frame的值會傳送到Page A的Frame屬性中，兩者是一回事兒，是為了方便再次Navigation時使用。比如this.Frame.Navigate(typeof(PageB))，這里的this實際上是Page A的實例，而this.Frame就是App.xaml.cs里創建的rootFrame。

Z軸導航的實際UWP的例子很多，如網易云音樂。Windows Store應用商店App是另外一個例子，它的內容也是可擴展的，就是說在窄屏上，可以一行列出4個項目，在寬屏上可以根據屏幕寬度列出5~8個項目。還有一個例子就是著名的必應詞典Win10版啦，也是用了一個Frame搞定所有事情。

用這種模式最忌諱的事情是: 當應用場景稍微復雜一些時，也就是頁面較多(8個以上)，有可能產生交叉跳轉，可能會造成用戶迷失；而在code方面，造成后退棧越來越大，不過這還是小事情。只要單個Frame的導航能滿足你的應用場景就可以。

舉例來說，如果我在必應詞典里的背單詞模塊中，想查一個詞，但不想跳轉到search頁，而是想在屏幕右側滑出一個區域來顯示該單詞的詞典解釋，那就需要兩個Frame來完成這個要求了。

不同的導航模式，對界面設計的要求是不同的，這一點請designer注意。在Z軸單頁模式中，只需要專注每個頁面的設計即可。但在后面的復雜導航模式中，只這樣做就不夠了。

一維Master/Detail導航模式

在寬大的桌面電腦屏幕上，上面那種在手機的窄屏界面的展示方式是不可接受的。如下圖的Windows 10中的設置頁面，它的窗口是可縮放的，可寬可窄，隨心所欲。在窄窗口中，顯示一頁的內容；在寬窗口中，side by side地顯示兩頁的內容，合理利用屏幕空間，同時簡化了用戶的操作: 用戶可以在右圖中的左側列表控件中任意點擊感興趣的條目，在右側可以立刻得到響應；但是在左圖中，用戶點擊了Display，進入詳情頁，必須點back鍵回到列表框，才能再進入另外一個條目。

 

 

我們再來看看ITHome - IT之家UWP的界面：

整個屏幕分成三列，最左側的窄條Vertical Menu Bar，中間偏左部分的資訊列表，右半部份的資訊詳情。可以說這是一個標準的寬屏設計模式，易于理解，易于操作，適合推廣使用。

它對應的XAML應該是這個樣子：

 

 1 <Grid Background="{ThemeResource WhiteColorBrush}">
 2     <Grid.ColumnDefinitions>
 3         <!--vertical menu bar-->
 4         <ColumnDefinition Width="48" x:Name="menuCol"/>
 5         <!--list page container-->
 6         <ColumnDefinition Width="2*" x:Name="leftCol" MinWidth="360"/>
 7         <!--detail page container-->
 8         <ColumnDefinition Width="3*" x:Name="middleCol"/>
 9     </Grid.ColumnDefinitions>
10 
11     <common:VerticalMenuBarControl x:Name="menuBar" Grid.Column="0"/>
12 
13     <!--list content in this frame-->
14     <Frame x:Name="leftFrame" Grid.Column="1"/>
15 
16     <!--detail content in this frame-->
17     <Frame x:Name="rightFrame" Grid.Column="2"/>
18 </Grid> 

 

Column-0的寬度為48 epx (effective pixel)，在點擊了上方的漢堡控件展開菜單后，這個寬度可以調整為120左右。

Column-1和Column-2的常規比例為2:3，但是當窗口太窄時，Column-1的寬度有個限制MinWidth="360"，避免里面的內容無法以合理方式展示。當然也可以設置一個MaxWidth="720"，避免太寬時橫向拉伸太難看。

關于epx的概念，請看這里：https://msdn.microsoft.com/windows/uwp/layout/design-and-ui-intro 。改天把這篇東西翻成中文給大家洗洗腦吧。

這種設計適合于簡單的二級內容應用場景，想看三級片是不行的了。現在市面上大多數的UWP，都可以用這種方式來實現，如微博UWP就是另外一個典型。

如果這樣做的話，是否能讓mobile和desktop兩個device使用同一套UI代碼呢？當然可以，否則就不能叫做UWP了，只是需要我們多做一點點事情而已。具體需要做什么事情，我們在另外一篇博客中（關于Win10 Mobile Continuum的使用方式）會詳細說明。

二維(Z+X)導航模式

用上述的master/detail模式，雖然可以充分利用屏幕，但是只適合于場景較為簡單的應用，如新聞類，閱讀類。下面我們看一下稍微復雜一些的應用，比如旺信UWP。先看看截圖獲得感性認識：

聊天主頁，左側展示好友列表：

 

右側窗口為具體聊天頁：

 

最右側的浮出窗口為輔助的設置頁面，基本是popup類型的信息：

 

它的主控頁的XAML是這樣寫的：

 

<Grid Background="{ThemeResource WXWhiteColorBrush}">
    <Grid.ColumnDefinitions>
        <!--vertical menu bar-->
        <ColumnDefinition Width="48" x:Name="menuCol"/>
        <!--list page container-->
        <ColumnDefinition Width="2" x:Name="leftCol" MinWidth="360"/>
        <!--detail page container-->
        <ColumnDefinition Width="3" x:Name="middleCol"/>
    </Grid.ColumnDefinitions>
    <!--left side vertical menu bar-->
    <common:VerticalMenuBarControl x:Name="menuBar" Grid.Column="0"/>


<!--list content in this frame-->
<Frame x:Name="leftFrame" Grid.Column="1"/>

<!--detail content in this frame-->
<Frame x:Name="middleFrame" Grid.Column="2"/>

<!--popup content in this frame-->
<Grid x:Name="rightFrameGrid" Grid.Column="0" Grid.ColumnSpan="3">
    <Grid.ColumnDefinitions>
       <ColumnDefinition Width="*"/>
       <ColumnDefinition Width="500" x:Name="rightCol"/>
    </Grid.ColumnDefinitions>
    <Rectangle Grid.Column="0" Fill="Black" Opacity="0.5"/>
    <Frame x:Name="rightFrame" Grid.Column="1"/>
</Grid>

</Grid> </code></pre> 
  
 
 
  
 
   
最左側的是vertical menu bar
 
   
第二列是leftFrame，用于顯示主要Scenario的主頁面
 
   
第三列是middleFrame，用于顯示每個Scenario的詳細頁
 
   
最右側是rightFrame，用一個grid承載。這個grid用于遮蓋后面的menu bar, left Frame, middle Frame，形成性感的半透明遮罩效果；right Frame用于配置頁面的展示。
 
  
 
  
在旺信UWP中，我們使用了三個Frame做navigation。在子模塊開發前，就實現了一個導航framework，使得每個業務模塊的開發者只需要完成自己的頁面開發，然后直接調用該framework提供的導航方法即可。
 
  
當然，這里的導航不再是this.Frame.Navigate()那么簡單，但是也沒復雜到哪里去，也就是多加了一個參數而已，叫做that.Nav.To(page, left|middle|right)，由后面那個參數指定你將要展示的頁面在哪個frame里出現。這樣做的基本條件是，做好需求分析，仔細梳理頁面之間的邏輯關系，使得每個頁面都在一個預訂的frame里展示。
 
  
旺信的導航邏輯可以抽象成這個樣子：
 
  
 
  
具體是這樣運行的：
 
  
 
   
用戶登錄旺信后，首先展示的是聯系人頁面，命名為A1；
 
   
用戶分別和三個聯系人聊天，會使用X軸導航方式，在右側依次展示三個聊天頁面，A2/A2'/A2"；在Middle Frame中，用了Z軸導航，承載三個頁面。
 
   
用戶在A2時做了兩次配置修改，使用X軸導航方式，依次出現了A3/A3'兩個頁面；在Right Frame中，用Z軸導航承載兩個頁面。
 
  
 
  
 所以，此應用的導航是X+Z的二維模式。這種模式要求interactive designer對該應用的業務非常熟悉，上下文處理得很流暢，否則會有跳躍感。而對于user experience designer，更多地要考慮兩個頁面之間的差別和聯系，和單頁設計的感覺完全不同，兩個頁面既不能長得完全不同（因為有上下文關系），又不能看著差不多，以為是讓用戶玩“找出不同處”的游戲，因為有上下級關系。
 
  
淘寶UWP的應用場景分析
 
  
迄今為止，我們遇到的最復雜的UWP就是淘寶了。打橋牌的人知道，橋牌是叫牌難，打牌難，計分難，發牌好像最簡單；淘寶是設計難，實現難，測試難，使用起來可是隨心所欲。
 
  
下面我們先來看一個常見的用戶購物行為:
 
  
 
   
打開淘寶首頁，點擊淘搶購
 
   
進入淘搶購，點擊一個水果商品
 
   
進入詳情頁，點擊店鋪按鈕
 
   
進入該水果的店鋪，點擊了另一個水果
 
   
再次進入詳情，加入購物車，然后從超級按鈕跳轉按鈕中進入購物車
 
   
在購物車中忽然看到了一件以前收入的衣服，還沒下單，于是點擊立即購買按鈕
 
   
進入訂單頁，發現送貨地址應該修改一下，點擊了地址控件
 
   
進入地址選擇頁，發現沒有自己想要的地址，于是點擊地址管理按鈕
 
   
進入地址管理頁，添加好了新地址，想看看以前的訂單的送貨地址有沒有搞對
 
   
進入我的淘寶，點擊我的訂單按鈕
 
   
進入訂單管理，增加了一個新的發貨地址
 
   
后面一系列折騰，整個購物過程經過了50多次頁面跳轉，歷時1小時……
 
  
 
  
琳瑯滿目的商品，讓人流連忘返，迷失于虛擬的貨架之間。但是作為UWP開發者，我們不能迷失，要理智，理智，理智……老板，那個快遞費能不能便宜些，再送一個贈品……回歸理智！
 
  
之所以有超級跳轉按鈕的設計，是因為你不可能讓用戶back無數次后才能找到購物車頁面，就好像在超市里你必須推著一個購物車，可以隨時放置商品，并且可以有無數通道通向收銀臺一樣。
 
  
下圖演示了這次購物行為的頁面跳轉過程（篇幅有限，圖片較模糊，見諒）：
 
  
 
  
讓我們來仔細分析一下這個常見的購物行為。
 
  
 
  
第一眼看上去，我丂！頁面是可以亂跳的！根本不是普通的App那樣的進棧出棧的規矩，看上去像是一種網狀關系。再仔細看看！怎么好像"詳情"頁出現了很多次呢？
 
  
在網購中，詳情是購物的關鍵環節，圖片，價格，評價，快遞，等等，它可以很大程度決定是否立刻剁手。
 
  
懷著剁手黨的激動心情，我們把詳情用藍色標記一下，變成如下圖:
 
  
 
  
都可以從哪些地方進入詳情頁呢？順藤摸瓜找上游業務鏈，那就是淘搶購，購物車，店鋪。還有很多其他頁面可以進入詳情，篇幅有限，不一一列出，比如天貓，聚劃算等等。
 
  
于是乎，我們把詳情的上游業務標記成橙色的，如下圖所示：
 
  
這里要注意，店鋪雖然在下圖中，處于詳情的下游，但是從真實場景看，店鋪的概念顯然是大于詳情的概念的，所以它實際是詳情的上游。那個鏈接只是系統提供的一種方便的跳轉而已。
 
  
 
  
我們還可以繼續剛才的思路，看看更遠端的上游和下游是什么?
 
  
先看上游，主頁是一個肯定的入口；進入淘寶后，也可以不干別的，直接進入購物車，因此我們把購物車從橙色變為更高級的紅色；我的淘寶是和主頁、購物車并列的入口，也標為紅色；地址管理的scenario非常特殊，可以作為一個獨立的業務，因此也標為紅色。
 
  
再看下游，詳情后面緊跟著的業務應該是確認訂單和支付，當然也可以先和商家討價還價，進入旺信聊天頁面，這些個下游頁面我們標記為綠色的。如下圖所示：
 
  
 
  
圖中出現了4種顏色，紅色，橙色，藍色，綠色，也就是說，淘寶的絕大部分業務流程，都可以以詳情為核心，串聯起前后一共3~5步，成為業務鏈。而每條業務鏈，就是一個Scenario!
 
  
4色定理，怎么讓我想起了微軟大田村的logo呢？
 
  
 
  
OK，讓我們照著這個思路，回過頭瀏覽一下淘寶中的所有頁面，大概能總結出以下幾種scenario：
 
  
 
   
Home->H5(如天貓，聚劃算)->詳情->旺
 
   
Home(猜你喜歡)->詳情->旺
 
   
Home->RushBuy->詳情->旺
 
   
購物車->詳情->旺
 
   
店鋪->詳情->旺
 
   
我的淘寶->H5->詳情->旺
 
   
我的淘寶->設置[list]->關于[detail]->版權信息[chat]
 
   
我的淘寶->訂單管理->詳情
 
   
Home->搜索[list]->詳情[detail]->旺[chat]
 
   
消息(物流)->物流列表[list]->查看跟蹤[detail]
 
   
消息(商戶)->旺[chat]
 
   
收貨地址管理->ADRU
 
   
……
 
  
 
  
還有一些分支，處于第3層和第4層，我沒有列出來，不太重要。以上這些足夠我們整理出一個合理的需求分析了，如下示意圖：
 
  
 
 
  
 
  
也就是說，主頁、店鋪、購物車、我的淘寶、地址管理等，都可以作為后續一系列業務的入口看待，我們把它們叫做Scenario.Home；
 
  
淘搶購、搜索、訂單管理、天貓、聚劃算等，都是一種業務頻道，引導用戶更方便快捷地購物，我們稱之為Scenario.List；
 
  
詳情是業務核心，成為Scenario.Detail；
 
  
后面的業務環節可以叫做Scenario.Chat，里面可以放旺信聊天頁，也可以放下單頁等等。
 
  
淘寶，必須做成四核的，需要4個Frame參與導航，才能符合我們經過縝密需求分析得出的完美業務模型。
 
  
于是，我們可以把業務抽象成這個樣子：
 
  
 
  
 
 
  
 
   
A是一個Scenario的名字；
 
   
1/2/3/4分別是四核導航的4個Frame；
 
   
A1/A2/A2'/A2"/A3/A4/A4'是這個scenario所涉及的頁面，后面的序號代表它們應該在那個Frame上顯示，如果需要的話，在2/3/4三個frame上都可以做傳統的Z軸導航。比如在淘搶購中，在Frame 2上點擊一個商品，會在Frame 3上顯示一個詳情；在Frame 2上點擊另一個商品，在Frame 3上就會顯示另一個詳情。
 
  
 
  
 
 
  
三維(Z+X+Y)導航模式
 
  
 
 
  
如果你沒看懂前面說的二維(Z+X)導航模式，那就goto前一章節重新看。如果看懂了，那下面的東西就很容易理解了，就是在那個基礎上多加了一維Y軸導航。
 
  
咱們還是看圖說話吧，請看下圖：
 
  
 
  
 
 
  
從上到下，一共三層（可以是N層）淡藍色的面板，每一層表示一個scenario的內部navigation，這一點與前面說的二維導航模式相同，只不過是多了一個frame 4。具體用幾個frame，是由這個App的Scenario決定的，原則上講，用的Frame的數量越少，對系統的performance越有利，code寫著也會簡單些。
 
  
淡藍色的面板的數量是隨著用戶navigation的深入而增加的，隨著按下back鍵而減少的，可以把藍色的面板定義為Scenario類。在下面這張圖中，用戶首先在最下面的Scenario A中暢游了6個頁面(A1,A2,A2',A3,A4,A4')，其中A1->A2做了X軸導航，也就是切換了Frame；在Frame 2中做了Z軸導航，然后從A2->A3做了X軸導航，然后再次X軸導航到A4，在Frame 4中做了最后一次Z軸導航之后，發現了一個神奇的按鈕，切換到了Scenario B，也就是到了第二層面板。以此類推，最后到了Scenario C中，又搞了一些事情。
 
  
此時，在Frame 1的導航歷史中，有3個頁面，A1/B1/C1；在Frame 2的導航歷史中，有7個頁面，A2/A2'/B2/B2'/C2/C2'/C2"；在Frame 3的歷史中有個3個頁面，A3/B3/C3；在Frame 4中有7個頁面，A4/A4'/B4/B4'/B4"/C4/C4'。
 
  
用下面兩個類可以表示以上數據模型:
 
  
public class Scenario
{ 
        public FrameSlot HomeSlot; 
        public FrameSlot ListSlot; 
        public FrameSlot DetailSlot; 
        public FrameSlot ChatSlot;

        public Scenario(Frame scenarioFrame, Frame listFrame, Frame detailFrame, Frame chatFrame, string url) 
      { 
                this.HomeSlot = new FrameSlot(scenarioFrame); 
                this.ListSlot = new FrameSlot(listFrame); 
                this.DetailSlot = new FrameSlot(detailFrame); 
                this.ChatSlot = new FrameSlot(chatFrame); 
                this.Url = url;
        } 
}
public class FrameSlot
{ 
        public Frame frame; // current frame
        int depth = 0; // navigation times 
}</code></pre> 
  
在Scenario類的初始化函數中，從外面指定了Frame的實例，也就可以保證不同的Scenario實例可以共享同一組Frame。
 
  
而這些Frame，可以這樣在XAML中定義：
 
  
<Grid x:Name="gridRoot" SizeChanged="gridRoot_SizeChanged">
        <Grid.ColumnDefinitions>
        <!--vertical menu bar-->
                <ColumnDefinition Width="64" x:Name="menuColumn"/>
                <ColumnDefinition Width="*" x:Name="contentColumn"/>
        </Grid.ColumnDefinitions>
        <localControls:VerticalMenuBarControl2 x:Name="menuBar" Grid.Column="0"/>

        <!--for content page-->
        <Canvas x:Name="panel" Grid.Column="1">
                <Frame x:Name="homeFrame" Canvas.ZIndex="10"/>
                <localControls:VerticalSeperatorControl x:Name="listSep"/>
                <Frame x:Name="listFrame" Canvas.ZIndex="20"/>
                <localControls:VerticalSeperatorControl x:Name="detailSep"/>
                <Frame x:Name="detailFrame" Canvas.ZIndex="30"/>
                <localControls:VerticalSeperatorControl x:Name="chatSep"/>
                <Frame x:Name="chatFrame" Canvas.ZIndex="40"/>
        </Canvas>
</Grid> </code></pre> 
  
 
 
  
從XAML中可以看到，最左側是個Vertical Menu Bar；右側是個Canvas面板。之所以使用Canvas面板，是因為這個panel類型最簡單，可以任意調整里面Frame的位置。其它的panel，如Grid, StackPanel, RelativePanel等等都有自己的一套Arrange Children的算法，我們并不需要。當然，你也可以自己從panel類派生出一個MyTaobaoPanel類，來組織這4個Frame。
 
  
好了，到目前為止，我們經過需求分析，找出了合理的模型，制定了基本類和界面邏輯，下面可以著手開發了……此處略去10000字的開發過程……最后的樣子如下面的截圖所示：
 
  
主頁：
 
  
 
  
 
 
  
在主頁上點擊了淘搶購：
 
  
 
  
 
 
  
在淘搶購中點擊了第一個商品：
 
  
 
  
 
 
  
在詳情中點擊了旺旺：
 
  
 
  
 
 
  
在詳情中點擊了店鋪：
 
  
 
  
 
 
  
在左側的超級菜單中點擊了我的淘寶：
 
  
 
  
 
 
  
在我的淘寶中點擊了設置：
 
  
 
  
 
 
  
頁面太多了，上百種navigation的組合路徑，一網打盡！
 
  
現在各位看官可能明白了，“四核”指的是4個Frame參與頁面展示與導航，”三維“指的是在三個維度上的導航方向，一維是在一個frame上的Z軸棧式導航，二維是在兩個frame以上的橫向導航，三維是在兩個Frame以上的橫向導航，再加上虛擬層之間的Y軸導航，切換場景相當于OS的進程切換，只不過是棧式的。
 
  
孔子還說："完美的抽象不能決定軟件的成功與否，但能判別開發者的素質。"
 
  
老子也說："好的開發者是一個軟件成功與否的基石。"
 
  
莊子說：……哎，讓莊子喝口茶水吧，實在編不下去了，意思你們都知道的，大家努力提高自己的職業素質吧，多學習，多觀察，多思考，多實踐，更好地抽象這個世界。
 
  
來自：http://www.cnblogs.com/ms-uap/archive/2016/03/28/5306123.html