4. 兼容舊版本

FDS最常見的問題之一是如何與Fall Creators Update之前的版本兼容，其實做起來也挺簡單的，ColorfulBox就實現了Creators Update與Fall Creators Update之間的兼容。

4.1 使用HamburgerMenu代替NavigationView

UWP Community Toolkit中的HamburgerMenu是以前制作漢堡包導航菜單最常用的方案，升級到2.0版本以後它會判斷運行的Windows版本，如果是Fall Creators Update則加載基於NavigationView的ControlTemplate，反之則加載默認ControlTemplate。控件內源碼如下：

if (menu.UseNavigationViewWhenPossible && HamburgerMenu.IsNavigationViewSupported)
{
    ResourceDictionary dict = new ResourceDictionary();
    dict.Source = new System.Uri("ms-appx:///Microsoft.Toolkit.Uwp.UI.Controls/HamburgerMenu/HamburgerMenuNavViewTemplate.xaml");
    menu._previousTemplateUsed
 
 = menu.Template;
    menu.Template = dict["HamburgerMenuNavViewTemplate"] as ControlTemplate;
}

4.2 使用條件XAML

Reveal樣式只在Fall Creators Update中提供，如果XAML中使用了Reveal樣式，項目在Fall Creators Update前的版本運行將會報如下錯誤：“Cannot find a Resource with the Name/Key ButtonRevealStyle [Line: 396 Position: 9]””。

對這種情況可以使用條件 XAML。

條件 XAML 提供在 XAML 標記中使用 ApiInformation.IsApiContractPresent 方法的一種途徑。它從Creators Update開始提供。 若要使用條件 XAML，Visual Studio 項目的最低版本必須設置為內部版本 15063（Creators Update）或更高版本，且目標版本設置為比最低版本更高的版本。

上面這種情況，可以在XAML中添加條件命名空間：

xmlns:fcu="http://schemas.microsoft.com/winfx/2006/xaml/presentation?IsApiContractPresent(Windows.Foundation.UniversalApiContract,5)"
xmlns:cu="http://schemas.microsoft.com/winfx/2006/xaml/presentation?IsApiContractNotPresent(Windows.Foundation.UniversalApiContract,5)"

然後使用條件命名空間前綴設置屬性：

<Button fcu:Style="{StaticResource ButtonRevealStyle}"/>

上面這段XAML中 Style="{StaticResource ButtonRevealStyle}" 只在Fall Creators Update中生效，不影響以前版本。

4.3 使用版本自適應代碼

對於Creators Update之前的版本，可以使用ApiInformation類創建版本自適應代碼。

if (ApiInformation.IsApiContractPresent("Windows.Foundation.UniversalApiContract", 5))
{
    var frameworkElement = Window.Current.Content as FrameworkElement;
    return frameworkElement.ActualTheme;
}
else
{
    var frameworkElement = Window.Current.Content as FrameworkElement;
    return frameworkElement.RequestedTheme;
}

ApiContract的主版本號見下表，從RTM開始到秋季創意者更新的版本號分別為1到5。

5. 其它常見的問題

5.1 為什麽Acrylic和Reveal沒有生效

在幾種情況下這兩個特效不會生效，AcrylicBrush變成純色不透明的Brush，應用了ButtonRevealStyle的按鈕變成普通的按鈕。

• 電腦電量不足，或開啟了“節電模式”；
• 運行於低端硬件；
• 在“設置\個性化\顏色”中關閉了“透明效果”選項。
  

除此之外還有一個常見的情況：在沒激活的Windows 10上Acrylic和Reveal都不會生效。大概和Windows7沒激活時不能開啟Aero一樣。

5.2 錯誤使用Acrylic

Acrylic有些難用，一般來說Acrylic只應該作為背景使用在菜單、彈出遮罩或Flyout等，程序的主體區域的背景不可以使用Acrylic。如果在應用在整個應用的背景使用Acrylic，除了使整個應用十分晃眼（以及程序員的自我滿足）外沒有任何積極意義。

作為例外，Widget或輕量級應用可以在整個應用的背景使用Acrylic，像計算器應用那樣。

不要在使用了Acrylic的地方使用Accent Color作為文字的Foreground，看不清的。WindowsTemplateStudio在這點上也犯了錯誤。

5.3 錯誤使用Reveal

簡單來說：

• 只應該在可操作的元素上使用Reveal。
• 不要在孤立的元素上使用Reveal。
• 不要在大面積的元素上使用Reveal。
• 靜態元素（例如文字和背景）不應該使用Reveal。
• 不應該讓Reveal幹擾重要的信息。

不在靜態元素、孤立元素、大面積元素上使用Reveal，這倒不是為了性能考慮。光照一直是設計師夢寐以求的元素，它有其應用場景，不應該亂用導致UI雜亂無章。Reveal最大的作用是為一組元素提示其可操作區域，例如ListView，NavigationView，或類似計算器應用上的無邊框按鈕。如果整個UI都用上Reveal，對重要信息反而是種幹擾。

6. 如何評價Fluent Design System

6.1 過去

Zune和WP的時代，局限於設備性能及屏幕尺寸，微軟提出了MetroUI，提倡了扁平化設計、移除多余裝飾元素，既好看又好用。

Windows8時代，微軟將MetroUI搬上桌面，依然十分好看，可各種問題馬上浮現：

• MetroUI不能承載復雜信息，而且由於要顧及觸摸操作，所有元素都設計得很大，導致UI顯得更加簡陋。
• 在觸屏時操作十分自然舒適的各種操作（典型的如橫向移動）到了桌面的鼠標的操作變得十分別扭。
• MetroUI是一種難度很高的UI，在WP時代有大量讓人驚艷的應用，但後來微軟為了提高應用數量放松了大量粗制濫造的應用的驗證，大大拉低了Metro的評價。
• 微軟自己都不清楚應該怎麽使用MetroUI，更別提對它進行改進。
• 為保證桌面和手機有相同的步伐，結果就是更新緩慢。

本來這些問題一直都存在，只是以前應用少用戶少，而且沒有跨設備，也沒有強制用戶使用Metro，所以問題不明顯。Windows8讓這些問題一口氣爆發，種種錯誤導致一個超前的UI慢慢落後。

但這不妨礙大量模仿MetroUI的桌面應用和網站，從這方面來看MetroUI本身還算是成功的。

Windows10時代，ModernUI代替了MetroUI。這時手機市場已經可以忽略不計，放棄了各種Metro的特色後，勉強拼湊起來的ModernUI在Windows10桌面上運行起來還不錯。但沒有特色的ModernUI已經沒有人去模仿了。

6.2 現狀

微軟現在需要解決ModernUI的各種問題，他需要一個能跨設備，可持續發展，精雕細琢，適應各種輸入輸出而且又很好看的UI。自從提出FDS到現在都已經不短時間了，FDS還只是一個很美好的願景，沒什麽出彩的應用，而且大致上就只是現在的UWP換了個發光發亮的皮膚，沒變得更好用，不滿意的地方倒是一堆。

例如我就覺得Reveal樣式的按鈕婆婆媽媽拖拖拉拉軟軟綿綿的沒有手感，Pressed狀態慢悠悠做動畫，而鼠標釋放後再次慢悠悠地做動畫，幾秒後才回到PointerOver狀態，這使整個操作看起來反應遲鈍。按鈕的天職是反應迅速，這樣才能給用戶愉悅的操作感受。單獨地看這個按鈕樣式的話除了炫技術還不如普通按鈕，希望以後可以改進吧。

另一方面，微軟的宣傳也有問題，現在很多媒體還將Acrylic說成Aero回歸，明顯是微軟改名部不給力，起什麽名不好，偏偏弄個這麽復雜的英文。

不得不再次點名批評改名部，看看以前Lumia、Aero、Metro、Modern，個個都好讀好記；Fluent Design System什麽鬼。

文檔方面，Material Design有很詳細的使用規範、指導原則，而且有面向設計師的文檔，而FDS還太過空泛，文檔主要是面向開發者的，各種規範分布在UWP的開發文檔中。

我覺得暫時來說，在設計師們還沒有完全上手以前，只要規規矩矩用上新的Style、Brush、控件就可以讓應用很好看了，可惜現在不少聲稱使用上FDS的應用為了炫技把各種新Control、新Brush、新Style用得亂七八糟還沾沾自喜。連微軟自家的應用都不爭氣，例如我以前吐槽過的Mail應用，它還出過新聞高調宣傳自己已經適配FDS了，結果好處沒看到多少，倒是一大堆舊毛病都不處理。我還記得Windows8剛出的時候對官方應用感到十分驚艷，可惜現在的官方應用很多連基本的用色和對齊都沒做好，都足夠做反面教材了。

6.3 未來

通過FDS的五個主題可以看出FDS的一個主要目的是讓數字內容通過設備與真實世界鏈接，這是個很好的願景。文章開頭介紹的視頻中展示了ParallaxView在MR中運行的效果，效果有趣很多：

即使只在桌面上運行，FDS也激發了不少創意。例如這些設計:

相比起當年MetroUI在桌面上後勁不足，FDS看起來有很長遠的發展計劃，雖然現在還有各種問題，相信以後能給我們更多的驚喜。

7. 結語

上一篇文章承諾過盡量寫短一些，但這篇文章的主題是個很龐大的話題，即使長話短說也短不了多少，所以分成兩篇發布了。

其實比起各種新控件新特效，我更希望FDS給出一個大的設計準則，一個嚴謹又包容多樣性的規範。這幾年隨著Windows不再強勢，設計師好像突然就忘了在桌面上怎麽設計了。前兩天看到一個運行在Windows上的系統的設計，系統的第一版和第二版都保持著“確定、取消”的按鈕順序，到最近的第三版就突然變成“取消、確定”，大概因為設計組的大佬們這兩年都換了MacBook，而平時看的UI文檔都是Google和Apple的，誰叫微軟沒有給設計師看的UI指導文檔呢(如果不算這份古老的文檔的話)。

本來關於Metro我還寫了很多，但都刪除了。寫博客是為了傳播新知識，無意為已經死去的Metro引起口水戰。而且我對FDS已經喋喋不休抱怨了很多，再寫下去就更像怨婦了。

當年也曾熱衷於在桌面上使用Metro，但現在對在WPF上使用FDS沒什麽興趣。何況這個主題是討論UWP中額FDS，不太想涉及WPF。上一篇文章的評論裏提到FDS其中幾種元素在WPF上的實現，有興趣可以參考一下。

8. 參考

Fluent Design System
Fluent Design System for UWP apps
Reveal highlight
Acrylic material
Connected animation
ParallaxView
Navigation view
Conditional XAML
如何評價微軟在 Build 2017 上提出的 Fluent Design System？

9. 源碼

Fluent-Design-System-Sample
Colorful-Box

[UWP]如何使用Fluent Design System (下)