Redesigning Chrome Desktop

Chrome is using the Skia graphics library. After a few tries, Peter was able to render key Chrome elements such as tabs and omnibox perfectly without using any type of bitmap. On his side, Evan created a converter able to translate .svg code to Skia code. .svg would essentially serve as a blueprint, a set of instructions for code rendering.

The design to engineering process was then defined as followed:

Designers would create .svg at any size desired to serve as a template for the Skia code rendering. This applies to both shapes and icons. Engineering would then take this template and implement it in Chrome, using Skia.

Here’s a schematic of the tabs:

Tabs are made of one .svg for the filling and another one for the stroke. Engineering then takes the .svg code and changes their paths to SKIA code adding proper coloring and opacity.

Here’s a code preview with the example of an icon, using the auto-conversion tool Evan put together:

This technique resulted in a huge decrease in the number of bitmaps use in Chrome, from around 1200 to… 0.

Keep in mind that all variant of buttons are now handled via code, effectively removing any duplicates for hover/pressed states as well as any need to apply color directly on the asset. All of this would be handled in code.

The bonus and huge advantage over using .svg directly is that we are able to control the rendering of each elements on a per PPI basis. This means that we can create an icon slightly different from 1x to 2x if need be. This is a huge deal as desktop is still majoritarily 1x. In addition we would also be able to control rendering for decimal multipliers, like 1.5, 1.25, etc… Making Chrome look as good as we can get in all odd PPI configurations.

With this new awesome tool and process in place, it was time to design and implement the new UI.

Visual consistency and design details

The redesign of the desktop UI wasn’t about starting from scratch as much as bridging the gap between our new design language on mobile and our aging desktop visuals.

A question that I think has been in the mind of all Chrome visual designers at one point is: “What makes Chrome, Chrome?”

There is a lot to what makes Chrome what it is but at the same time, our role is to disappear in favor of the content, in other words, be present but not in the way.

The key elements when you think about our Core UI are the tabs and icons. Chrome mobile was already using the new sharp tab edges on tablet and was also using the new icon system derived from the Material design guidelines. In this context, our goal was to:

• Bring the new tab shapes to life on desktop
• Bring a new set of icons, derived from MD using desktop sizes
• Align and simplify our color palette and our theming system. 
  Bonus: Bring the new “dark” incognito to desktop
• Start the revamp of secondary UI elements such as buttons, toolbars, bubbles, etc…
• Create a more touchable version of Chrome for convertible devices
• Come up with a set of rules for Third party OS consistency
• Implement MD motion when possible

General layout and UI footprint

There is one key thing to remember when designing Chrome’s Core layout: UI footprint. It’s the exact amount of pixel we use to display our UI or in other words, the amount of pixels we take away from the content.

The height of the pre-MD design when the bookmark bar wasn’t displayed was 73px on Chrome OS and macOS (including the window frame) and 78px on Windows (including the frame as well).
The native frame on windows is taller than its ChromeOS and macOS counterparts. It makes the frame easier to click and grab at the cost of a bigger footprint. See a comparison on macOS with Windows below, pre-MD:

This previous version of the Chrome toolbar layout was created when high PPI screens didn’t exist so it was optimized for rendering at 100% scale, using odd numbers so you could center element on a full pixel.

The first thing that needed to be done was using an even grid so that carrying the layout throughout various multipliers would be easier. This way icons would fall on the pixel grid more often by comparison with an odd number based design grid.

Material design uses 8pt as its baseline. We are using half as small: 4pt. 
Setting a grid and positioning elements by increments of 4pt tremendously helped getting a good balance and keeping the layout, iconography and typography consistent throughout. To achieve balance, we split the UI in half: tabs + window frame / Toolbar.

This is what it looks like for the regular UI:

As you can see on this 200% (or @2x) preview of Chrome MD on Chrome OS, the toolbar is split in two parts of 36pt each. Each core element falls on the 4pt grid.

Tabs are 28pt, equal to the omnibox height. We leave an 8pt top padding between the tabs and the top of the frame.

If you looked closely, you might have noticed that the omnibox strokes are not aligned on the grid in this preview. The reason is that we use 1px as line weight regardless of the PPI, creating a lighter UI with thinner strokes.

The downside of this technique is that you always need to remember that the space which was supposed to be filled by the thicker, 2px stroke, is now an empty space.

You might also have noticed that we render the stroke by adding 1pt at the bottom of the toolbar rather than insetting it for balance reason, effectively adding 1pt to the 36pt+36pt total height.

On the left is our hybrid UI.

For Hybrid, we maintain the frame padding (8pt) while increasing the tabs and toolbar footprint by 4pt. The result is a more spaced out 40+40 layout.

You might wonder at this point why we do not simply match the Android or iOS touch target recommendations (48 and 44 respectively) to make things touchable. We actually tried this but goes against what Hybrid is trying to achieve.

We aim at the right compromise between full-touch and non-touch. Balancing our goal to minimize user touch errors without compromising the productivity aspect expected from a laptop layout.

On desktop, every pixel counts, delivering the tablet UI on a laptop was out of the question.

Following is a comparison between Chrome pre-MD, Chrome MD normal layout, Hybrid and finally, Tablet, all rendered at 200% (xhdpi for Android).

Effectively, the MD normal layout footprint, including the window frame is 2px taller than its pre-MD ChromeOS/macOS counterpart (71 vs. 73). However, because we moved the UI up by 3px in the window frame the new UI, not counting the window frame we get a UI effectively 5px taller (60 vs. 65).

A pixel is extremely valuable for Chrome and every single one counts.
In the case of the redesign, all size decision was affected by the following factors: UI legacy, adoption of the new grid and overall UI balance.

This logic also applied to icons…

Iconography

The choice was quickly made as to what set of icons to use.

We needed to revamp our numerous core ui icons as well as all the feature icon spread across the product and the Material design icon repository offers just that. That way, they would also be fully consistent with the icons on our mobile properties, both iOS and Android.

However, one problem remained: grid size. The 24x24pt based grid wasn’t really fitting the rather condensed UI we were planning to create (even including hybrid). After all, they were conceived for mobile.

We needed to derive a grid that would fit our new normal and hybrid UI.

To do so and to match our 4pt grid, we used 16x16pt based icons as described in the following preview.

We reduced the container from 24pt to 16pt and added some flexibility around the initial internal padding: 2pt change to 1pt to 2pt depending on the icon for the Chrome icon grid. The reason for this flexible padding is that considering the wide variety of icons we were going to use, some might require extra space to make their paths work visually at small sizes.

The advantage of this straight 33% reduction in size is that we were going to be able to also use scaling straight from the Material icons. This would drastically improve our icon delivery time and increase scale-ability… at the cost of some icon being rendered off grid, and therefore slightly blurry.

While this would be fine on secondary icons, all our most prominent icons had to be rendered properly and as pixel perfect as possible. To that end, we would re(create) them to avoid any off-grid pixel, especially on lower PPIs. See our “back” icons below”

As you can see, since we have control of the rendering on any given PP, we remove the scaling-induced blurriness of the icon. 
We also made the icon line weight slightly thinner (2px on 100% and 3px one 200% from the initial 2px in 100% and 4px in 200%) as I thought the weight was slightly too high. This way, they are more elegant and balanced within our UI.

This technique offering both flexibility and control over our assets really reduced our visual maintenance cost. Relying on an already existing, huge set of asset was also a huge time saver for our feature team, capable of iterating faster on their feature icon without having to wait on a designer to create a custom icon. Finally, it brought consistency between mobile and desktop.

Since these were rendered programmatically, we also deleted all duplication for color states, all we have to deliver is a black .svg and paint the required color in code.

A nice added bonus of programmatic rendering is that we are able to cut and badge the icons when needed (for blocked extensions and permissions for example) instead of exporting the blocked and non-blocked variant as separate bitmaps.

See the process specced below:

Below is a preview of the new unified iconography system with color and badged versions. This gives you a sense of the system as a whole.

Now that the icon creation process is ironed-out. Let’s see how they fit within the UI.

Touch targets and layout

Since the icons are based on a 16x16pt layout that fits perfectly the 4pt grid determined earlier, placing them and spacing them in the UI was just a matter of figuring out the proper size of touch/click targets for both normal and hybrid mode.

In normal mode, we went for 28x28pt touch targets, holding 16x16pt icons. Of course the following spacing are consistent throughout all Chrome normal layouts, regardless of the platform.

Below is Chrome in ChromeOS:

For Hybrid, concessions had to be made as to how much we wanted the UI to grow. We wanted to offer the user more space while maintaining a compact layout which explains why some elements had to break off the grid, as you’ll see below.

As we were still trying the theory behind this layout, we were a bit more conservative. What I kept repeating to myself during the making of this layout was that the user shouldn’t feel too uncomfortable using it with mouse only, it shouldn’t waste space.

We first focused on increasing the height of elements for which we already had identified the most pain points: the tabs and the omnibox.

We both increased them to 32pt from 28. In addition, we use a technique that increase the touch area of the tab into the frame itself, adding 8pt of additional touch target size.

While icons kept their 28x28pt touch targets, we increased their surrounding margin to 8pt, giving the UI more space and reducing user touch errors. Same principle applies to icons within the omnibox (extensions and permissions) as well as extension icons.

You can notice that while the spacing changes, icons, remain the exact same size. We use 16x16pt iconography throughout. This minimizes the amount of design asset requiring maintenance, making long term scalability as well as feature iteration easier.

See what the completed Hybrid core UI looks like below.

Conceiving a layout from the ground up is a fairly easy part, coming back to it years after years and not being lost and overwhelmed is where initial planning and organization pays off.

Aligning all icons to be the same size tremendously streamlined our maintenance and design process and made the design more uniform and elegant.

Previous, non-MD icons were created over a period of several years which made it hard to maintain a consistent set of size. This time, we even updated our extension icon requirements to be 16x16pt instead of the previous 19x19pt. We also redefined the way badging works, following the same cropping technique we used for blocked permission.

Finally, for users who like to always show their bookmarks bar, we tweaked it as well so it doesn’t unbalance or overpowers both layouts.

See example below with Mac for normal layout, Windows and Chrome OS for Hybrid.

Mac appends 28pt to its normal footprint, to match the toolbar buttons 28x28pt click targets.

Windows and Chrome OS in normal or hybrid, operate slightly differently.

We appended a 24pt high bookmarks bar to balance the extra height of the Windows frame. Since ChromeOS uses the same implementation as Windows, it inherits this same measurement.

As we are still experimenting with this layout on ChromeOS. Time will tell if aiming for the right balance between touch and non touch will pay off.
This is why until we get a better understanding of our users habit and needs on the the Windows platform, we will ship the normal layout by default for all Windows devices. ChromeOS touch-able devices will however get Hybrid by default.

If you want to try it for yourself, simply head to the chrome flags section (chrome://flags) and set the “UI Layout in the browser’s top chrome” flag to “Touch”.

Omnibox, results dropdown and security indicators

There are two tenants to our omnibox and dropdown layout design:

• Give a strong emphasis on security states.
• Fast access to the information or URL you need to go to.

The omnibox is probably the most important feature of Chrome. It is our users’ gateway to Google search results, the web, as well as their own bookmarks and history. It is also the only place where we can indicate strongly the security state of a domain, effectively trying to protect our users against a myriad of online threats through active blocking, passive indication and education.

To that goal, visual designer Max Walker as been working hand in hand with Chrome UX lead Alex Ainslie and Chrome security to add a new, revamped security indicator system to our omnibox which goes as followed:

• We replaced the default “page” icon by an info button, inviting users to click it to edit site permission and understand the security state of the domain they are on. Non encrypted HTTP pages fall in this category.

• Secured or “Green lock” state is now only applied to secure, HTTPS sites. This move rewards secured domain who uses encryption.

• You might remember that Chrome had a yellow security state back a few years ago. This time, all websites with broken https or presenting a threat are marked as red. When Google knows the domain is a phishing site, we also completely block its access.

Max aligned the typography of the certification with the URL text and used our new color scheme. He also revamped our locks, giving them a light look.

In direct relationship with this is the omnibox dropdown, or the container of the result you get when typing a query. The dropdown wasn’t drastically changed in the context of this revamp. We changed the iconography along with the color scheme but the core of our work is represented in two changes: a new layout for hybrid and more importantly, inline answers.

Inline answers, also named “answers in suggest” is essentially Google or Chrome displaying the information you are looking for before you actually hit “enter” to validate the query. For example, when you type “weather in los ang” in the omnibox, Chrome was suggesting you the following:

Now with answers in suggest, if we are sure to have the answer you are looking for, we display it as part of the results. As you can see below, it doesn’t only apply to the weather but also quick queries, stock search as well as calculations.

This is what this query looks like in normal layout:

And here’s the difference with another query (stock query this time) in the hybrid layout, with improved row height for touch-ability.

The omnibox dropdown on desktop always offered very tight rows, regardless of the platform. It is a balance between information density, clarity and ease of use to get the user from query to result as fast as possible.

Just like for the other Core UI features, hybrid is about reducing user touch error by increasing the height of each row while maintaining high information density to avoid too much travel for the user’s eye and therefore more time to access content.

Colors and accessibility

Beyond layout density, another element with a lot of influence is color.

Chrome MD for desktop went through the same mutation Chrome for Android did. We needed a more unified color guideline as well as a consistent and more importantly, accessible, color scheme.

Of course the most prominent change you notice when opening Chrome is the Core UI color change itself.

Balancing the color of the core UI is a task requiring some subtlety, more than I thought it would at first.

The Core UI is formed of three key elements:

• The frame, created by the OS itself, changing on a per platform basis
• The Active tab and toolbar. Which includes the selected tab attached to the ommibox and controls
• The inactive tab(s).

To work well, these three things need to have a proper amount of contrast. Something that wasn’t easy to solve was how to bring the design to a flatter, more modern look within compromising too much on the contrast.

Another thing we needed to think about was theme. Contrarily to mobile, desktop supports theming. We needed to account for that and improve on it if possible.

Finally, my personal favorite, we wanted to make incognito mode really different, instead of theming only the frame, we wanted to completely change its global theme, making it very dark, just like its mobile counterpart.

Here’s Chrome three level structure for both modes:

Our Core UI color system is as follows:

Mac and Chrome OS are pretty straight forward as we control the color of the OS frame directly, simply adding the background blur on mac.

Windows is a bit trickier as the user or system can set pretty much any color as their frame color. Therefore, we continued what we’ve been doing so far, playing with opacity to blend our color with whatever the system shows. 
See comparison below, while mac and Chrome OS inactive tabs uses an opaque coloring, we reduce the fill of inactive tabs and new tab button to 78% on Windows.

To balance the new color theme, we rely heavily on the use of stroke. Since the stroke have a 1px weight regardless of PPI, their opacity have been tweaked a lot so that they do not look too dark in 1x, or too light in 2x. This goes for normal and incognito mode.

Accessibility has always been part of Chrome’s DNA whether it’s on the content side with a11y compliance or on the UI side.

In the past two years, this effort grew even stronger. Admittedly on the visual side, our color scheme needed a new pass to make it both simpler and compliant to the WCAG 2.0 rules for good contrast.

We made sure that all our typography as well as iconography reaches at least AA level or 4.5:1 contrast ratio:

A great tool I recommend to test contrast ratio: http://leaverou.github.io/contrast-ratio/

Directly related, our programmatic rendering enables us to color our icons dynamically based on the contrast ratio, which not only means that the themes created for Chrome will look better but also that accessibility will be improved as well.

As you can see below, installing the theme “Dark theme V3” makes the icons switch to white and the dropdown automatically switch to dark mode.
This is a direct benefit we get from programmatic rendering and our incognito mode implementation.

Motion

Motion is a big part of what people think of when describing “Material design”, especially on mobile. Good motion design on this form factor can really make an app shine and empower its users to use it more effectively. Provided you are not over-doing it, you as a designer can provide delight as well as guidance and spatial awareness using subtle hints and opinionated and clear UI movement.

But when it comes to desktop and its mouse-and-keyboard-first, large screen environment, it’s a slightly different story. 
Desktop is a platform you will likely engage with for a higher amount of time than mobile, usually using productivity tools, in favor of a deeper experiences as opposed to the quick, on-the-go or more lean back mobile experience.

As much as we would like touch and non-touch platforms to be more consistent in their paradigm and attributes, something that might seem necessary and engaging on mobile can become an annoyance if not a hindrance to the task you are trying to accomplish on desktop.

Chrome desktop has always been about efficiency and execution speed. No motion should get in the way of you accomplishing your task, which is why most UI surfaces appear with no delay or with the minimal amount of motion.

Take our omnibox dropdown for example, a bit of motion might seems nice at first but when you access it more than a hundred times a day, you are quickly going to hate us for that extra bit of time we are taking away from you, simply to show a hypothetical sliding animation with fade-in. 
This is why we make it appear instantly, like our menus.

So how do you get some “Material design delight” on a platform that seems so hostile to motion. Well, you try to add it to pieces of the UI that will not be affected by it, this is why we played with ripple effect on our buttons.

There is a lot to a click action on desktop and there is even more when you combine that with the touch-ability of hybrid devices. Some of the states do not even exist on mobile. They go as follow:

• Hover state
• Active state
• Single click/tap (onClick-release)
• Single click/tap to active (button enters “active” state upon release)
• Long click/tap to active (for elements only displaying options on long click/tap)

We based all our motion on the Material design ripple burst. A simple burst of color growing out from the the click or tap location.

Since hover states didn’t exist in the MD spec, the first thing we had to do was combining it with the ripple. We make the ripple burst out of the squared hover state, pushing its boundaries outward. In the case of a simple hover + single click with no active state, it looks like this:

This is what it looks like in our toolbar:

For “single click to active” and “long click/pressed to active” we needed to combine the ripple with the common final state of the button, the active state, which is a grey rounded rectangle, similar to our hover state.

To do so, we worked with the Material design team to explore some morphing effect on the ripple. This is a mobile exploration:

Applied to the desktop, and for the single click to active, we maintain the ripple expansion spread but once the ripple reaches its apogee, we morph it into a square instead of letting it burst. It looks like this:

The long click/tap to active is very similar, only this time we slow down the expansion of the ripple.

Lastly for our bookmarks bar, we implemented a flood ripple. This type of ripple is an expanding ellipse filling up a contained area. In our case, we combine the ripple with the hover state to create the active state of our bookmarks, like shown below:

Quick note, we decided not to carry ripple effect to macOS as they felt a little out of place on this platform. We chose OS consistency here.