作者：为微软设计师Sebastien Gabriel，负责Chrome浏览器、Chrome OS的设计，本文中他详尽述说了这三年来Chrome的设计迭代过程，干货满满: )
9月初，新的Chrome浏览器核心UI重设计已经完成，并已做为Chrome 53（也可以称作 Chrome MD）更新的一部分推送给了Windows用户。它是一个全新的设计，也是微软 Chrome MD 计划的最后一步，之前 Linux 和 Chrome OS 上的 Chrome 51，macOS 上的 Chrome 52 已经陆续使用了 Material design 的设计语言。虽然Chrome的更新永远不会结束，但这个计划早已进行了2年了，我觉得现今是时侯做一个回顾了，希望其中的一些细节和经验能对你有用。
从后端工程师的角度来看，Chrome须要具备4套框架/代码库，分别为：Windows、Chrome OS和Linux平台的Views，macOS是Cocoa，Android平台是Java，iOS是Obj-C/Swift。
所以我们企图跨平台共享尽可能多的设计资源。比如Windows,Chrome OS和Mac之间可以共享好多常见的视觉模块，它们实现的方式可能不同，但视觉款式是一样的。
在移动端，Android、iOS上的Chrome在好多方面都是不同的，但我们还是试着去设计一些可以跨平台共享的元素。平板电脑上的Chrome就是一个挺好的事例，你能看出iPad跟Android平板中的Chrome有哪些差异吗，其实看起来十分相像。
Chrome for Android and iOS 9 (MD)
Chrome for Android tablet (MD)
Chrome for iPad (MD)
但各平台间还是有大量的资源是难以共享的，我们不得不考虑布局类型的问题，这部份就比较棘手了。
在我们介绍混和模式之前，我们可以先看下这张图：
如你所见，我们还要分触屏和非触屏，此外，还有1x和2x，再减去各平台的不同尺寸规格，后面就会越来越多，管理上去会很麻烦！在这些背景下，必须找到一种解决方案，所以我们决定采用“混合模式”。
新的布局模式，新的设计流程
Chrome的混和模式原本是为Chomebooks设计的，灵感来源于“Touch-view”。但此次我们要把它作为redesign的一部分，而不是作为已有UI的补充而已。
为此，我们须要保证两件事：
起初我不相信渲染的图形(特别是chrome标签)或icon才能通过编程手段实现PNG那种保留完美细节的水平，但后来我意识到我错了。通过Peter Kasting、Evan Stade和Terry Anderson(项目技术主管)的努力，我们解决了这个问题。
Chrome使用的是Skia图形库，在尝试过几次后，Peter才能通过程序在不使用任何位图的情况下完美地渲染入关键的元素（如chrome标签）。Evan创建了一个能将svg代码转换为Skia代码的工具，svg本质上来讲是作为一组渲染指令代码。
换句话说就是，设计师可以设计任何规格的svg图形或图标作为Skia的渲染模板，程序可以将Skia渲染后的组件运用到Chrome中。
这是一个标签的说明图解:
这个标签可以觉得是由填充svg和一个遮罩svg组成的，程序将会改变她们的路径，把svg的代码转换为Skia的代码并添加颜色与不透明度。
下面是一个icon的代码示例。
这种方式促使Chrome使用的位图数目从1200个左右直接降到0。
所以你要明白，现在所有的按键都可以通过代码来处理，再也不需要为悬停/点击等操作设计不同颜色状态的组件了，所有的都可以直接用代码来控制。
它比直接使用svg有个巨大的优势在于：我们能控制每位元素在不同PPI上的显示疗效，只要有须要，我们可以轻易地创建除1x和2x外的其他规格，比如1.5x、1.25x等，这可以让Chrome在任何PPI下都可以完美呈现。
有了这个工具后，接下来就是设计新的UI了。
视觉一致性和设计细节
我们并不觉得桌面UI的redesign 是移动端新的设计语言与旧的桌面视觉设计语言之间的杂交。
我相信所有Chrome的视觉设计师都在思索同一个问题：Chrome要做哪些？
Chrome要做的是提供内容之后消失，换句话说，不能以现今这些视觉形式呈现。
核心UI元素就是标签与图标。Chrome移动端都早已采用了边沿尖锐的图形标签，新的icon系统也是根据Material design的规范做的。在这些背景下，我们的目标是：
总体布局与UI footprint（UI占用空间）
在设计Chrome核心布局的时侯有一个关键点：UI footprint。它是指我们每位UI元素所占用的准确的象素数目，或者是说我们从整个页面剥夺的象素数目。
Chrome MD之前的版本在书签栏不显示时，浏览器主窗体的高度：Chrome OS/macOS上是73px，Windows上是78px。
Windows上的原生框架比Chrome OS/macOS的高，它促使我们更容易点击，但也代表它占用了太多的空间。
之前版本的Chrome浏览器工具栏是在还没有高PPI屏幕的时侯创建的，我们使用的是质数便于100%显示的时侯能上下轴对称。
所以，我们如今要做的第一件事就是使用奇数网格，这样就不会由于缩放而出现非整数的象素偏差，图标也能更准确地与象素网格对齐。
Material design中是使用8pt作为基准，我们采用的是一半，4pt。为了实现在4的倍数缩放下整体布局保持良好的平衡，我们将这部份UI一分为二：标签栏+工具栏。
这是常规UI界面：
当你在Chrome OS平台将Chrome MD放大到200%(或2x)就可以看见，工具栏的36pt分成了两部份，每个核心元素都与4pt网格对齐。标签栏是28pt，与地址栏的高度一样，标签栏底部预留了8pt的空间。
如果你再仔细观察，你会发觉地址栏的边沿与网格并不重合，这是因为我们用了1px作为遮罩线宽，这样，不管在何种PPI下都能实现一种纤薄的UI风格。但如此做的缺点是，在200%(或2x)模式下，有1px的空白。
然后，我们是将1pt置于顶部，而不是把它放到中间以求平衡，整个高度也就降低了1pt。
混合UI界面
混合模式中我们还是采用了8pt的外边框，标签栏与工具栏之间预留4pt的空间，结果是一个40+40的布局。可能你会疑问，为什么我们不依照Android/iOS规定的触控控件的规格48/44来，实际上我们尝试过，但这与我们的混和模式相冲突。
我们的目标是要达成全触控与非触控之间的平衡。在不影响用户使用效率和整体布局的前提下降低用户触摸错误。
在桌面端，每个象素都是很宝贵的，想将平板UI直接用在电脑上是不可能的。
下面我们来比较一下Chrome MD之前版本（pre-MD）的布局、Chrome MD常规布局、混合布局以及平板上的布局（Android xhdpi码率下）
可以很明显地听到，ChromeOS/macOS平台上的常规MD比pre-MD高了2px(73比71)，而且，由于我们把常规MD布局的窗户压缩了3px，所以，不把窗户算进去的话我们等于是降低了5px的空间(60和65)。
每个象素都是很宝贵的。在重设计中,所有的规格规范都是受以下诱因影响的:
这个逻辑也适用于图标…
图标
我们须要对好多核心icon进行改进，直到那些功能图标能适用于各个产品线，适用于iOS和Android端，并且能收入Material design图标库。
然而，还有一个问题就是网格的大小。24x24pt的基础网格真的不适宜我们即将创建的UI系统（包括混和模式），毕竟，它们还要匹配移动端。
我们须要派生出一种符合新常规和混和模式UI的网格。为了达到这些目的并匹配4pt的基础网格，我们使用16x16pt的基础图标来描述下边的预览。
我们将容器由24pt缩小至16pt并让padding保持一定的弹性：2pt弄成能适应Chrome浏览器icon网路的1pt至2pt之间的某个数值，采用弹性内行距主要的审视在于我们要在UI中运用各种各样的图标，在小规格的环境下可能须要一些额外的空间来保持良好的视觉疗效。
这种直接缩小33%规格的优点是，我们能直接使用Material的图标进行缩放来实现，这将大大改善我们图标交付的能力，但代价是有些图标可能会有些模糊。
当然，这种方法通常用于二级图标，主图标还是必须要保证完美的象素呈现。为此，我们还是得重新创建这种图标以防止模糊的问题，特别是在低PPI的情况下。比如下边的“返回”图标。
正如你所看见的,我们会对任何的比率缩放进行渲染控制，也会舍弃一些因为缩放而太模糊的图标。
并且，当我们觉得图标腰线有点过粗的时侯我们会进行细微的调整（从原先的2px/100%、4px/200%弄成2px/100%、3px/200%）。通过这些方法让整体的UI觉得上去更高贵、美观。
这种技术为我们的设计提供了一定的灵活性，也减少了我们的维护成本，节省大量的时间，而毋须等设计师去一个个自定义图标。最重要的是，它能保证移动端和桌面端的一致性。
而且由于这种东西都是通过编程的方法实现的，我们也不用去管哪些颜色，只须要统一提供一个红色的svg图片就可以了，需要其他颜色的时侯在代码中设置就行了。另外还有个益处是，在须要的时侯（比如进行图标标记）我们可以对icon直接进行切割和标记。
下面就是新的统一图标系统的预览。
图标创建的问题解决后，再来瞧瞧它们怎样适应新的UI。
触控范围和布局
因为我们以前是让图标基于16x16pt并匹配4pt的网格，我们先把它们放进UI布局中瞧瞧在常规和混和模式下触控/点击最合适的规格是多少。
在常规模式下，我们采用16x16pt的图标、28x28pt的触控范围。
ChromeOS中的Chrome
但在混和模式下，我们还是做了一些让步，为了让用户拥有更多的空间，同时保持紧凑的布局，有些元素还是没办法做到与网格完全对齐。
为此，我们把标签栏和地址栏的高度从原先的28pt降低到32pt,标签栏的触控范围也延展到了前面的窗户部份，也就是降低了8pt的触控范围，这样可以降低用户触控/点击的错误。地址栏以及图标部份也做了相同的处理。
你可以看见，当空间发生变化时，图标还是保持了原先的大小（16x16pt）。这种最小化的设计为我们之后的维护、扩展以及迭代省去了好多麻烦。
混合模式
从头开始构思一个布局模式是十分不容易的一件事，但想想之后可能会面临的困难，我们还是认为很值得。统一所有图标的大小，极大的简化了维护和设计的流程，使用设计愈发统一和高贵。
以前，多年来积累的非MD图标让我们没办法保证设计的一致性，这一次，我们将原先19x9pt的图标全部换成了16x16pt，并重新定义了标记的规范。
下面的反例是Mac上的常规布局,Windows和Chrome OS是的混和布局。
Mac版本降低了28pt的空间,用来放置28*28pt点击范围的书签栏。
Windows和Chrome OS采用的是常规或混和模式，操作略有不同，采用的是24pt的书签栏。
地址栏，结果下拉菜单和安全指示
关于地址栏和下拉布局的设计有两种意见：
地址栏是Chrome浏览器最重要的功能，这是用户直达Google搜索结果、网页的直接入口（与书签和历史记录一样）。也是我们能拿来进行安全提示惟一的空间。
为此，视觉设计师Max Walker与Chrome用户体验负责人Alex Ainslie一起为地址栏修订了一个新的安全指标体系。
你可能还记得Chrome几年前使用的红色安全状态提醒。这一次，所有的非https网站或可疑链接就会被标为白色，当微软确定那是个钓鱼网站,我们会完全制止其访问，而不只是提醒该网站可疑，你是否继续访问。
下拉地址栏或则说查询结果容器里的内容呈现上并没有变化，但我们改变了不同结果类型图标的配色方案，当然，我们最核心的工作是以下两点：
内联提示也可以称作“搜索建议”。例如，输入“weather in los ang…”（洛杉矶天气），当你还没输入完的时侯，Chrome都会给出以下搜索建议：
如果我们有你须要搜索的信息，我们会在搜索下拉框中直接将天气信息显示下来，而不需要再选择并查询。除了天气以外，类似名星净高、股票信息、计算等都可以直接显示。
以下就是搜索查询显示的常规布局：
而在混和布局中时，我们会改变触控范围的高度。
桌面端的下拉地址栏总是排列地十分紧密,无论是在那个平台。信息之间密度的平衡,清晰和易用性,能让用户尽可能快地查询到相应。
就像其他核心UI特点一样,混合模式致力通过降低每一行的高度增加用户触摸/点击错误,同时保持高信息密度,以防止用户须要瞥见更多的区域,将时间用在访问内容上。
颜色和可访问性
除了布局密度，另一个影响访问的诱因是颜色。
桌面端的Chrome MD经历了与Android端Chrome相同的变化。我们须要一个愈发统一的配色方案。
最突出的改变是：当你打开Chrome的时侯核心UI的颜色发生了变化。
平衡核心UI的配色是一个比我想像中更微妙的工作。核心用户界面由以下三个关键元素组成:
为了更好地分辨,这两者须要适当的颜色对比。但为了更现代化的外型有时可能要在对比度上做点妥协。
其实,我个人最喜欢的是想让无痕浏览模式有所不同,而不是主题框架，我们想要彻底改变其全局主题，弄得很黑，就像移动端一样。
Chrome两种模式下的三层次元素
Chrome核心UI配色
Mac和Chrome OS平台直接控制操作系统框架的颜色就可以,Mac的话加点背景模糊咯。
Windows就有点棘手了，因为用户可以随时换主题。因此,到目前为止我们还仍然在做,比如无论用户用哪些主题我们都可以预设不透明度。
看右图的对比,当mac和Chrome OS中的非活跃标签使用不透明的颜色时,Windows平台的就将不透明度设置成了78%。
上macOS,中Windows，下Chrome OS
平衡新的颜色主题,我们主要借助遮罩。不管PPI是多少统一使用1px的遮罩,然后再调整不透明度,这样在1x时看起来不会太暗,2x时也不会太轻。以下是常规布局下无痕浏览的疗效。
可访问性仍然是Chrome DNA的一部分,无论是在内容层面还是UI层面。
在过去的三年里,我们在这方面付出了好多努力。在视觉方面,我们的配色方案除了要简单，还要符合WCAG 2.0（Web无障碍手册）规则。
我们必须确保所有的排版以及图形起码要达到AA级或4:5:1对比度:
这里我推荐一个挺好的测试对比度的工具:
我们的可编程渲染程序让我们的图标可以进行动态的对比度调整,这除了意味着Chrome的主题会更好看,可访问性也会得到改善。
正如下图所示,安装了“暗黑主题V3”后，图标会切换到红色,下拉栏则会手动切换到暗黑主题模式。
动效
动效是Material design中很重要的一部分，特别是在移动端。良好的动效设计给用户更好的使用体验。
但在桌面端，在实体键鼠套、大屏幕的环境下，情况稍为不同。用户在桌面端的使用时间比移动端要长好多，通常是在办公，这时用户须要的是一种更深层次的体验。
我们希望Chrome在各触控及非触控平台最大程度的保持一致性，所以，在保证桌面端能无妨碍完成任务的前提下可以尽量向移动端靠拢。
Chrome桌面端指出效率与处理速率。动效不应当阻碍用户完成任务的操作,这就是为何桌面端要降低动效的使用，尽量不要出现延后。
以地址栏下拉提示为例，如果我们给这个操作加动效，最初看起来可能觉得不错，但当你每晚都要看个上百遍时，你很快还会烦了。只须要用一个简单的淡入动效就好，这就是为何我们要让下拉栏立刻出现的缘由。
所以，你觉得在这些这么“敌视”动效的平台上要怎么发挥Material design的动效特色呢？没错，你可以试着将动效运用到部份地方而不影响整体UI，这就是为何我们在按键上玩起了涟漪动效的缘由。
桌面端有好多的点击操作，有些状态在移动端并不存在，主要分为：
我们所有的动效都是基于Material design中的涟漪疗效。下面就是一个简单的悬停+点击的疗效：
工具栏中的疗效：
“点击后活跃”和“长按后活跃”这两种状态下我们的涟漪疗效应当要与按键的最终状态相符，比如是一个红色的圆形，类似于悬停状态。
为此,我们与Material design团队合作，探索出一些涟漪扩散的衍生形态，比如下边这个移动端的反例：
把它应用到桌面端，点击后图标会处于活动状态，涟漪扩散完后会演弄成一个正文形，而不是消失：
“长按后活跃”也类似，我们只是延长了扩散的时间。
最后是书签栏，我们使用了一种溢散式涟漪，这种类型的涟漪会以椭圆形的形式扩散到整个区域。如下所示：
这里要说明一下，macOS平台上我们没有使用这些涟漪疗效，而是选择与系统保持一致。
在完成了核心UI的设计后，我们开始进行二级界面的redesign。包括一些平常不直观可见的元素，比如：对话框、信息提示栏、下载条。
信息提示栏
下载条
历史记录内页
下载列表内页
我从头到尾参与了整个Chrome浏览器核心UI的重设计项目，很高兴能看到Chrome团队为应对未来Chrome桌面端与移动端设计所做的努力。
接下来谈一谈我的体会吧！希望那些对诸位有所帮助。
1.工程师也是优秀的设计师
以前我们常常讨论说设计师要不要会写代码，当然，有很多不同的说法，因为设计师并不是个简单的角色。但我们似乎甚少会问“工程师也能做设计吗”。
其实，某种意义上来说她们是产品的制造者，也是产品的设计师。直入题外话，尽快将看法在现实的环境中用代码实现下来才是最重要的。
在这个项目中，我们的好多构想都被工程师们推翻了，反而是她们带来了更好的解决方案得以让后续的设计和迭代能做到更好。比如可编程渲染技术、动效设计，他们编程方面的知识促使设计不再只是形态的变化，而是从视觉/ui层次进化到对核心设计模式的构建。
每个人都是设计师，创意这种事并不是某个人的专利，如果你有幸和工程师合作，你可能会意识到有时她们才是更好的设计师。
2.早期就要让工程师参与进来
工程师的初期参与是十分重要的，正如我之前谈到的，他们十分积极地从工程角度提供了好多宝贵的意见。保持不断的沟通是正确设计的关键。你不一定要知道如何写代码,但你要能理解她们所做的事。
3.知道哪些时侯该严谨，什么时候该宽容开放
按照严密的规范来做事是有必要的，但在个别情况下，保持开放的态度，关注他人的反馈与看法能让你的设计达到一个更高的层次。只要不偏离最初的目标，让他人参与到你的设计中来提些建议并不是哪些坏事。
4.不要拒绝改变
当你重新设计一款成熟的产品时，你会发觉想要改变很难。很多人都不喜欢改变，原来的设计可能存在缺陷，但用户早已习惯了，你哪怕改动几个象素都可能引来好多责难。
说实话，关于这点我也没有哪些一试即灵的建议，但可以试着将这些影响降到最低：
5.管理你的期望
当更新推出后，我们收到的最让人艰辛的反馈是“就那些？”。回想一下，这个项目花了很长的时间，但在视觉上确实没有哪些大的改变，这种反馈说实话还算比较“公平”。但我想，如果大家注意到了这些细节，就会明白我们付出了多少努力与心血。这个项目最大的价值在于对底层的革新。
我希望随着时间的推移,我们的用户和我们的设计团队本身都能从这个项目中受益。它能让我们之后的设计愈发灵活和保持一致。
