中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

作為一名Google新員工（原文noogler，即New Googler，Google內部用語），這次經歷告訴了我Chrome瀏覽器設計是如此復雜之又復雜。也給我迄今為止所有涉及的決策上了一課。

這個九月初，新的Chrome核心UI或者說“Chrome MD”（for Material design）在windows上的第53次更新中上線了。這項新設計經歷了三步發(fā)展過程，先是在Chrome OS和Linux上的51版本上，接著是macOS上的52版本，windows上的53是最后一步。最后一步是這個過程的迭代高峰，但是chrome的迭代從不會停止。對于我來說，偶爾回過頭拿出來看下這個過程，原來恍然已經過了接近兩年的時間。在這里我提供一些設計上的細節(jié)和經驗希望對你有所幫助。

如果你讀過我的上一篇文章Redesigning Chrome for Android，那么這篇跟上一篇是有些類似的，雖然我嘗試在保持技術細節(jié)輕量化上有點失敗……當然這次它只是其中的一部分。如果你還沒有閱讀上一篇文章，那么我建議你可以去閱讀一下，因為它也是桌面版Chrome思考過程中的一個完整部分。

A bit of background

我負責Chrome和Chrome OS的視覺設計快5年了，在過去的一年里，我越來越趨向專注于Chrome OS的瀏覽器和操作系統(tǒng)了。時間回溯到2012年，作為Chrome團隊新成員，第一個大項目就是使新的Chrome核心UI在高分辨率顯示上也能兼容，比如第一代Macbook Pro Retina和Google版本的retina顯示——第一代Chromebook Pixel。Chromebook Pixel預計是在2013年2月發(fā)布，比Macbook Pro稍晚了一點。

作為一名Google新員工（原文noogler，即New Googler，Google內部用語），這次經歷告訴了我Chrome瀏覽器設計是如此復雜之又復雜。也給我迄今為止所有涉及的決策上了一課。

當時我們的目標不僅僅是要給即將推出的新屏幕分辨率和密度比（1x和2x）帶來新設計，還要重新思考通過組織我們的工作流程和資源庫使我們與工程開發(fā)的合作更容易。

這種需求在為了使Chrome設計過程變得面向未來中的必要性逐漸增加。Chrome自從誕生起，快節(jié)奏的迭代讓我們沒有太多時間去整理一些東西，我們越是前進（更新版本），越是難于遍歷之前我們的工作結果，導致了創(chuàng)建延遲和設計債。

經過了幾個月的工作，帶有正規(guī)屏幕分辨率的閃亮?高識別度新設計出爐，下面是他們的樣子：

我趁機把我們整個資源庫存（大約1200張位圖）整理一下以便以后使用更快捷。這應該會在將來會派上什么用場。這種設計或多或少大概存在了4年，直到2016年4月為Chrome OS設計的Material Design風格的Chrome推出。

Timing and planning

現(xiàn)在Chrome支持高分辨率屏幕，我們的流程問題已經解決，團隊正在變得相當有效率，是時候向移動端轉向注意力了。
2013年剛開始的時候，Chrome還不是Android系統(tǒng)的默認瀏覽器，沒有平板版本，只是剛剛在iOS上發(fā)布。也是從那開始，移動端成為我主要的關注焦點，Android上的MD樣式Chrome也是2015年才開始做的，但是這不意味著（這幾年中）從未在桌面版Chrome瀏覽器上發(fā)生過什么改動。

有意思的是，我們看到臺式機/筆記本電腦都轉換到一個新的使用場景，即觸摸屏不再是移動端平臺的專屬，而是出現(xiàn)在更多平臺上比如筆記本電腦。雖然前幾年也有一些嘗試，但這還是第一次筆記本電腦擁有觸摸屏看起來比一些所謂噱頭和探索更現(xiàn)實一點。

對于Chromebook Pixe我有很密切的經驗，但是win8則讓我失去了很多興趣，它們強有力的承諾卻傳達給我們一套自以為是的UI在一款新的，混血的，作為一款hero級別的設備Surface上。

第一代帶有高分辨率觸摸屏的Chromebook Pixel

第一代微軟surface和win8的“Metro?mode”

操作系統(tǒng)的雙重性，以及為所有可觸摸和不可觸摸設備設計一個易于觸摸行為的UI，使我對Chrome UI在這種環(huán)境下的位置和方向產生了思考。由于Chromebook Pixel帶有觸摸屏，我們已經著手面對這類問題了，但依賴觸摸操作的只有內容滾動和一些次級操作，觸摸并不是主要的輸入方式。而Pixel的定位作為一個實驗性的“發(fā)燒友”級的設備允許我們花時間去思考，我們的UI為什么和怎么受到了哪些影響？

一段時間后，我們決定做出一種成為今天“混合模式”（Hybrid mode）的先導設計——Touch-view。

Touch-view是在正常核心UI上做的改進，讓核心元素之間的間距更大，以控制用戶錯誤觸摸操作次數(shù)，并部署在Chromebook和win8系統(tǒng)上。

這是一次有趣的實驗，但是它沒有持續(xù)太長時間，touch-view在windows上迅速被取消而且win8本身也被重構，不知道發(fā)生了什么事變成了win10（笑），這一瞥對于前沿發(fā)生了什么來說已經足夠了：筆記本電腦與平板電腦之間“混合”與“轉換”的界限越來越模糊了。

Adapting to an upcoming and growing device category: hybrids

2014年年底，系統(tǒng)設計領域發(fā)生了很多事情。Apple宣布了Yosemite系統(tǒng)，UI風格在于macOS和iOS7之間那樣，Lolipop也推出了，采用了Google新的視覺語言：Material Design。

設計風潮不斷變化，雖然大多公司都在按照自己的視覺準則設計，但是一個共同的命題正在形成：“擬物化”時代結束了，被一種留白更多，陰影變輕的輕量化UI所代替，正是我們熟知的著名（臭名昭著）綽號——“扁平化設計時代”。

Windows有它的“Modern UI”，Apple有它的“iOS UI”，Google則有“Material Design”。作為大更新的一環(huán)，Chrome需要對Android和iOS做移動端的適配。

我們得對我們濃重的陰影，高光和漸變上的一些冗雜的效果說再見，我們使標簽更尖銳，選擇了一套與Google設計原則一致的圖標。新的Chrome在這……但還不是桌面版的。

The new Chrome MD on tablet

桌面UI的未來正在慢慢地走上清晰化的道路，一邊Windows和Google在試圖尋找一種能夠立即處理適應所有屏幕尺寸和格式的設計系統(tǒng)，另一邊Apple還在固執(zhí)的為每一種平臺和格式設計布局導向（可觸控的iOS，不可觸控的macOS）。正是兩年前的那個時候，是Chrome重設計過程的開始.

The Hybrid layout type

在我為Chrome工作的這幾年里，有一件經常而又不平凡我必須注意到的是大多數(shù)設計師要處理應對其實是他們的設計資產管理。這么說有一個原因是之前提到的要組織整理我們大約1200張位圖，除了這個過程帶來了難以置信的樂趣，他也是當你跨平臺工作的必要過程。

從前端工程角度來看，Chrome拓展延伸到4個框架：Windows,Chrome OS and Linux上的Views（我們的框架去構建UI），macOS上的Cocoa，Android上的Java，iOS上的Obj-C/Swift。

為了保持對設計資源長期而有效地管理，我們試著分享盡可能多的跨平臺設計資源。例如Windows, Chrome OS和Mac有許多共享的視覺效果，他們的實現(xiàn)方式可能是不同的但是最終顯示的位圖是一樣的。然而在移動端上Chrome和Android有很多不同的地方，我們也試著去設計和思考兩者可被用作跨平臺的資源。平板上的Chrome就是一個非常好的例子，無論你是在ipad還是Android平板上運行Chrome瀏覽器，他們都是長得非常相似。

Chrome for Android and Chrome for iOS 9 (MD)

Chrome for Android tablet (MD)

Chrome for iPad (MD)

當然，這其中也有很多平臺所屬的特定資源，但也是有共享上限的。當你要處理多種倍數(shù)（multipliers）和樣式元素(或布局類型)時，這依然會變得很棘手。在考慮混合這些之前，如下圖所示：

正如你所見，分為兩種布局類型：觸摸和非觸摸。

在這兩種布局類型中有兩個核心倍數(shù)（1x和2x），拓展到各個平臺可以有5到6個倍數(shù)：

• 移動端 – 100, 150, 200, 300, 400
• 桌面端 – 100, 125, 150, 180, 200, 225（極端情況下）

有如此多的倍數(shù)下的設計需要去做以至于最后我們不得不依賴與縮放奇數(shù)倍資源來創(chuàng)建，比想象中少了很多工作。這種情況下，隨著可觸摸和可轉換設備的需求與日俱增，我們不得不為可轉換型設備找出解決方案，通過觸摸視圖的啟發(fā)我們將之命名為“Hybrid”，現(xiàn)在的結構也變得更加復雜：

這有可能創(chuàng)造出一份新的設計資源來導出管理，并遠超出它的限制推動我們目前基于過程的位圖（創(chuàng)造）。

現(xiàn)在該到程序化渲染出場的時候了。

New layout type, new process

Chrome的“混合模式”原本就是為Chromebooks設計的，靈感來自于我們上一次所做的“觸摸視圖”。這一次我們打算針對“混合模式”重新設計，而不是作為現(xiàn)有UI的一種額外補充。
為了達到目的，我們需要做到這兩件事：

• 設計上必須足夠靈活以適應常規(guī)模式和混合模式。常規(guī)模式最初是被部署在我們用戶基礎上絕大多數(shù)的最大那一部分。
• 一種可以創(chuàng)建、導出和實現(xiàn)我們設計資源的方式，并且可以優(yōu)雅地在大多布局類型和桌面的PPI環(huán)境中縮放。

我們第二個問題的解決方案是通過Peter Kasting，Evan Stade和Terry Anderson（項目的技術主管）的努力誕生的。
其實最開始我是不相信圖形渲染（特別是chrome的標簽Tabs）和圖標完全以程序化方式達到我們用.png提供細節(jié)水平。事實上我錯了。

Chrome正在使用Skia圖形庫。經過幾次嘗試后，Peter已經能夠不使用位圖而完美呈現(xiàn)一些Chrome的關鍵元素（如標簽頁和多功能地址欄）。另一邊，Evan做了一個轉換器，可以將.svg代碼轉換為skia代碼。.svg本質上已經作為一個藍圖，一組用于代碼呈現(xiàn)的指令。

于是，整個（新的）設計工作流程被如下定義：
設計師創(chuàng)建任意尺寸大小的.svg作為Skia代碼渲染的模板，這些適用于圖標和圖形，然后開發(fā)們將采用這種模板使用Skia在Chrome中實現(xiàn)。

下面是標簽頁的一些示意圖：

標簽頁是由填充和描邊兩部分.svg組成，開發(fā)們拿著.svg代碼轉換到SKIA代碼改變路徑并設置相應的顏色和透明度。

這里有一個示例圖標的代碼預覽，Evan用自動轉換器把它們放到了一起：

這種技術使Chrome中的位圖數(shù)量大幅度減少，從大約1200張到……0張。要記住的是，現(xiàn)在所有不同的按鈕都是通過代碼來處理的，包括任何鼠標經過和按下狀態(tài)以及其他需要直接應用顏色的地方都是用代碼來處理的。

相對比直接使用.svg的優(yōu)勢，我們可以在每種PPI控制每個元素的渲染。這意味著如果有需求的我們可以創(chuàng)建稍微不同于1x和2x的圖標，這是一個較大的代價因為桌面端最主要的還是1x。此外我們也可以在帶有小數(shù)的倍數(shù)中控制渲染，例如1.5x、1.25x……使Chrome在一些奇怪的PPI中也看起來無異。

有了這個新的出色工具到位，是時候設計和實現(xiàn)新的UI了。

Visual consistency and design details

桌面UI的重新設計并不是要從頭開始，而是橋接我們在移動設備上的新設計語言和比較久的桌面視覺之間的差距隔閡。有一個問題我認為在所有Chrome視覺設計師的腦海中都會想過：“是什么造就了Chrome，Chrome？”

定義Chrome是什么的東西有很多，但同時，我們的作用是為了隱匿在有利的內容之中，換句話說，它確實存在，但并不是以方式形式存在。

正如你所想的我們核心UI的關鍵元素是標簽（tabs）與圖標（icons）。移動端的Chrome已經在平板上用上了新的尖銳的標簽邊緣，圖標也換為遵循了Material design準則的圖標系統(tǒng)。這種情況下，我們的目標是：

• 給桌面端帶來新的尖銳型標簽
• 使用桌面端尺寸制作出一套MD圖標
• 整理和簡化我們的調色板和主題系統(tǒng)，為桌面端帶來新的“暗色”隱身模式
• 開始修改一些次要的UI元素，比如按鈕、工具欄、氣泡等等
• 為一些可轉換設備設計一種更易于觸摸的Chrome版本
• 為第三方系統(tǒng)提供一套一致的原則
• 盡可能去實現(xiàn)MD動效

General layout and UI footprint

當設計Chrome的核心布局時需要記住一個關鍵的事：UI覆蓋區(qū)（UI footprint）。這是用來顯示我們UI的確切數(shù)量上的像素，或者換句話說，這是我們從內容中“拿走”的像素數(shù)量。

不顯示書簽欄時，pre-MD版的Chrome設計高度在ChromeOS和macOS（包括窗口邊框）上為73px，在Windows上為78px（當然也包括邊框）。Windows上的自帶框架要比ChromeOS和macOS高，以更大的覆蓋區(qū)為代價更易點擊和選取。參照下面Windows和macOS的比較：

上個版本Chrome工具欄布局是在高PPI的屏幕還沒存在時創(chuàng)建的，所以它在100%的比例下渲染效果優(yōu)化很好，使用了奇數(shù)所以還能在完整像素上居中元素。

第一件需要做的事情就是規(guī)劃出一個均等的表格，以便在各種倍數(shù)上管理布局，基于奇數(shù)的設計網(wǎng)格，這樣圖標可以落在像素網(wǎng)格上。
Material design中使用8pt作為基線，我們這里使用更小的一半：4pt。以4pt為增量設置網(wǎng)格和定位元素可以獲得一個良好的平衡，并能保持布局、圖標和排版一致。為了實現(xiàn)平衡，我們將UI分為兩部分：標簽頁（tabs）+窗口框架/工具欄（window frame / Toolbar）。

下面是常規(guī)UI的外觀：

正如你所看到的這個在ChromeOS上的Chrome MD預覽，工具欄被分為兩部分，均為36pt，每個核心元素都落在了4pt網(wǎng)格上。標簽頁高28pt，等同于多功能地址欄高度。我們在標簽頁和框架頂部預留了8pt填充高度。

如果你仔細觀察，你可以注意到多功能地址欄的邊框未和網(wǎng)格對齊。因為我們巫師PPI使用了1px線寬，以這種更細的描邊表現(xiàn)更輕量的UI。然而這種技術的缺點是你總是需要去記得原來用更厚的2px描邊現(xiàn)在應該是一個空位置。

你可能還會注意到，我們在工具欄底部添加了1pt來渲染描邊，不是為了平衡，而是實打實的在總高度上添加1pt。

上邊的是我們的混合模式UI（hybrid UI）。

對于混合模式，我們保持了框架的上填充8pt，同時增加標簽頁和工具欄覆蓋區(qū)4pt，即跟過留白的40+40布局。你可能疑問為什么在這點上我們不匹配Android和iOS尺寸建議（分別為48和44）使其更易觸摸。我們也確實去嘗試做了，但是卻違反了我們設計混合模式的初衷。

我們的目標是在全觸摸與非觸摸間選擇一個折中的解決方案。盡量平衡減少觸摸失誤發(fā)生的錯誤，而不會影響從筆記本電腦上布局預期的各個方面的生產效率。

在桌面端上，每個像素都算在內把平板的UI提供給筆記本電腦使用是不可能的。

下圖是Chrome pre-MD、常規(guī)的Chrome MD布局、混合模式和平板上觸摸布局比較，都是200%渲染（Android上的xhdpi）：

實際上，MD布局包括窗體框架的正常占用空間要比他的ChromeOS/macOS pre-MD版高2px（71 vs 73），然而因為我在新UI窗體框架上上移3px，不算上窗體邊框我們實際得到的UI是多5px高（60 vs 65）。

每一個像素都對Chrome很有價值。重設計情況下，所有的尺寸都會受以下因素影響：UI繼承，新網(wǎng)格的采納以及整體上的UI平衡。

這套邏輯同樣適用于圖標……

Iconography

在這上面的選擇是根據(jù)圖標用途快速制作。
我們需要改進我們大量的核心圖標，以及所有產品上的功能圖標，Material design圖標庫對其提供了這一點。
這樣，我們移動端上的圖標也會得到一致，包括Android和iOS.

然而，問題在于網(wǎng)格尺寸?；?4x24pt網(wǎng)格的圖標不適合我們打算創(chuàng)建簡潔的UI。畢竟他們最初是為移動端標準準備的。我們需要得到一種網(wǎng)格尺寸能適應我們新的常規(guī)和混合模式UI。為了這么做匹配4pt網(wǎng)格，我們使用了如下圖基于16x16pt的圖標：

我們將容器從24pt減小到16pt，并在原來圖標的內填充上做了些改動：2pt變?yōu)?pt到2pt，具體數(shù)值取決于Chrome圖標網(wǎng)格。選擇這種可變的內填充方式是考慮到以后我們將要使用各種圖標，一些圖標可能需要額外的空間以在小尺寸上依然保持可識別性。

這種直接在尺寸上減小33%的優(yōu)勢在于我們可以直接從Material design圖標中提取，這可以大量的節(jié)約我們的時間，但一些圖標的渲染并沒有太對齊網(wǎng)格，因此會略有模糊。

雖然這樣在次要圖標上也表現(xiàn)不錯，但我們所有比較突出的圖標必須貼合像素正確地渲染出來。為此，我們得（重新）創(chuàng)建防止它們沒有對其網(wǎng)格，特別是較低的PPI上，如下：

正如你所見，自從我們可以控制在任何PP上渲染，我們移除了一些縮放導致的圖標模糊性。我們還讓圖標的描邊更細一些（100%上為2px，200%上為3px，原來則是100%上為2px，200%上為4px）之前我認為原來的太厚重了，這樣它們在新UI中可以更優(yōu)雅和平衡。

這種既能提供靈活性又能控制設計資源的技術大大降低了我們的維護成本。巨大的設計資源對于我們團隊能節(jié)省巨大的時間，使我們能夠更快的進行迭代而不用等設計師做一個新圖標出來。最后，他還為桌面端和移動端帶來了視覺上的一致性。

由于這些都是一代碼形式渲染的，我們刪除了所有復雜的顏色，只需提供黑色的.svg并在代碼中指定顏色。程序化渲染的另一個好處就是我們能在需要時（例如阻止一些拓展和權限）剪切和標記圖標，而不是將阻止類型的和非阻止類型的圖標單獨導出位圖。

如下圖的過程所示：

下圖則是帶有顏色和標記的圖標預覽，體會一下整體上的感覺：

現(xiàn)在圖標創(chuàng)建完畢，讓我們繼續(xù)看看他們是如何適應新UI的。

Touch targets and layout

由于圖標都是基于16x16pt布局，它們可以完美的適配在4pt網(wǎng)格布局上，但是UI上的間距和位置對于常規(guī)和混合模式上觸摸/點擊目標的合適大小是個問題。在常規(guī)模式下，我們使用28x28pt的觸摸區(qū)域，嵌套著16x16pt的圖標。當然，下面的布局（ChromeOS中的Chrome）在所有平臺都是一致的。

對于混合模式，我們必須做出UI版本迭代多少的讓步。我們想為用戶提供更多的空間，同時保持緊湊的布局。這也是為什么正如下面你所看到的一些元素之間會有隔斷間距。

由于我們還在嘗試這種布局規(guī)則，所以我們有一點保守。在制作這個布局中我們一直重復思考的是，用戶只使用鼠標時不能感覺到太多不舒服的地方，不應該浪費留白空間。

我們首先專注于增加元素高度，而且標簽頁和多功能地址欄這兩處棘手的的地方已經定下來了，我們將他們都從28pt增加到32pt。此外我們還使用了一種技術增加了標簽頁的觸摸面積，加高了8pt到框架本身中去。雖然圖標都保持了28x28pt大小，但是我們增加了它們的邊距到8pt，以給UI更多空間和減少觸摸錯誤。同樣這也適用于多功能地址欄中的擴展和權限圖標以及外部的擴展程序圖標。

你可以注意到，即使間距更改了，圖標卻依然保持大小一致，依然是16x16pt的圖標。這可以使我們對設計資源的維護成本最小化，長期可拓展化以及迭代更容易。下圖為完成的混合模式：

一開始設計一個布局是一件很容易的事，多年之后依然可以維持和兼容，這才是最初的布局規(guī)劃所取得的成功之處。

將所有圖標以相同尺寸對齊極大的簡化了我們的設計和維護過程，還可以使設計更整齊和優(yōu)雅。以前的非MD圖標是在幾年間設計的，很難保持一致大小。這一次我們甚至更新了我們的擴展程序圖標用16×16代替19×19.
我們也重定義了數(shù)量標識的視覺，和我們用來阻止權限的圖表一樣采用了相同的裁剪技術。

最后，對于喜歡總是展示書簽欄的用戶，我們調整使其不會超出布局或者不平衡。

參照下面的macOS的常規(guī)模式，Windows和ChromeOS的混合模式：

Mac這里在其常規(guī)的空間下附加了28pt以和工具欄上28x28pt的點擊區(qū)域匹配。

對于Windows框架我們附加了24pt高度來平衡額外空間，由于ChromeOS的實現(xiàn)方法和Windows一樣，因此均為一樣的數(shù)值。

由于我們還在ChromeOS上試驗這個布局，時間將會告訴我們這個介于觸摸與非觸摸的平衡數(shù)值是否成功。這就是為什么我們一直在Windows系統(tǒng)上默認提供常規(guī)布局，直到我們能夠更好的了解Windows用戶的需求和習慣。ChromeOS則是默認提供混合模式。

如果你想在Windows上嘗試下新布局，只需在地址欄輸入chrome://flags然后選擇里面的“UI Layout in the browser’s top chrome”項改為touch即可。

Omnibox, results dropdown and security indicators

在我們的多功能地址欄及其下拉布局設計中有兩個需要注意的：

• 重點強調網(wǎng)址安全狀態(tài)。
• 快速顯示你要訪問的信息或網(wǎng)址。

多功能地址欄可能是Chrome最重要的功能。那里是進行谷歌搜索、打開網(wǎng)頁、書簽以及歷史記錄的用戶入口，那也是唯一一個地方我們可以強調顯示一個域名的安全狀態(tài)，可以有效地試圖通過主動組織、被動指示和教育保護我們的用戶免受互聯(lián)網(wǎng)上無數(shù)的在線威脅。

為了達到這個目標，視覺設計師 Max Walker攜手我們的UX總監(jiān)Alex Ainslie在多功能地址欄中加入了全新的一個安全提示機制，如下圖：

安全的綠色的鎖狀態(tài)僅應用于安全的https網(wǎng)站，這些安全的域名使用了私密鏈接。

你可能還會記得幾年前的Chrome有一種黃色的安全狀態(tài)，這次，所有不完整的https和具有威脅的網(wǎng)站都會被標記為紅色。當谷歌知道該域名是詐騙網(wǎng)站時，我們還會完全阻止你去訪問。

與地址欄相聯(lián)系的還有下拉菜單和輸入查詢獲得的結果內容區(qū)域。在這次新設計中，下拉菜單沒有多大的變化。我們改變了圖標的顏色方案，但是我們這次的核心工作表現(xiàn)為：一個新的混合布局，更重要的是內聯(lián)搜索結果。

內聯(lián)結果（Inline answers），也叫“建議搜索結果”，本質上就是在你真正的按下回車鍵驗證查詢之前Google或Chrome顯示的你想要查找的信息。例如，當你在搜索框中輸入“weather in los ang”時，Chrome會顯示以下建議內容：

對于這個建議搜索，如果我們確定了你要查找的結果，我們會直接將它作為搜索的一部分直接顯示出來的。如下圖，它不僅能適用于天氣，也可以快速查詢、股票搜索和計算等。

下面的這是在常規(guī)模式下查詢結果樣式：

這里是另一種查詢結果（股票查詢）在混合模式中的布局，加大了行高度以方便觸控：

無論哪個平臺桌面版的下拉菜單總是顯示的非常緊湊，并在信息密度、清晰度和易用性之間達到平衡，以使用戶盡可能快的得到他們想要的結果。
就像其他的核心UI元素一樣，混合模式通過增加行高度減少誤觸行為，同時保持信息密度，以使用戶的瀏覽更有效率。

Colors and accessibility

除了布局密度因素，還有一個影響較大的因素就是顏色。
桌面版的Chrome MD經歷了和Android版Chrome同樣的變化，我們需要一個更加統(tǒng)一的顏色規(guī)范，以及更一致的，更易識別的顏色方案。

當然了，你打開Chrome時最明顯注意到的就應該是核心UI的顏色變化，平衡這些顏色是一個很需要很細心的任務，并超出了我之前最初的想法。

核心UI有三個關鍵元素：

• 基于系統(tǒng)本身的框架，每個平臺都有不同。
• 選中的選項卡和工具欄，包括很多附加在多功能工具欄的控件和標簽。
• 尚未選中的選項卡。

要做好這些，這三種東西要有一定的對比度。但不容易解決的是在不損失太多對比程度下如何讓這些設計更扁平化，更加現(xiàn)代化。
另一件我們需要思考的是主題（theme）。與移動端相反，桌面支持主題功能，我們需要解決這個問題，有可能的話我們還要加以改進。

最后，我個人最喜歡的（也是譯者最喜歡的）是，我們想讓隱身模式變得真的不同于其他，而不只是框架主題的改變。我們想改變隱身模式的全局主題，讓它變得暗一些，就像移動端一樣。

下面是每種模式的三種結構：

我們的核心UI顏色系統(tǒng)如下：

Mac和ChromeOS非常直接，我們可以直接控制框架的顏色，然后添加背景模糊在mac上。Windows就有點棘手了，因為用戶可以通過系統(tǒng)設置幾乎任何顏色作為其框架顏色。因此，我們就一直延續(xù)我們一直再做的不透明框架，無論你系統(tǒng)用的什么顏色。

參閱下面的比較，Mac和ChromeOS的不活躍標簽是不透明的，對于Windows我們則是將不活躍標簽和新建標簽填充降低到78%：

為了平衡新的顏色主題，我們這里大量依賴了描邊。因為描邊具有無視PPI的1px粗度，描邊在不透明度修改了多次以使它在1x看起來不是那么暗，2x里看起來不是那么亮。這些適用于正常模式和隱身模式。

Chrome macOS in 200% and 100%. Both strokes have a 1px?weight.

無障礙一直是Chrome的DNA一部分無論是合乎a11y的內容方面還是UI方面。過去的兩年里，我們一直在努力。但不可否認的是，現(xiàn)在我們的配色方案需要一個新的繼承，使其更簡潔，更符合WCAG 2.0規(guī)范的對比度。

還有我們可以確認我們的排版和圖標都至少達到了AA級別或4：5：1的對比度：

一個我認為不錯的測試對比度工具：http://leaverou.github.io/contrast-ratio/

直白了說，偶們的程序渲染方式可以基于對比度動態(tài)的著色圖標，這不僅可以使Chrome更好看，無障礙功能上也可以得到改進。如下圖所示，安裝了主題“Dark theme V3”后可以使圖標切換為白色，下拉菜單則為暗色。這些都是我們從程序化渲染和隱身模式中收獲的益處：

Motion

動效是人們在討論Material design所津津樂道的地方，特別是移動端。一個優(yōu)秀的動效可以讓一個App很搶眼，而且能使用戶更有效的使用它。只要你不做過頭，你作為一個設計師就可以為用戶提供一些趣味和引導，利用微妙的暗示來感知空間，還有清晰的UI運動。

但是當這種動效來到桌面端時，我們首先提到的則是鼠標、鍵盤和大屏幕的環(huán)境。這是一個有點不一樣的故事。

在桌面端平臺你可能會花費更多時間去移動（鼠標），通常這種產品工具需要更深層次的體驗，而不是類似于移動端快速的體驗。我們希望觸摸和非觸摸平臺上的規(guī)范和屬性最大化保持一致，但移動端上一些看起來很必要或者有吸引力的東西可能在桌面變成一個麻煩，即使這沒有妨礙到我們完成任務。

Chrome的桌面版一直離不開效率與執(zhí)行速度的話題。大量動效的后果可能會導致妨礙完成你的任務，這也是為什么大多數(shù)UI表現(xiàn)的沒有延遲或者以最小數(shù)量的動效表現(xiàn)。就以我們的多功能地址欄為例子吧，起初有一點動效看起來還算nice，但是當你每天使用它超過一百次時，你很快就會痛恨這該死的動效浪費的額外時間，盡管只是一個淡入淡出的效果。這也是為什么我們使它突然顯示，
就像我們的菜單一樣。

那么我們怎么做才能在這個看似有些不利于動效的平臺上得到“Material design”的趣味？我們試圖把它加入到不會受到影響的UI處，于是我們又玩起了我們的漣漪按鈕動效。

在桌面端上會有很多點擊類操作，如果與帶有觸控的混合設備結合可能還會更多。一些狀態(tài)不會出現(xiàn)在移動端上，如下：

• 鼠標經過狀態(tài)（Hover state）
• 激活狀態(tài)（Active state）
• 單擊/點擊（Single click/tap、單擊觸發(fā)到釋放）
• 單擊/點擊激活（Single click/tap to active、從激活狀態(tài)到釋放）
• 按住/長按激活（Long click/tap to active）

我們將所有的動效都基于Material design的波紋漣漪制作——從點擊或觸碰位置產生簡單的顏色變化。由于懸停狀態(tài)不存在MD規(guī)范中，我們要做到第一件事就是使其與波紋動效結合。這里我們在鼠標經過后點擊使用波紋展開的動效，并將其像邊界推，再簡單的鼠標懸停和單機情況下，它看起來應該是這個樣子：

下面是在工具欄中的樣子：

對于“單機到活動狀態(tài)”和“長時間點擊/按下到活動狀態(tài)”，我們需要將波紋與普通的最終狀態(tài)（灰色的圓角矩形，類似于鼠標懸停效果）相結合。為此，我們與Material design團隊一起探討了波紋的變形效果。下面是移動端的探索一部分：

應用到桌面端的單擊活動狀態(tài)，我們保持了波紋的擴散效果，而且一旦波紋擴展到其最大值，我們讓其變?yōu)橐粋€（圓角）正方形，而不是讓他爆發(fā)開來。如下：

長點擊/長按效果類似，只有這一次我們減緩了波紋拓展速度：

最后，對于我們的書簽欄我們使用了滿眼型漣漪效果。這種類型的波紋是一個擴展的橢圓形，最后會填滿整個區(qū)域。下面的例子中，我們將波紋與懸停狀態(tài)的動效相結合，來創(chuàng)建我們的書簽活動狀態(tài)效果：

注：我們最后決定不再macOS平臺上實行這種效果，因為感覺這些動效在這個平臺上有點不適應。在這里我們優(yōu)先選擇與原操作系統(tǒng)的一致性。

在開發(fā)方面，Ben Ruthig是我們在桌面端建立新的波紋動效背后的主力。設計方面，這些快速的預覽動效和規(guī)格都是在Hype3上做出來的，你在上邊看到的動效圖也是。這種原型可以快速的讓我們進入到代碼實現(xiàn)階段而不是在花費時間在原型的循環(huán)迭代上，我們使用原型作為大方向代替一些規(guī)范，代碼從web到C變化很大，早期的直接嘗試開發(fā)輸入是很寶貴的資源。

對于這種類型的動效工作，開發(fā)者們才是真正的設計師。

What’s next

在完成了核心UI的實現(xiàn)規(guī)范和原型之后，我們討論了一下次級UI，包括了每種都不會直接顯示的Chrome元素，比如菜單、對話框、氣泡、按鈕、信息欄、頁內查找和底部下載架。有些可能已經上線了，有些可能即將推出：

The new download shelf, available on?Windows.（2016-09-22）
還有一些為了防止對未來更新造成困擾我不會在這里展示，但如果你是一個狂熱的Chrome用戶，你可能已經在Chrome的flags里啟用了一些新功能——Chrome團隊精心帶來的嶄新的次級UI和一些內部頁面，如下：

The new “History” inner?page

The new “downloads” inner?page

核心UI項目最終迎來了尾聲，我在Chrome瀏覽器的參與也結束了，我很興奮地看到Chrome團隊在桌面端和移動端上的未來一片光明。

Lessons learned and initial release feedback

作為結語，我想向大家分享一些通過這個項目學到的一些經驗，還有關于內部和外部的發(fā)布反饋。希望這些能對你或你的項目有所幫助。

1. 工程師們都是優(yōu)秀的設計師

我們在設計圈討論過很多次，設計師是否需要會編程和為什么要編程。關于這個問題有很多不同的意見，他們都來源于沒有一個簡單的設計師定義這個事實。然而我們很少提及的是：開發(fā)們應該學習設計嗎？

從結果上來看，開發(fā)者們才是生產者。在一定程度上，使之變?yōu)橐粋€真正的可用事物才是一個產品的“設計師”應該做的。大多時候，作為設計師我感覺我們所做的一切都是在試圖“偽造”和“模仿”最終結果。說來說去，讓產品盡可能快的處于真實的場景和代碼中是必不可少的。

在這個項目中，我的很多假設都被開發(fā)們打破了，他們不僅提供出了更好的解決方案，而且比以往我做的更好的執(zhí)行和迭代了我的設計。我開始更具體的審視和思考程序化渲染（Peter Kasting的大力支持）和動效設計（Ben Ruthig的帶領）的事了。他們的代碼知識對于做出正確的設計是至關重要的，這不僅僅改變了設計本身，而是從UI的視覺改進到核心元素的重寫，改變了項目性質。

每個人都是設計師。想法不再局限于角色規(guī)則。如果你有幸與積極、熱情飽滿的開發(fā)者們一同工作，你可能會發(fā)現(xiàn)有時候他們是比你更出色的設計師。

2. 使開發(fā)盡早的開始

在本次項目中， 工程師們很早參與到設計和構想過程中。正如我前面所提到的，他們通過更好的開發(fā)解決方案來積極產生更好的設計，造就了今天這樣的產品。成員之間保持不斷的溝通才是為正確的設計帶來活力的關鍵。

3. 知道何時張、何時弛

提供一份非常周到的設計規(guī)格是必要的，然而一些情況下，在設計初期就開展反饋，會讓一些新的想法使你的設計上升另一個層次。只要你的最終設計依然保持著原始的目標和意圖，那么就開放包容地讓其他人進入并改進你的設計過程吧~

4. 當心背離設計方向

當你準備Redesign一個產品、特別是一個已經上線一段時間的產品的時候，你將會碰到我們許多人都會碰到的：改進看上去比較丑的地方?，F(xiàn)在要小心了，有時你“好心”的改進可能使其變得更加糟糕，大多數(shù)情況下，僅僅是一些簡單的改動也會觸及到一些用戶的底線。

這是一場難以接受并且需要非常努力的戰(zhàn)斗。對于這次的redesign，添加一些像素級別的改動我們都會進行長時間的辯論和討論。我沒有撒謊，我可沒有奇跡般的解決方案，但有一些事情我們可以讓用戶的情緒最小化：

• 與你的“觀眾們”溝通。在產品開發(fā)這條大船的行進過程上，你要時刻準備在甲板上想愿意收聽你的人解釋你的版本細節(jié)，特別當他們還是你的利益相關者。
• “保持航向”，堅持到底。堅信你的選擇是有利的，但不要固執(zhí)。保持自信。
• 十足的準備。當有人想和你探討你的設計決策時，準備好現(xiàn)有的實際情況、調研（如果有）和過去的一些驚經驗。當你發(fā)現(xiàn)你無法回答對方的問題時，他們的反饋值得你去思考。
• 認識到一些事情花費的時間。令我感到沮喪和處理麻煩的是，一些事情只是需要時間來改變。產品越大，花費的時間越長。不如轉換為從階段勝利中獲得成就感，并重新認識到你的產品永遠也不會完成。

5. 管理你的預期指標

每當一次更新推出時，我們收到最難的反饋就是“那是啥？”。在我看來這是一個公平的反饋，項目花費了一段時間（測試）而且并沒有視覺上的大幅度革新，我更想說，如果你多看看細節(jié)，你就會感受到我們在這上面花了多少關心和注意力。這次的重設計項目我們最大的改進是在底層上的提升，這是開發(fā)中最主要和重要的。我真心希望，隨著時間的推移我們的團隊和我們的用戶都可以從中受益，因為現(xiàn)在的Chrome在所有平臺上前所未有一致和靈活。

通過自己的眼睛找到工作中滿意的地方和結果，比通過其他人找到的方式更重要。如果你真誠而真正的對你所做的事情感到滿意，那你很棒哦。

Closing notes

感謝你閱讀了這么多。如果你想，你可以隨時通過Twitter或者其他地方來聯(lián)系我。

如果你想聯(lián)系Chrome的設計團隊，下面就是這些很cool人的推特：Alex Ainslie, Chris Lee, Max Walker, Rachel Ilan Simpson, Peter Schaffner, Hannah Lee, Glen Murphy。

再下面則是幕后工作的那些優(yōu)秀工程師們：Peter Kasting, Ben Ruthig, Evan Stade, Terry Anderson, Valery Arkhangorosky, Jayson Adams。

原作者：Sebastien Gabriel

原文地址：https://medium.com/google-design/redesigning-chrome-desktop-769aeb5ab987

翻譯：fenx

來源：http://design.moe/design/155/Redesigning-Chrome-Desktop.html

本文由 @fenx 授權發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。